Thread: [mod-security-users] debug log analysis
Brought to you by:
victorhora,
zimmerletw
From: Charles H. <ch...@ch...> - 2009-04-24 14:06:42
|
G'morning all, I have some lines in the debug log I need to analyze. If anyone could point me to a resource, or outline a methodology for for fixing what's triggering the rules, I would appreciate it. The first case: I serve an rss feed from my site, /recipes.rss. When a newsreader (NetNewsWire in my case) hits on that file, it's triggering a rule. Here's some of the audit log below, I have put "*" to obscure some sensitive data. My thinking on how to handle this is: create the modsecurity_crs_15_(what goes here?).conf file, for my personal rules, and add some sort of exception for this case. Maybe something that says, "When the request includes "/recipes.rss", log it, but don't apply any rules"? Gotta be more to it than that; there are surely security implications involved, but for starters..? Am I close to correct? --6125c443-A-- [23/Apr/2009:14:37:26 --0500] SfDDdsCo-gIAAG1oCGsAAAAA 192.168.***.*** 50434 192.168.***.*** 80 --6125c443-B-- GET /recipes.rss HTTP/1.1 Host: bubbabbq.homeunix.net Accept-Encoding: gzip User-Agent: NetNewsWire/3.1.7 (Mac OS X; http://www.newsgator.com/Individuals/NetNewsWire/) If-None-Match: "23d57-42b0-46827b47dd000" If-Modified-Since: Wed, 22 Apr 2009 17:00:48 GMT Connection: close --6125c443-F-- HTTP/1.1 304 Not Modified Last-Modified: Wed, 22 Apr 2009 17:00:48 GMT ETag: "23d57-42b0-46827b47dd000" Accept-Ranges: bytes Content-Length: 0 Connection: close Content-Type: application/xml --6125c443-H-- Message: Warning. Match of "rx ^OPTIONS$" against "REQUEST_METHOD" required. [file "/usr/local/etc/apache22/Includes/mod_security2/ modsecurity_crs_21_protocol_anomalies.conf"] [line "41"] [id "960015"] [msg "Request Missing an Accept Header"] [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/MISSING_HEADER"] Message: Warning. Match of "rx ^OPTIONS$" against "REQUEST_METHOD" required. [file "/usr/local/etc/apache22/Includes/mod_security2/ modsecurity_crs_21_protocol_anomalies.conf"] [line "41"] [id "960015"] [msg "Request Missing an Accept Header"] [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/MISSING_HEADER"] Stopwatch: 1240515446100744 16410 (2452 13218 -) Producer: ModSecurity for Apache/2.5.9 (http://www.modsecurity.org/); core ruleset/1.6.1; core ruleset/1.6.1. Server: Apache/2.2.11 (FreeBSD) DAV/2 -- Thanks, Charles mod_security v.2.5.9, DetectionOnly mode, Apache/2.2.11, FreeBSD 6.4- STABLE |
From: Brian R. <Bri...@br...> - 2009-04-24 16:16:39
|
Charles Howse wrote: > G'morning all, > I have some lines in the debug log I need to analyze. > > If anyone could point me to a resource, or outline a methodology for > for fixing what's triggering the rules, I would appreciate it. http://www.google.com/search?q=site%3Ablog.modsecurity.org+false+positive&btnG=Search http://modsecurity.org/documentation/faq.html > > The first case: > I serve an rss feed from my site, /recipes.rss. When a newsreader > (NetNewsWire in my case) hits on that file, it's triggering a rule. > Here's some of the audit log below, I have put "*" to obscure some > sensitive data. > My thinking on how to handle this is: > create the modsecurity_crs_15_(what goes here?).conf file, for my modsecurity_crs_15_local_rules.conf or modsecurity_crs_15_custom_rules.conf Whatever you want. You may also want to create one after the other rules. modsecurity_crs_99_local_rules.conf > personal rules, and add some sort of exception for this case. Maybe > something that says, "When the request includes "/recipes.rss", log > it, but don't apply any rules"? Gotta be more to it than that; there > are surely security implications involved, but for starters..? > Am I close to correct? If you just want to log (audit) that particular URI, then in your custom 15 file add something like: # Just audit this URI and that is all SecRule \ REQUEST_FILENAME \ "@endsWith /recipes.rss" \ "phase:1,t:none,t:normalisePath,allow:request,log,auditlog" However, that is a bit of a sledge hammer rule (not as bad as removing 960015, though). In a custom 99 file you could just change the deny (assuming you are using the optional version which does deny) to a pass only for that rule: # Do not deny for missing Accept header SecRuleUpdateActionById 960015 pass There are other options as well, so read through the resources from above. -B > > --6125c443-A-- > [23/Apr/2009:14:37:26 --0500] SfDDdsCo-gIAAG1oCGsAAAAA 192.168.***.*** > 50434 192.168.***.*** 80 > --6125c443-B-- > GET /recipes.rss HTTP/1.1 > Host: bubbabbq.homeunix.net > Accept-Encoding: gzip > User-Agent: NetNewsWire/3.1.7 (Mac OS X; http://www.newsgator.com/Individuals/NetNewsWire/) > If-None-Match: "23d57-42b0-46827b47dd000" > If-Modified-Since: Wed, 22 Apr 2009 17:00:48 GMT > Connection: close > > --6125c443-F-- > HTTP/1.1 304 Not Modified > Last-Modified: Wed, 22 Apr 2009 17:00:48 GMT > ETag: "23d57-42b0-46827b47dd000" > Accept-Ranges: bytes > Content-Length: 0 > Connection: close > Content-Type: application/xml > > --6125c443-H-- > Message: Warning. Match of "rx ^OPTIONS$" against "REQUEST_METHOD" > required. [file "/usr/local/etc/apache22/Includes/mod_security2/ > modsecurity_crs_21_protocol_anomalies.conf"] [line "41"] [id "960015"] > [msg "Request Missing an Accept Header"] [severity "CRITICAL"] [tag > "PROTOCOL_VIOLATION/MISSING_HEADER"] > Message: Warning. Match of "rx ^OPTIONS$" against "REQUEST_METHOD" > required. [file "/usr/local/etc/apache22/Includes/mod_security2/ > modsecurity_crs_21_protocol_anomalies.conf"] [line "41"] [id "960015"] > [msg "Request Missing an Accept Header"] [severity "CRITICAL"] [tag > "PROTOCOL_VIOLATION/MISSING_HEADER"] > Stopwatch: 1240515446100744 16410 (2452 13218 -) > Producer: ModSecurity for Apache/2.5.9 (http://www.modsecurity.org/); > core ruleset/1.6.1; core ruleset/1.6.1. > Server: Apache/2.2.11 (FreeBSD) DAV/2 > > -- > Thanks, > Charles > > mod_security v.2.5.9, DetectionOnly mode, Apache/2.2.11, FreeBSD 6.4- > STABLE > > > ------------------------------------------------------------------------------ > Crystal Reports- New Free Runtime and 30 Day Trial > Check out the new simplified licensign option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Appliances, Rule Sets and Support: > http://www.modsecurity.org/breach/index.html -- Brian Rectanus Breach Security |
From: Charles H. <ch...@ch...> - 2009-04-24 16:30:36
|
OK, my research has led me to creating modsecurity_crs_15_personal.conf, with contents: # For testing purposes only # Allow /recipes.rss SecRule REQUEST_HEADERS "GET /recipes.rss HTTP/1.1" nolog,allow,ctl:ruleEngine=Off That doesn't generate any errors when loading, however I'm snot sure what I should be seeing in the audit.log after this rule fires. I was thinking "nothing"...? -- Thanks, Charles mod_security v.2.5.9, DetectionOnly mode, FreeBSD 6.4-STABLE |
From: Charles H. <ch...@ch...> - 2009-04-24 16:49:45
|
On Apr 24, 2009, at 11:16 AM, Brian Rectanus wrote: > > Charles Howse wrote: >> G'morning all, >> I have some lines in the debug log I need to analyze. >> >> If anyone could point me to a resource, or outline a methodology for >> for fixing what's triggering the rules, I would appreciate it. > > http://www.google.com/search?q=site%3Ablog.modsecurity.org+false+positive&btnG=Search > > http://modsecurity.org/documentation/faq.html > >> >> The first case: >> I serve an rss feed from my site, /recipes.rss. When a newsreader >> (NetNewsWire in my case) hits on that file, it's triggering a rule. >> Here's some of the audit log below, I have put "*" to obscure some >> sensitive data. >> My thinking on how to handle this is: >> create the modsecurity_crs_15_(what goes here?).conf file, for my > > modsecurity_crs_15_local_rules.conf > > or > > modsecurity_crs_15_custom_rules.conf > > Whatever you want. You may also want to create one after the other > rules. > > modsecurity_crs_99_local_rules.conf > > >> personal rules, and add some sort of exception for this case. Maybe >> something that says, "When the request includes "/recipes.rss", log >> it, but don't apply any rules"? Gotta be more to it than that; there >> are surely security implications involved, but for starters..? >> Am I close to correct? > > If you just want to log (audit) that particular URI, then in your > custom 15 file add something like: > > # Just audit this URI and that is all > SecRule \ > REQUEST_FILENAME \ > "@endsWith /recipes.rss" \ > "phase:1,t:none,t:normalisePath,allow:request,log,auditlog" > > However, that is a bit of a sledge hammer rule (not as bad as > removing 960015, though). > > In a custom 99 file you could just change the deny (assuming you are > using the optional version which does deny) to a pass only for that > rule: > > # Do not deny for missing Accept header > SecRuleUpdateActionById 960015 pass > > There are other options as well, so read through the resources from > above. Thank you Brian, I actually had "False Positives", "Data Format" and "Configuration Directives" open as I was experimenting with that rule. I may actually have had it going with another rule, but wasn't sure what I should be seeing in the log, so your example helped a lot. Now I can continue on my own for some other false positives I have. The last part of your rule is where I'm getting lost. Safari has a "Find in document" feature, and I've done a find on "t:none" in all the pages I have open right now, and I can't find an explanation of exactly what that means/does. Have I missed it somewhere? |
From: Brian R. <Bri...@br...> - 2009-04-24 17:01:42
|
Charles Howse wrote: > On Apr 24, 2009, at 11:16 AM, Brian Rectanus wrote: > >> Charles Howse wrote: >>> G'morning all, >>> I have some lines in the debug log I need to analyze. >>> >>> If anyone could point me to a resource, or outline a methodology for >>> for fixing what's triggering the rules, I would appreciate it. >> http://www.google.com/search?q=site%3Ablog.modsecurity.org+false+positive&btnG=Search >> >> http://modsecurity.org/documentation/faq.html >> >>> The first case: >>> I serve an rss feed from my site, /recipes.rss. When a newsreader >>> (NetNewsWire in my case) hits on that file, it's triggering a rule. >>> Here's some of the audit log below, I have put "*" to obscure some >>> sensitive data. >>> My thinking on how to handle this is: >>> create the modsecurity_crs_15_(what goes here?).conf file, for my >> modsecurity_crs_15_local_rules.conf >> >> or >> >> modsecurity_crs_15_custom_rules.conf >> >> Whatever you want. You may also want to create one after the other >> rules. >> >> modsecurity_crs_99_local_rules.conf >> >> >>> personal rules, and add some sort of exception for this case. Maybe >>> something that says, "When the request includes "/recipes.rss", log >>> it, but don't apply any rules"? Gotta be more to it than that; there >>> are surely security implications involved, but for starters..? >>> Am I close to correct? >> If you just want to log (audit) that particular URI, then in your >> custom 15 file add something like: >> >> # Just audit this URI and that is all >> SecRule \ >> REQUEST_FILENAME \ >> "@endsWith /recipes.rss" \ >> "phase:1,t:none,t:normalisePath,allow:request,log,auditlog" >> >> However, that is a bit of a sledge hammer rule (not as bad as >> removing 960015, though). >> >> In a custom 99 file you could just change the deny (assuming you are >> using the optional version which does deny) to a pass only for that >> rule: >> >> # Do not deny for missing Accept header >> SecRuleUpdateActionById 960015 pass >> >> There are other options as well, so read through the resources from >> above. > > Thank you Brian, I actually had "False Positives", "Data Format" and > "Configuration Directives" open as I was experimenting with that rule. > I may actually have had it going with another rule, but wasn't sure > what I should be seeing in the log, so your example helped a lot. Now > I can continue on my own for some other false positives I have. > > The last part of your rule is where I'm getting lost. Safari has a > "Find in document" feature, and I've done a find on "t:none" in all > the pages I have open right now, and I can't find an explanation of > exactly what that means/does. Have I missed it somewhere? > http://modsecurity.org/documentation/modsecurity-apache/2.5.9/modsecurity2-apache-reference.html#N11479 It just instructs modsecurity to start with no transformations instead of any default transformations you may have. I like to avoid any default transformations and make rules "self contained" so that if the defaults change the rule still works. I recommend *against* SecDefaultAction in all cases but to control the default disruptive action for use with "block" action. -B -- Brian Rectanus Breach Security |