8 Tips for Avoiding the Next Big Worm

Modern worms such as Nimda and CodeRed are blended threats that use multiple propagation methods and exploits to spread rapidly. Such worms infect one computer, then from that system attack others, so a seemingly unimportant computer that becomes infected can easily cause damage to more important machines. Therefore, you need to protect every computer on your network—not only systems with crucial information or processes. In addition to virus scanning and border firewalls, you need to implement layers of defense at each workstation and server.

It's only a matter of time before the next big worm hits, but you can take steps now to prepare your Windows 2000 systems to resist it. The following eight tips can help you protect workstations and servers behind the firewall. Sound like a lot of work? Don't worry—you can use nifty built-in Win2K tools such as Group Policy, IP Security (IPSec), and startup scripts to automate much of the process.

1. Disable Unused Services
One way in which Nimda spreads is by looking for servers and workstations running Microsoft IIS, then using an IIS bug to infect those computers. Disabling all unneeded services and features is the most effective way to protect systems against future threats. How many computers on your network truly need to run IIS, and exactly which services within IIS (e.g., FTP, SMTP, Network News Transfer Protocol—NNTP) are necessary on even those systems? Nimda attacks the WWW service (aka the World Wide Web Publishing Service), but who's to say the next worm won't attack a vulnerability in Telnet? I recommend you disable the following services by default on workstations and servers: ClipBook, FTP Publishing, IIS Admin, Indexing, Internet Connection Sharing (ICS), NetMeeting Remote Desktop Sharing, NNTP, Remote Registry, Routing and Remote Access, Simple TCP/IP, SMTP, Telnet, Terminal Services, World Wide Web Publishing Service, and Windows Media Services (WMS). For more information about the potential problems related to these services, see my three-part Web-exclusive series "Dangerous Services," http://www.secadministrator.com, InstantDoc ID 16301, InstantDoc ID 16363, and InstantDoc ID 16476. For more information about Win2K Server services in general, see Jordan Ayala, "Win2K Server Services, Part 1," November 2001, InstantDoc ID 22541, and "Win2K Server Services, Part 2," November 15, 2001, InstantDoc ID 22762.

Even when your default installation image excludes the services that you want to disable, users can easily install such services without your knowledge after you've deployed a computer. Consider editing the Default Domain Policy Group Policy Object (GPO) to disable the services by default. See the Web-exclusive sidebar "Disabling Services by Default," http://www.winnetmag.com, InstantDoc ID 26394, for instructions. Be aware that when you edit a GPO to disable or enable services, Win2K populates the GPO with the services it finds on the computer from which you're working. Therefore, edit the GPO from a computer that already has all the relevant services installed.

What about computers that need to access one or more disabled services? For example, what about workstations that need to access the IIS WWW service for use with Microsoft FrontPage? You can create exception GPOs that enable appropriate services for the computers that need them. See the Web-exclusive sidebar "Enabling Disabled Services on Certain Systems," http://www.winnetmag.com, InstantDoc ID 26392, for details.

