Auditing does not prevent system attacks, although it is an important aid in identifying intruders and attacks in progress, and can assist you in diagnosing attack footprints. Enable a minimum level of auditing on your Web server and use NTFS permissions to protect the log files so that an attacker cannot cover his tracks by deleting or updating the log files in any way. Use IIS W3C Extended Log File Format Auditing.
During this step, you:
Log all failed Logon attempts .
Log all failed actions across the file system .
Relocate and secure the IIS log files .
Archive log files for offline analysis .
Audit access to the Metabase.bin file .
You must log failed logon attempts to be able to detect and trace suspicious behavior.
Task To audit failed logon attempts
Start the Local Security Policy tool from the Administrative Tools program group .
Expand Local Policies and then select Audit Policy
Double-click Audit account logon events .
Click Failure and then OK .
Logon failures are recorded as events in the Windows security event log. The following event IDs are suspicious:
531 . This means an attempt was made to log on using a disabled account.
529 . This means an attempt was made to log on using an unknown user account or using a valid user account but with an invalid password. An unexpected increase in the number of these audit events might indicate an attempt to guess passwords.
Use NTFS auditing on the file system to detect potentially malicious attempts. This is a two-step process.
Task To enable logging
Start the Local Security Policy tool from the Administrative Tools program group.
Expand Local Policies and then select Audit Policy
Double-click Audit object access .
Click Failure and then click OK .
Task To audit failed actions across the file system
Start Windows Explorer and navigate to the root of the file system.
Right-click and then click Properties .
Click the Security tab.
Click Advanced and then click the Auditing tab.
Click Add and then enter Everyone in the Name field.
Click OK and then select all of the Failed check boxes to audit all failed events.
By default, this applies to the current folder and all subfolders and files.
Click OK three times to close all open dialog boxes.
Failed audit events are logged to the Windows security event log.
By moving and renaming the IIS log files, you make it much more difficult for an attacker to cover his tracks. The attacker must locate the log files before he or she can alter them. To make an attacker's task more difficult still, use NTFS permissions to secure the log files.
Move and rename the IIS log file directory to a different volume than your Web site. Do not use the system volume. Then, apply the following NTFS permissions to the log files folder and subfolders.
Administrators: Full Control
System: Full Control
Backup Operators: Read
To facilitate the offline analysis of IIS log files, you can use a script to automate secure removal of log files from an IIS server. Log files should be removed at least every 24 hours. An automated script can use FTP, SMTP, HTTP, or SMB to transfer log files from a server computer. However, if you enable one of these protocols, do so securely so that you do not open any additional attack opportunities. Use an IPSec policy to secure ports and channels.
Audit all failures by the Everyone group to the IIS metabase.bin file located in \WINNT\System32\inetsrv\. Do the same for the \Metabase backup folder for the backup copies of the metabase.
Additionally, you can configure IIS W3C Extended Log File Format Auditing. Select W3C Extended Log File Format on the Web Site tab of the Web site's properties dialog box. You can then choose Extended Properties such as URI Stem and URI Query.