IDS mailing list archives
RE: Web server response to attacks
From: "Levinson, Karl" <LevinsonK () STARS-SMI com>
Date: Fri, 21 Feb 2003 13:17:57 -0500
-----Original Message----- From: Terry Ziemniak [mailto:terry.ziemniak () swc com]
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 of exploits (meaning OS/web server executable and dll exploits)? For Code Red I and II, as well as tomorrow's new web server exploit d'jour, can I assume a 400 level response from my web server means that the attack was not successfully?
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+syslog http://groups.google.com/groups?q=iis+syslog http://www.mwagent.com/en/FAQ/forward-iis-logs-to-syslog.asp http://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
Current thread:
- Web server response to attacks Terry Ziemniak (Feb 20)
- Re: Web server response to attacks Michael Katz (Feb 20)
- Re: Web server response to attacks Frank Knobbe (Feb 25)
- <Possible follow-ups>
- RE: Web server response to attacks Levinson, Karl (Feb 21)
- Re: Web server response to attacks Michael Katz (Feb 20)