In a previous article, I extolled the virtues of DNS on Windows. In particular, I love the scripting interface that DNSCMD provides. In that article, I claimed: “Need to create 500 host records, both forward and reverse, in different domains and subnets? DNSCMD can do it with a 1-line script… there is no *nix alternative that is this simple or powerful.” Well, enough people have been bugging me to provide it so here is is:

REM### Copyright 2008 William L. Dougherty
REM### Script for bulk uploading DNS records into Windows DNS
REM### Script requires hosts.txt file in format: FQDN,IPADDR 1 host per line
REM### Example:
REM######host1.domain.com,192.168.1.1
REM######host2.domain.com,192.168.1.2
for /F “tokens=1-7 delims=,. ” %%a in (hosts.txt) do dnscmd /recordadd %%b.%%c %%a a %%d.%%e.%%f.%%g && dnscmd /recordadd %%f.%%e.%%d.in-addr.arpa %%g ptr %%a.%%b.%%c

Just put it into a batch file and you are good to go. Simple, right? Well, maybe I should explain. The basic concept here is we use a for loop to iterate through a text file, parsing the components into variables. We then feed these variables into dnscmd to create the A (host) record, and feed them a second time into dnscmd to create the PTR record. I tend to use for loops in a lot of my scripts, because they are an easy way to execute repetitive commands in batch files.

The above script takes as input a file named hosts.txt that must be located in the same directory as the script being executed. This files should be in the format FQDN,IPADDRESS. This script will work with either Active Directory Integrated, or Primary zones, but it does require the zones already exist on the server.

So what do you do if the zones don’t already exist? Another simple script will take care of this. Just iterate through the same list, and create the zone files first. If the zone already exists, then Windows will throw an error to the console, but there are no other bad consequences, so running this every time is fairly benign. You just need to know in advance whether you want Primary or Active Directory Integrated zones. Here are the scripts for each:

Active Directory Integrated:
for /F “tokens=1-7 delims=,. ” %%a in (hosts.txt) do dnscmd /zoneadd %%b.%%c /dsprimary && dnscmd /zoneadd %%f.%%e.%%d.in-addr.arpa /dsprimary
Primary:
for /F “tokens=1-7 delims=,. ” %%a in (hosts.txt) do dnscmd /zoneadd %%b.%%c /primary /file %%b.%%c.dns && dnscmd /zoneadd %%f.%%e.%%d.in-addr.arpa /primary /file %%f.%%e.%%d.in-addr.arpa.dns

As one of my co-workers is fond of saying, “it’s too easy!” DNSCMD has many, many other options. Two of my favorites are /enumzones and /enumrecords. Using these two options, you can easily dump all your DNS records into text files. I’ve used this to back up my records every night, and I’ve also used this for change control. Dump the files nightly and diff them to the previous night, and you’ll know what changed. This script creates a seperate text record for each of your zones:

dnscmd /enumzones > zones.txt
for /f %%a in (zones.txt) do dnscmd /enumrecords %%a @ > %%a.txt

DNSCMD gives you a scriptable interface into anything/everything you need to administrate zones and records on Windows. Learn to love it, and you’ll never go back to Bind.

The first script in the series is a Windows Services lockdown script for Windows XP & 2003. Disabling services is generally a good idea to reduce the threat profile of your computer, and to improve its performance. Every security guide out there tells you to disable unnecessary services. A few of them also give some guidance as to which services are unnecessary. Few of them tell you how to disable them consistently.

There are three ways to disable services: 1) Use the Services MMC GUI. This is a time consuming process and is prone to mistakes. 2) Use Group Policy. This works well for environments that use Group Policy, but is harder to implement for stand-alone servers, such as web servers. 3) Use the sc.exe command line utility.

If you do not know the sc command, learn it! sc is a powerful utility for controlling services on local or remote hosts. sc will let you configure how services start, change the user account and password they run under, and start/stop/pause the services. The basic syntax of sc is:

sc <server> [command] [service name] <option1> <option2>

We are going to use 2 different sc commands in our service lockdown script: config & stop. These should be self explanatory, but config will allow us to disable the service, and stop will stop the service. To make this work, we need three files: 1) The script batch file; 2) a list of servers by name called hosts.txt; 3) a list of services we want to disable called services.txt. The two text files must be in the same directory as the batch file. The code is fairly simple:

REM***(c) 2007 William L. Dougherty
REM***Script created by Bill Dougherty to disable services on Windows 2003 & XP
for /f %%a in (hosts.txt) do call :serviceconfig %%a
goto :eom
:serviceconfig
for /f %%b in (services.txt) do (sc \\%1 config %%b start= disabled)
for /f %%c in (services.txt) do (sc \\%1 stop %%c)
:eom

Pretty simple, huh? We loop through a list of servers, and then for each server, we loop through a list of services. The service list must be the service name and not the display name of the services. Some service names are less than intuitive, such as the service name for IPSEC Services is PolicyAgent. You can get the service name from the services MMC by clicking the service and looking at its properties, or from the command line using sc query. Either way, once you build your service list the first time, you’ll rarely need to revist this.

