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: