Next, create a batch file called LockDownIfNotAlreadyDone.bat and add the following lines:
if exist %systemroot%\iisalready
lockeddown exit
iislockd
md %systemroot%\iisalready lockeddown
Open the Microsoft Managament Console (MMC) Group Policy console to edit the FrontPageWorkstationsPolicies GPO. In the left-hand pane, select Computer Configuration\Windows Settings\Scripts (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 Startup\iislockd. Return to the Startup Properties dialog box and click Add. Click Browse, then maneuver to Startup\iislockd 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 Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment) to assign the Access this computer from the network right to that group only.
Preventing shared filebased 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.
Prev. page
1
[2]
3
4
next page 
