RE: Web server response to attacks

From: Levinson, Karl <LevinsonK(at)STARS-SMI.com>
Date: Fri Feb 21 2003 - 13:17:57 EST

> -----Original Message-----

> can you tell the whether the attack was successful based on
> the HTTP return
> code?

Not always.

> I had always assumed that a 403/404 to this type of a
> requests meant
> it was blocked.

I'm not aware of a case YET where a 400 status code indicates anything other than failure.

However, contrary to what you would normally expect, the 200 and 502 status codes by themselves do not necessarily prove either success or failure. 500 codes are supposed to generally indicate failure, but logs of Nimda directory traversal can show 502 status even where commands such as ECHO and COPY are successful.

Similarly, the 200 code is supposed to generally indicate success. HOWEVER, an IIS server that has been patched against MS Indexing Service buffer overflows still returns 200 in response to the Code Red worm's request to GET /DEFAULT.IDA, whether the exploit code failed or was successful.

http://securityadmin.info/faq.htm#iislogs2

> But as I have never actually seen the logs from a
> successful exploit, I am wondering if that is true.

You can see logs from successful exploits along with HTTP status codes at:

http://securityadmin.info/faq.htm#iislogs

> Along those same lines, does this apply to the general class

I wouldn't presume to state that HTTP 400 status messages will always indicate failure. One never knows.

Additionally, note that logs can be deleted or edited by an intruder and are not always reliable. One solution to try to preserve log integrity is to use some method to continuously export the logs to another secured server, often using syslog. Some such solutions [both free and commercial] can be found by searching the usual places:

http://www.google.com/search?q=iis+sysloghttp://groups.google.com/groups?q=iis+sysloghttp://www.mwagent.com/en/FAQ/forward-iis-logs-to-syslog.asphttp://www.intersectalliance.com/projects
http://sabernet.home.attbi.com/software/ntsyslog.html 
       [sends Windows event logs to syslog]

http://www.kiwisyslog.com [one of many syslog clients]

Since the logs are valuable but not always reliable or authoritative, you may also want to consider doing the usual things to monitor for other signs of successful intrusion: antivirus, anti-Trojan scanners, file change checkers like Tripwire or the free S.I.M. at www.gfi.com, network and/or host-based intrusion detection, programs or scripts that monitor logs for changes like www.ipsentry.com or DUMPEL with BLAT, etc.

While trying to inspect log files to determine the success or failure of an attack, it is probably useful to try to determine what the attack tried to do and look for evidence of success... If an attempt was made to download or create a file, do traces of that file exist? If an attempt was made to install or launch an executable, is there evidence of an unexpected process in memory, or listening on a certain port according to NETSTAT, or sending out unexpected traffic per your firewall logs or a sniffer? Also, was the same command tried over and over with different syntaxes and then stop? Do subsequent commands show any evidence of knowledge of your computer that could have been gained by success of a previous command such as a DIR command?

HTH Hope I didn't get too far off-topic.

kind regards,

karl
levinson_k@despammed.com

---

Does your IDS have Intelligent Attack Profiling? If not, see what you're missing.
Download a free 15-day trial of StillSecure Border Guard. http://www.securityfocus.com/stillsecure Received on Fri Feb 21 13:24:05 2003