IIS Informant: Determining Whether a Hack Is Successful

While I was reviewing my IIS logs, I noticed the log file that Figure 2, page 6, shows. (I've removed the IP address.) This log file appears to show an attempt to crack the server, but how can I determine whether the crack was successful?

This output has the Nimda worm's signature and indeed shows an attempt to crack the server by using a variety of techniques. (For more information about the Nimda worm, go to http://www.cert.org/advisories/CA-2001-26.html.) Let's break down this file. The first part of each entry—for example

2001-12-14 03:14:53 (ip address)- W3SVC3 WEBSRV1 (ip address) 80

identifies the Web site, shows when the request occurred, and shows both the identity of the Web server and the IP addresses involved in the attack. The first IP address is the IP address of the client attacking the server. The second part of each entry—for example

GET /scripts/root.exe /c+dir

shows exactly what the Web server received from the client's URL. The third part of each entry—for example

401 5 3874 144 0 HTTP/1.0 www - - -

shows the result of the server's request processing. In all cases in your example, the server returned the error message 401 File not found.

Fortunately, you weren't vulnerable to any of these attacks. As you can see, the first two entries look for root.exe in the /scripts folder. In other words, the attacker was looking for an IIS server on which the CodeRedII virus had placed root.exe in the /scripts folder. The remaining entries are trying to exploit the Directory Traversal vulnerability in IIS.

After you've secured your server from these attacks, you have to worry about the IIS log file entries becoming diluted. Recording every attack on your server in your IIS logs can make determining how many users are actually contacting your server for legitimate purposes difficult. After all, as far as IIS is concerned, an attacker is a user.

So, how can you keep this information out of your IIS logs? The only way is to keep IIS from processing the URL the attacker sends to the server, which requires that a program or process intercept the attacking URL and reject it before IIS processes it. For example, you can use intrusion-detection software such as Snort, Internet Security Systems' (formerly Network ICE's) BlackICE Defender for Server, eEye Digital Security's SecureIIS Application Firewall, or Flicks Software's Titan. UrlScan, which is part of the IIS Lockdown Tool, inspects an incoming URL and effectively blocks Nimda-type attacks. UrlScan is a free download from http://www.microsoft.com/downloads/release.asp?releaseid=33961 and works well; however, don't confuse it with intrusion-detection software.