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.htmlMany 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#servertokensOr 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.htmlhttp://phpsec.org/www.Obnosis.com |  http://en.wiktionary.org/wiki/Citations:obnosis |
http://www.urbandictionary.com/define.php?term=obnosis (503)754-4452Catch 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.comTo: klsmith2020@yahoo.com; plug-discuss@lists.plug.phoenix.az.usSubject: RE: Website ExploitsDate: 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.


From: 
plug-discuss-bounces@lists.plug.phoenix.az.us 
[mailto:plug-discuss-bounces@lists.plug.phoenix.az.us] On Behalf Of keith 
smithSent: Wednesday, December 03, 2008 3:40 PMTo: 
plug-discuss@lists.plug.phoenix.az.usSubject: OT: Website 
Exploits

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.
http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_speed_122008