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.)
Prev. page
1
2
[3]
4
next page 