This script requires you to have administrator access on the target host. This works great in a domain environment, but what if you are dealing with stand-alone servers? You can still use this script so long as the user credentials you are logged in as have admin access on the target. If not, the you’ll need to log into each server and run the script locally. If this is the case, you only need the script file and the list of services. You should modify the script like this:

for /f %%b in (services.txt) do sc config %%b start= disabled
for /f %%c in (services.txt) do sc stop %%c
:eom

This script works with both Windows XP and Windows 2003, although the two platforms have different services. There are several good sources for figuring out which services are unnecessary. I highly recommend the TechRepublic guides: XP Services Guide and 2003 Services Guide. Over the years, I have developed my own lists. I highly recommend you spend the time to research these services, and test the impact of disabling them BEFORE you run this script against your production network!

Windows 2003 services that can be disable:

Alerter
AppMgmt
ClipSrv
TrkWks
TrkSvr
MSDTC
ERSvc
helpsvc
HidServ
ImapiService
IsmServ
LicenseService
Messenger
mnmsrvc
NetDDE
NetDDEdsdm
nla
NtLmSsp
WmdmPmSM
appmgr
RemoteAccess
SCardSvr
SENS
LmHosts
TapiSrv
TlntSvr
Tssdis
Themes
uPS
uploadmgr
WebClient
AudioSrv
stisvc
WZCSVC

Windows XP services that can be disabled:

Alerter
AppMgmt
ClipSrv
TrkWks
MSDTC
ERSvc
FastUserSwitchingCompatibility
helpsvc
HidServ
CiSvc
Messenger
mnmsrvc
NetDDE
NetDDEdsdm
nla
NtLmSsp
SysmonLog
WmdmPmSM
RSVP
RemoteAccess
SCardSvr
SSDPSRV
LmHosts
TapiSrv
TlntSvr
Themes
uPS
upnphost
WZCSVC

I hope you find this script useful. Check back often for additional scripts in the series.

-Bill

Fortunately, it is possible to perform a rapid clean up if you follow a simple process, and use tools to help. This process is specific to the platform the administrator supported. The process for cleaning up after a Windows administrator is as follows:

1. Create a list of all servers in your environment. If you aren’t sure, check DNS and Active Directory
2. Search Active Directory for all users with privileged (admin) group memberships
3. Search every server for services that run under domain or local accounts instead of LocalSystem or NT
4. Search every server for scheduled tasks that run under domain or local accounts
5. Change the password on every privileged user account. Assume that the old admin could have had access to every account at some point.
6. Change the password on every service and scheduled task to match the new passwords in step 5.
7. Change any service or scheduled task that runs under the old admin’s account to run under a new service account
8. Review any scheduled tasks that are scripts, to make sure you know what they do. A clever admin could bury a script to recreate his admin account inside of another script.
9. Disable the old admin account

There are many good commercial tools available for searching servers for service accounts and scheduled task accounts, but I’m a big believer in using simple scripts where possible to get the job done. If you want a commercial product to help, check out:

• ScriptLogic Service Explorer
• Service Account Manager

If like me, you hate to spend good money for tools that duplicate the built-in power of Windows, then these scripts are for you:

Code:

This script does a couple of basic things, but it does them well. First, it prints out the group memberships of the four Windows admin groups. This tells you which accounts need to be changed. Second, it searches every server listed in the “servers.txt” file for any services running under a domain or local account, instead of LocalSystem or NT. This tells you which services need to be changed. Lastly, it tells you every scheduled task running on every server in the “servers.txt” file. This tells you which scheduled tasks need to be changed. Once you have your lists of services and tasks that need to be updated, you can also script the update.

Code to update Scheduled Tasks:

REM ***Create a new document called tasklist.txt with 2 columns, separated by a comma.
REM ***Column 1 should be the server name. Column 2 should be the scheduled task name
REM ***EXAMPLE: server1,task1
REM ***These names can be extracted from the checkthesetasks.txt file
set /P newpassword=Enter the new password you want each scheduled task to run with:
for /f “tokens=1-2 delims=,” %%a in (tasklist.txt) do (schtasks /change /s %%a /RP %newpassword% /TN %%b)

Code to update Services:

REM ***Create a new document called servicelist.txt with 2 columns, separated by a comma.
REM ***Column 1 should be the server name. Column 2 should be the service name
REM ***EXAMPLE: server1,service1
REM ***These names can be extracted from the checktheseservices.txt fileset /P newpassword=Enter the new password you want each service to run with:
for /f “tokens=1-2 delims=,” %%a in (servicelist.txt) do (sc %%a config “%%b” password= %newpassword%)

After you have changed the services and scheduled tasks, you should be safe to disable the old admin’s account. Although the above scripts apply to Windows servers, the same concepts can be applied to other platforms: Identify any processes/services/scripts that run with privileged user access and change them; Identify all privileged accounts and change them as well; Remove the admin’s account from the system.

This process is not foolproof. A determined, disgruntled admin could install rootkits, keyloggers, trojans, and logic bombs prior to leaving. Administrators are GOD on their systems, so the only defense against this is to diligently screen your admins before you hire them. This process WILL allow you to locate and clean up access that was legitimate when it was created, even if it is not well documented. I hope you find these scripts useful.

-Bill

Digg This Story!