Not the wormy "CodeRed", but Red Alert, mind you.
Following the new "tradition" of posting a security tip of the week (mentioned here, here ; SANS jumped in as well), I decided to follow along and join the initiative. One of the bloggers called it "pay it forward" to the community.
So, Anton Security Tip of the Day #4: Code 200: Good or Bad?
Now, this is somewhat related to my previous tip (#3), but as it applies to web server logs, such as IIS Extended W3C (or other) logs or Apache access_log logs. Unlike, say, databases, all webserves come with logging enabled, so web server log review is a common task for web server admins as well as for security teams. But what do you look for in normal web access logs, apart from web site access statistics and visitor trends?
Obviously, observing various access failures is important. All the pesky 404s, 401s as well as 50X response codes.
Here are a couple of examples from Apache web server access_log logs:
61.52.47.251 - - [26/Sep/2004:21:10:22 -0400] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 404 286 "-" "-"
or
67.170.226.184 - - [10/May/2004:13:18:09 -0400] "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 400 293 "-" "-"
Is this ominous or what? :) Nah, it is just my Linux + Apache honeynet responding to some good ole IIS 4.X attack. Truly nothing to worry about.
How about this one though?
68.49.152.86 - - [22/Apr/2004:11:56:49 -0400] "GET /cgi-bin/awstats.pl HTTP/1.0" 200 2190 "-" "Mozilla/4.75 (Nikto/1.32 )"
Somebody using the web statistics CGI script? Benign, since the response code is 200 which means that the server served the page (or ran the script!) as expected? No, you are about to get 0wned thru an AWSTATS hole!
So, the gist of this tip is similar to the previous one: when monitoring web server logs, do not just focus on 404s, 401s, 50Xs and other "known bad" response codes; take a long hard look at the vanilla 200 response codes. "But how do I separate the "good" 200s from the "bad" 200s?" - you might ask! Well, that would be the subject of another tip in the future!
Just in case, here are the links to my previous tips: #3, #2, #1.
Also, I am tagging all the tips on my del.icio.us feed. Here is the link: All Security Tips of the Day.
tags: security, tips, log analysis, log, web logs, web servers, log management
2 comments:
Great ip Anton. I also think that sucessful attempts should be checked and
taken in consideration...
For 200 (sucess) return codes, it is very hard to separate the "bad" from the "good", specially on dynamic web sites. To try to solve this problem, on ossec, we built a list of strings that are most of the time bad on URLs. For example, for sql injections, we use the following combination:
='|select%20|insert%20|%20from%20|
%20where%20|union%20
For cross site scripting, we use:
%3Cscript|%2Fscript|script>|
script%3E|SRC=javascript|IMG%20|
%20ONLOAD=|INPUT%20
We also have more *patterns for specific
attacks, common worms , etc.
Btw, I also think that this analysis
must be done on web proxy logs too.
On ossec we use that on our squid
rules and we can easily detect
infected internal systems by their
http requests...
*we know the list is not complete, but
we are improving it.
Thanks,
Daniel B. Cid
dcid ( at ) ossec.net
You do not need to search for working free web proxies. All is here.
Find free web proxy for desired country!
All proxies are regulary checked if they still alive.
http://getproxy.emigrantas.com
http://getproxy.ath.cx
http://getproxy.mine.nu
http://proxylist.getmyip.com
http://proxylist.homeip.net
http://randomproxy.ath.cx
enjoy them!
Post a Comment