2. Lock Down IIS
CodeRed relied on IIS's support for the Internet Printing Protocol (IPP). I don't know anyone who uses IPP, but IIS's script mappings (aka Internet Server API—ISAPI—filters, application mappings, or ISAPI mappings) enable it by default. For those computers on which you need to install IIS, bear in mind that most IIS exploits depend on features that users typically don't need. You can and should disable such features on most Web servers, and Microsoft provides a great tool to automate the process: the IIS Lockdown Wizard. The wizard installs the IIS Lockdown Tool, which disables unneeded features such as script mappings, removes sample files and directories, removes unneeded services such as WWW Distributed Authoring and Versioning (WebDAV), and strengthens default permissions. The wizard also installs URLScan, an ISAPI filter that looks for and blocks suspicious content in URL requests. (For more information about URLScan, see "Protect Your IIS Server with URLScan," http://www.windowswebsolutions.com, InstantDoc ID 25230, and "Deploy URLScan to Protect Your IIS Server," InstantDoc ID 25581.)

To take advantage of the IIS Lockdown Wizard, download iislockd.exe from http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/tools/locktool.asp. Run

iislockd.exe /q /c /t:c:iislockd

to unpack the wizard's files to the C:iislockd folder. The iislockd.chm file contains the wizard's documentation. When you have many IIS computers to lock down, consider running the wizard in unattended mode, which the file runlockdunattended.doc documents. To run the wizard on all the computers in an Active Directory (AD) group, you can configure a startup script in a GPO. For example, you can use a startup script in the FrontPageWorkstationsPolicies GPO to run the wizard on all the systems in the sample FrontPageWorkstations group. Win2K automatically runs startup scripts each time a computer reboots, so you need to add some special logic to prevent the wizard from rerunning each time the computers reboot.

To configure the sample startup script, edit C:iislockdiislockd.ini in Notepad or another text editor. Set the UnattendedServerType option to the server template you want to use. (A server template defines the options to enable or disable according to how you're using IIS. For example, you don't want to disable certain features if you use FrontPage. The iislockd.ini file contains 14 server templates, matching common types of IIS servers, after the [Info] section. Each template begins with the template's name in brackets, followed by a longer label name and the template options.) For our example, set UnattendedServerType to frontpage, as follows: UnattendedServerType=frontpage. Set Unattended=TRUE and save the file.

Next, create a batch file called LockDownIfNotAlreadyDone.bat and add the following lines:

if exist %systemroot%iisalreadylockeddown exitiislockdmd %systemroot%iisalready lockeddown

Open the Microsoft Managament Console (MMC) Group Policy console to edit the FrontPageWorkstationsPolicies GPO. In the left-hand pane, select Computer ConfigurationWindows SettingsScripts (Startup/Shutdown), then double-click Startup in the right-hand (aka details) pane to open the Startup Properties dialog box. Click Show Files to display the contents of the Startup folder. Create a new subfolder and name it iislockd. Copy the contents of C:iislockd to Startupiislockd. Return to the Startup Properties dialog box and click Add. Click Browse, then maneuver to Startupiislockd and double-click LockDownIfNotAlreadyDone.bat. Click OK. The list in the Startup Properties dialog box now includes LockDownIfNotAlreadyDone.bat. Any computer that applies the FrontPageWorkstationsPolicies GPO will automatically run the IIS Lockdown Wizard. The next time the computer boots and runs LockDownIfNotAlreadyDone.bat, the batch file will notice that the iisalreadylockeddown folder exists and will terminate.

3. Lock Down the Server Service
Given what we know about Nimda, which propagates by inserting itself into files in shared network folders, you can expect future worms to target executables and documents in shared folders. The Win2K Server service, which is enabled by default on workstations as well as servers, provides file sharing as well as network access to services, event logs, and scheduled tasks. Although you might consider disabling the Server service on workstations, doing so prevents you from remotely administering the workstation through the MMC Computer Management snap-in. For computers on which you can't or don't want to disable the Server service, you can use two user rights—Access this computer from the network and Deny access to this computer from the network—to lock down connections through the service. Users who don't have the Access this computer from the network right or who do have the Deny access to this computer from the network right on a system can't connect to any resource that the Server service makes available on that computer.

Typically, the only people who need to connect remotely to a workstation are workstation-support staff. You can create a WorkstationSupport group, then create a GPO that applies to all your workstations. If you have a Workstations organizational unit (OU), link the GPO to that OU. Then edit the GPO (under Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment) to assign the Access this computer from the network right to that group only.

Preventing shared file­based propagation on servers is more difficult because those systems must permit connections from a wider range of users. However, you can take some measures to reduce exposure. First, consider who truly needs to access the server through the Server service. On computers that aren't file servers—for example, enterprise resource planning (ERP) or database servers—users might not need access to the file system or other resources that the Server service makes available. In that case, you can restrict the Access this computer from the network right to administrators and other accounts that connect to shared folders or other Win2K resources on the computer.

Second, for file servers and other computers on which the Server service needs to be available, consider whether everyone in the forest truly needs access. Usually, only some subset of users (i.e., a particular department or group) needs access to the server. By default, the Everyone group, which includes all users in the forest, has the Access this computer from the network right. By scaling this right back to a subset of users, you can limit the accounts that intruders can use to attack your server through the Server service.

Third, establish an in-depth defense strategy. Don't forget that basic security measures such as strict file permissions go a long way in containing how far a worm can spread. Limit Write and Create permissions throughout the domain to only those users that truly need them, and follow the principle of least privilege whenever possible.

4. Use IPSec to Lock Down Network Access to Computers
Most networks are fully routed without internal firewalls, so a worm that succeeds in infecting one computer through email or an infected Web page can then attack all the other computers in the organization's network. Seldom does a workstation truly need access to every other computer on the network. Using internal firewalls and LAN segments to chop your network into discrete zones of permitted traffic would be prohibitively expensive and complicated, but IPSec offers some fantastic possibilities for slowing down or even preventing a worm from spreading within your network. You can use Group Policy to deploy IPSec policies easily and automatically to computers throughout your AD domain. These IPSec policies can be simple packet filters that block access to certain ports on your computer according to IP address, or you can formulate more sophisticated policies that use IPSec's strong authentication, integrity checking, and encryption capabilities.

Keep in mind that you aren't trying to protect individual computers—you're trying to protect your network and slow down or limit the spread of a worm. Therefore, you need a broad deployment of the IPSec policy to all servers and workstations throughout the AD forest. Limiting each computer to accept packets only from the other computers with which that system needs to communicate would be nice, but compiling and maintaining a list of permitted systems for each computer would be onerous. Instead, you need to base your IPSec policies on generalizations about network traffic.

Unless you use Windows NetMeeting or certain forms of Instant Messaging (IM), your workstations have little need to communicate with other workstations. CodeRed and Nimda spread from workstation to workstation, not just from workstation to server. Therefore, I suggest that you prevent workstation-to-workstation communication. The easiest way to mandate such a policy is to use IPSec in Authenticated Header (AH) mode, which lets a system accept only packets that truly come from the computer that claims to have sent them. The only disadvantages to using AH mode are a small performance degradation on servers—workstations aren't usually affected—and the fact that network analyzers will see the traffic as IPSec AH mode packets instead of as ordinary TCP or UDP packets. Instead of using AH mode, you could configure IPSec to permit or block traffic based on IP address so that workstations reject other workstation traffic. However, this approach requires that your servers reside on subnets that are separate from your workstations so that your packet filters can distinguish between workstation and server traffic.

You can specify Kerberos, preshared key, or certificate authentication. Kerberos isn't useful in our scenario because every computer in the AD forest automatically supports Kerberos authentication. You need to use preshared key or certificate authentication so that you can control which computers can communicate with one another. Preshared key authentication is simpler than certificate authentication, which requires setting up a Certificate Authority (CA), so let's look at an example of how to use preshared key authentication to prevent workstation-to-workstation communications.

To accomplish this goal, you need to create two IPSec policies: one for workstations and one for servers. The workstation policy will require workstations to use IPSec AH mode communication, authenticated with a designated preshared key; you'll add an exception to the workstation policy for traffic between workstations and external Web servers on the Internet. The server policy will respond to computers requiring AH mode with the designated key. To implement this solution, you first need to create a Workstations OU and a Servers OU, add your workstations and servers as members of the applicable OU, then create OU-linked GPOs to implement the IPSec policies. See the Web-exclusive sidebar "Using IPSec to Prevent Workstation-to-Workstation Communication," http://www.winnetmag.com, InstantDoc ID 26393, for instructions.

Restricting workstation-to-workstation traffic is just one way you can use IPSec to slow down worm propagation. You can tailor your IPSec policy to restrict traffic to appropriate servers or to specify permitted traffic types between physical sites so that worms can't spread easily from one building or city to another. In such scenarios, however, good impact analysis and a thorough understanding of the traffic on your network is important so that you don't accidentally block legitimate communications.

5. Safeguard Administrative Authority
With worms such as Nimda, simply browsing the Internet or reading email puts you at risk of infecting your workstation (and the rest of the internal network). And if you're logged on with administrative authority when you inadvertently trip across a worm, the worm can spread even farther and faster. Therefore, following a few best practices (such as the principle of least privilege) with accounts that are part of the Administrators, Domain Admins, or Enterprise Admins groups is essential.

First, give each administrator two accounts: one with administrative authority and one without. Instruct administrators to log on to the unprivileged account to use email, open Microsoft Office documents, browse the Internet, or engage in other activities that could execute malicious software (malware). Administrators should use the administrative account only for activities that truly require its authority (e.g., using the MMC Active Directory Users and Computers snap-in or the Computer Management snap-in). The best way to help administrators remember to follow this rule is to make it a policy never to log on with an administrative account. Instead, administrators should always log on with their nonadministrative accounts. When an administrator needs administrative access—for example, to use the Active Directory Users and Computers snap-in—he or she should press Shift+Ctrl and right-click the applicable shortcut, then select Run as to open the Run As Other User dialog box that Figure 1 shows. In that dialog box, the administrator enters the username, password, and domain for his or her administrative account, then clicks OK to run the chosen program under the administrative account. (Be aware, however, that Win2K's Runas service has a logical consistency problem. A full explanation is outside the scope of the article, but consider the following example. If you use the Runas command to start Microsoft Outlook under Administrative authority and an incoming email message launches a browser session, the browser session will also run in the Administrator's context.)

6. Delete Dangerous File Associations on Workstations
Many worms and viruses depend on file associations to execute malicious attachments. Although training users not to open suspicious attachments is a good start, deleting file associations for dangerous files such as .bat, .cmd, and .vbs files is a safer strategy. (Visit http://www.novatone.net/mag/mailsec.htm for a list of file associations you should consider disabling on workstations throughout your network.) When you delete such associations, make sure that doing so won't break any legitimate scripts you depend on. For example, if you want to delete the file association for .vbs files but have a shortcut on your Start menu to a script called update.vbs, you need to change the shortcut so that it doesn't directly link to update.vbs but instead runs wscript update.vbs.

Manually deleting all those script mappings on each workstation in your network would be laborious. Instead, you can create a .reg file to do the work for you. To delete the file association for .vbs files, open Notepad or another text editor, then create a file with the following lines:

REGEDIT4[-HKEY_CLASSES_ROOTVBSFile]

REGEDIT4 is a required header that specifies the file type. Copy and edit the second line for each file association you want to delete, replacing VBS with the appropriate extension (e.g., CMDFile). Name the file deleteFileAssociations.reg and save it. Open a command prompt on the local system (to delete the association on the local system only), and type

regedt32 /s deleteFileAssociations.reg

to instruct regedt32 to delete the specified registry subkeys under the HKEY_CLASSES_ROOT registry key, which is where Windows stores file associations. (The sample file, for example, tells regedt32 to delete the VBSFile subkey.) You can use Group Policy and startup scripts (as I described in Tip 2) to deploy the .reg file to all your workstations and execute the file automatically.

Keep in mind, however, that installing a service pack or update can reassociate deleted file associations. Therefore, instead of deleting associations, you might consider reassociating offending file extensions to a harmless program (e.g., notepad.exe) or using a security template to deny Read access for the HKEY_CLASSES_ROOT registry subkeys that correspond to the file associations that you want to disable.

7. Lock Down IE
Nimda spreads through infected Web pages; future worms will certainly follow suit. Even with the built-in security features in Java and other scripting languages, attackers have found many ways to access files on browsing computers' local drives, then access resources on your company's networked servers. Microsoft Internet Explorer (IE) has more than 20 security options that you can customize for four zones: Internet, Local intranet, Trusted sites, and Restricted sites. Disabling ActiveX and scripting is the safest practice but will probably cause complaints from users. A detailed discussion of IE security options is outside the scope of this article but is provided in my six-part series beginning with "Internet Explorer Security Options, Part 1," http://www.secadmininstrator.com, InstantDoc ID 20468.

After you decide on the IE settings you want to use, you don't need to configure them all manually for each workstation: Group Policy comes to the rescue again. In the Active Directory Users and Computers snap-in, edit the Default Domain Policy GPO to open the Group Policy console, then select User ConfigurationWindows SettingsInternet Explorer Maintenance to find options for fully configuring IE's security zones. Then, select User ConfigurationAdministrative TemplatesWindows ComponentsInternet Explorer to find options for disabling users from reconfiguring IE to get around your policies. See "Internet Explorer Security Options, Part 6," http://www.secadministrator.com, InstantDoc ID 21282, for more information and instructions about using Group Policy to control IE. Keep in mind that editing IE security zones might affect Outlook and Outlook Express's behavior because both those applications base their treatment of HTML-based email on IE's security zones.

8. Keep IE, Applications, and Windows Up-To-Date
Almost every week, new vulnerabilities are discovered in Microsoft products (as well as other vendors' products) and new patches are released. CodeRed and Nimda exploited well-known vulnerabilities for which patches had been available for some time. The only way to protect yourself against many vulnerabilities is to load the appropriate patch on a timely basis.

You need to keep more than just Windows and IE up-to-date. Worms can spread through Office, IM programs, and other applications. Whenever your organization begins using a new piece of software on the network, you need to accept responsibility for monitoring and deploying security-related patches. Microsoft Software Update Services (SUS) and Automatic Updates can help (see http://www.microsoft.com/windows2000/windowsupdate/sus/susfaq.asp for more information). And if you set up the proper infrastructure, you can use Group Policy and a few simple scripts or batch files to simplify the task. (For complete instructions and sample code, see "Updating Service Packs and Hotfixes with Boot Scripts," http://www.secadministrator.com, InstantDoc ID 15953.) You can also use Hfnetchk or Microsoft Baseline Security Analyzer (MBSA—which includes Hfnetchk) to scan your network for computers that are missing important security patches.

Think Ahead
Today's blended threats are sophisticated, and you need a sophisticated, multilayered defense strategy to stop them. Besides using perimeter defenses (such as those that Roger A. Grimes describes in "Putting Down an Email Attack," http://www.secadministrator.com, InstantDoc ID 23656, and "Where to Place Your Antivirus Defenses," InstantDoc ID 24050), you can disable unneeded functionality and limit traffic to slow down a worm's potential progress through your network. (As a bonus, following such measures reduces the need to load some patches immediately, such as those that deal with vulnerabilities in a little-used IIS feature or unnecessary Windows service. When you've already disabled such unneeded features and services, you aren't vulnerable to related exploits. Of course, you should ultimately load all patches for maximum security.) And remember, to keep all your computers locked down and up-to-date, think automation. Windows' scripting abilities and Group Policy can make the job much easier.