How to use scripting to secure your Win2K network--some examples
From: Tony Chow (tchow@BLUETENTACLE.COM)Date: 10/09/01
- Previous message: Russ: "Re: NTFS inherited permissions bug on W2K"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Message-ID: <50B30C640EC48648ABAA34F00D737A96CDA7@leto.bluetentacle.local> Date: Tue, 9 Oct 2001 14:11:31 -0700 From: Tony Chow <tchow@BLUETENTACLE.COM> Subject: How to use scripting to secure your Win2K network--some examples To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Hi,
After my initial post on this subject, I've received a number of
requests asking for the scripts I mentioned. This is difficult for me
to do, since my scripts use a lot of shared code and won't make sense to
others unless I post all of them. I'm also concerned that, if I am to
post the code, I will be inundated by e-mails saying "why won't this
work?", or "it destroyed my network! See you in court!" The best I can
do here is describe in reasonable detail what my scripts do to
accomplish their goals. All of the tools I use are either built into
Windows 2000 or freely available from Microsoft, and all of them are
well documented. Some of the most important reference sites that you
can visit are:
WSH:
http://www.msdn.microsoft.com/library/default.asp?url=/library/en-us/scr
ipt56/html/wsoriWindowsScriptHost.asp
ADSI:
http://www.msdn.microsoft.com/library/default.asp?url=/library/en-us/net
dir/adsi/adsi_reference.asp
WMI:
http://www.msdn.microsoft.com/library/default.asp?url=/library/en-us/wmi
sdk/r_wmicls_6r6t.asp
Hopefully, my examples and the above references will help you create
automated security enforcement solutions tailored to your environment.
As I'm yet ignorant about many aspects of NT/2000, please forgive any
misinformed statements I may make in the paragraphs below, and feel free
to point them out to me.
Finally, I just want to throw this out and see what happens: I'm looking
for a better job. My resume can be found at
http://www.bol.ucla.edu/~everblue/resume.html.
All my scripts are Windows Scripting Host scripts, authored mostly in
JScript, and partly in VBScript when necessary.
--------------------------------------------------------
Software Installation script:
Keeping systems up to date with fixes is a challenge to any
administrator of Microsoft networks. The purpose of this script is to
automatically install any software that cannot be handled by Windows
Installer packages distributed through GPOs. Such software include:
-Service Packs
-Hotfixes
-Internet Explorer Updates
-Office 2000 updates that are not available as Windows Installer
patches, and cannot therefore be integrated into the Office 2000 MSI
package.
-Any legacy software that are not available as Windows Installer
packages, and is unsafe to repackage into MSI files.
Windows Installer can perform much of the automated installation of
*end-user* applications, but it has a fatal limitation of not being able
to replace any files protected by the System File Protection feature.
This limitation renders it useless in automating the installation of
service packs, hotfixes, Internet Explorer, and the like, which do
replace system files.
Installing updates through a combination of scripting and Windows
Installer also eliminates the need for disk images. With disk images,
the same task--keeping software up to date--requires you to devise two
update plans, one designed for images and another for existing
installations. In contrast, when all software is installed and updated
dynamically, both new and existing installations are taken care of by a
single system.
Let's see how service packs and hotfixes are handled in the script:
+ Service packs
The latest service pack is stored in a DFS network folder such as
\\domain\dfsroot\installers\sp\#, where # is the service pack number.
The installation routine first checks if the operating system is Windows
2000, and then obtains the latest version of service pack already
installed by parsing the value of
"HKLM\Software\Microsoft\WindowsNT\CurrentVersion\CSDVersion" with a
regular expression. If the latest service pack number, obtained from
the network service pack folder, has not been installed, the script
performs a silent installation by executing update.exe with the -u -n -o
parameters. After the installation completes, the script quits, and the
computer reboots.
+ Hotfixes
Hotfixes pertaining to both Windows 2000 Professional and Server are
stored in a DFS network folder such as
\\domain\dfsroot\installers\hotfixes. Those that pertain only to Server
are stored in a subfolder named server. All NT/2000 hotfixes are
standard packages that behave the same way, and they can all be run
silently without issues. All hotfixes also have a standard naming
convention, in the form of Q######_w2k_sp#_x86_en.exe, and it is from
their names that we determine whether it should be installed given the
service pack version.
The installation script first browses the network hotfixes directory,
dumps all the hotfix files names and paths into an in-memory ADO table,
and sorts them by date; if this is Windows 2000 Professional, server
hotfixes will not be included. The script then goes through each hotfix
and checks in the registry if it's already installed by looking for the
presence of its Q number in the
"HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Hotfix" registry key.
If the hotfix is not registered as installed, the script compares the
service pack number in its file name to the service pack number
installed on the computer. For example, if Service Pack 2 is present,
only pre-SP3 hotfixes (that is, those file names with _sp3_ in the
middle) need to be installed.
Those hotfixes that have not yet been installed and are not included in
the current service pack are installed in order of their modified dates.
The hotfixes are executed silently with the switches -m -z -n. Reboot
is disabled, and all hotfixes are installed in one batch. After all the
hotfixes have been installed, qchain.exe, available from Microsoft, is
run as an extra measure of preventing new files from being written by
old ones (although installing hotfixes by date should already be
sufficient for this purpose). Once the entire process has been
completed, the script checks to see if there's a value in
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager named
PendingFileRenameOperations. If such a value is present, it means that
some files are in use and await to be replaced at the next reboot, and
the script accordingly terminates and executes shutdown.exe (from the
resource kit) placed on a network share to reboot the computer.
Of course, there are many ways this scheme can go wrong, and I have
taken them into account. For example, what if Microsoft re-releases a
"fixed" hotfix under the same file name? How then can the script
determine that the hotfix needs to be reapplied? To deal with this
scenario, my script records somewhere in the registry the modified date
of every hotfix it installs, and when determining which hotfixes need to
be applied, it checks these dates in addition to the presence of the Q
number in "HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Hotfix". If
a hotfix is recorded to have already been installed but the file is
newer, it is reapplied.
Another potential pitfall is this: if you have missed posting a hotfix
to the network share, and later hotfixes updated some, but not all of
files that it contained, then posting this hotfix now will overwrite
those files with older versions. Bearing this in mind, I wrote the
script so that after installing a hotfix that is earlier than some other
hotfixes already present, all subsequent hotfixes are automatically
reapplied.
This script presently has no ability to determine the need for a
particular hotfix depending on the exact services available on a
particular computer. This may seem problematic, since every hotfix
registers themselves as installed even if the feature it's supposed to
fix--say, IIS--is not present. When IIS is installed at a later date,
the hotfix is overwritten.
In reality, this seldom happens because server roles remain fairly
constant at most places. And when you do add a feature to a server, a
task which requires manual operations anyway, you can simply delete the
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Hotfix key, so that the
next time the script runs all hotfixes will be reapplied. At my
organization, I take the additional precaution of running a scheduled
script that in turn runs the hfnetchk.exe tool on all computers in the
domain, parses the results using regular expression, condensing it down
to only those computers with problems, and then send the condensed
report to me via e-mail, if necessary.
(A side note: You need not worry about unneeded hotfixes bloating your
Windows 2000 installation. Hotfixes will not replace files that are not
already there, though they will still record themselves in the registry
as installed. That, at least, has been my experience.)
Finally, the hotfix installation routine does not yet handle hotfixes of
separately sold server products like Exchange and SQL. But you can also
automate those with similar methods.
This script is assigned to all workstations and servers as a startup
script. Since servers cannot tolerate rebooting all the time, I also
create, on each server, a scheduled task, that runs the same script
using a special switch that turns on a hotfix-only mode. In this mode,
when new hotfixes are found and installed, and a reboot is necessary,
instead of rebooting by itself, the script sends an e-mail message
alerting the administrator to the need to reboot, thus ensuring that
services provided by the server are not interrupted in an untimely
fashion.
The e-mail alert functionality is provided by a freeware command line
program called BLAT, which can be found at
http://www.interlog.com/~tcharron/blat.html. You use it by running the
executable in your script and passing it parameters.
This task is run under local system context in order to avoid caching a
domain user name and password. You will need to use the "at" command to
create such a task.
(Another site note: there's a big difference between Windows 2000 and
NT4 in the way the local system account accesses network resources. In
NT4, the local system can only access network resources through a null
session, making any such proposition a security risk. In Windows 2000,
however, the system account access the network under the security
context of the computer account in the domain, and computer accounts can
now belong to groups and be assigned permissions to resources. This new
capability is what makes this script possible, allowing it to grab
installation files from the network without relying on a domain user
account.)
--------------------------------------------------------
Password randomization script:
One of the most overlooked security risks is the local administrator
accounts on member workstations and servers in NT/2000 domains. Since
most sane administrators manage their computers through highly
privileged domain accounts, local admin accounts are almost never used.
Yet they cannot be disabled. Should an intruder crack the generic
password often assigned to such accounts, he/she gains full access to
the infiltrated computer, and can potentially elevate his/her privileges
to threaten the entire network. As a simple example, reference to a
malicious program can be implanted in the Run registry key under
HKLM\Software\Microsoft\Windows\CurrentVersion. When an administrator
with domain-wide privileges logs onto the infiltrated computer, this
program will launch under the administrator's security context and go
about the domain unimpeded.
(BTW, I never use domain admins accounts to administer workstations.
Instead, I create a separate global group called Workstation
Administrators, and assign it to the local administrators groups of
workstations through the Restricted Groups feature of security
templates, and propagated through GPOs. You seldom need full domain
admins privileges when troubleshooting workstations, yet you don't want
to have to enter a unique name and password to administer every
workstation. This solution is a good compromise between security and
convenience.)
The alert administrator is thus confronted with the difficult task of
keeping the administrator account secure and distinct on each and every
workstation on the network. At the same time, local admin accounts are
occasionally needed and there needs to be a safe and convenient way to
keep track of the unique passwords assigned to each such account. In my
organization, this is accomplished through a password randomization
script.
The script utilizes ADSI to browse the Active Directory or NT domain
(the script accepts a parameter specifying the exact LDAP path to start
searching), finding all servers and workstations. One by one, the
script uses ADSI to access each computer's SAM database and looks for
the account with the RID 500, which is the administrator account, giving
it a random name and password (of specifiable lengths), and stores it in
an Access table through ADO along with the computer name and the date.
The script also finds the guest account (with the RID 501), also
randomizes it, and then disables it. Just to make the safeguard
complete, the script then creates two dummy accounts, administrator and
admin, each provided with a long, randomized password, so that the
potential intruder will spend enormous effort cracking the password only
to find it without privileges.
The database file is located in a network folder secured with ACL. On
occasions you absolutely need to access the local admin account on a
member computer, you can simply print its record from the database.
This script is run as a scheduled task under a domain admin account on a
secured computer dedicated to these purposes. All traffic to and from
this computer is encrypted using IPSec.
Also note that certain characters are illegal in user names, and
characters unavailable on the keyboard, and that cannot be easily
recognized from a printout of the database will render the
username/password useless in time you actually need to use the local
administrator account. You will need to take these factors into account
when designing your random-string algorithm.
Additionally, to make the dummy accounts truly without privileges you
will need to combine this script with security templates and GPOs, which
you should use to replace references in NTFS, Registry, and privileges
DACLs to "Authenticated Users" and "everyone" groups with the "users"
built-in local group wherever possible. This is necessary because if
the dummy account authenticates successfully, it will be treated as
among "authenticated users" even if it belongs to no explicitly assigned
groups. An exception to this rule is the Network Access privilege,
which must be given to "authenticated users" on all computers;
otherwise, users connecting to remote printers will find themselves
unable to check on the status of their print jobs (this operation in
Win2K requires the print server to be able to authenticate with the
user's computer, and computer accounts are not members of the Domain
Users group, and therefore do not belong in the local "users" group on
each member computer).
To top it off, you should also use security templates/GPOs to enforce
strict anonymous access so that anonymous users cannot iterate the SAM
account database. If this step is not taken, the purpose of randomizing
the administrator name will be defeated.
I advise not applying this script on domain controllers, as I'm sure
everyone uses the domain Administrator account on a daily basis to
administer their servers and won't be very happy to find themselves
unable to log on the next morning because it's been randomized. (Like
local administrator accounts, the domain administrator account is also a
built-in account with the fixed RID 500.)
I will stop here now to allow digestion. If people find this
information helpful, I will post some more examples.
======================================
Delivery co-sponsored by Trend Micro, Inc.
======================================
BEST-OF-BREED ANTIVIRUS SOLUTION FOR MICROSOFT EXCHANGE 2000
Earn 5% rebate on licenses purchased for Trend Micro ScanMail for
Microsoft Exchange 2000 between October 1 and November 16. ScanMail
ensures 100% scanning of inbound and outbound traffic and provides
remote software management. For program details or to download your
30-day FREE evaluation copy:
http://www.antivirus.com/banners/tracking.asp?siS&BI;$5&UL;=http://www.ant
ivirus.com/smex2000_rebate
- Previous message: Russ: "Re: NTFS inherited permissions bug on W2K"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
