Re: [mod-security-users] [Fwd: Re: Logging of internal dummy connections]

[Ryan B. <Rya...@br...>]

Is your Apache server a reverse proxy?  Perhaps the 400 level status code is being generated by a downstream host.

-----Original Message-----
From: Peter Termaten [mailto:pet...@gm...]
Sent: Sunday, March 29, 2009 11:14 AM
To: mod...@li...
Subject: [mod-security-users] [Fwd: Re: Logging of internal dummy connections]

Thanks Ryan,

There's only one type of message in the error.log:

[Sun Mar 29 16:07:40 2009] [error] [client 127.0.0.1] ModSecurity: Audit
log: Failed to lock global mutex: Identifier removed [uri "*"]
[unique_id "fSrVU8JtjvIAAASSAXQAAAAC"]
[Sun Mar 29 16:07:40 2009] [error] [client 127.0.0.1] ModSecurity: Audit
log: Failed to unlock global mutex: Invalid argument [uri "*"]
[unique_id "fSrVU8JtjvIAAASSAXQAAAAC"]

and no further clue about the status 400. Grepping the logfiles does not
give any results either.

Any ideas??

-peter



Ryan Barnett wrote:
> Peter,
> You should review your apache error_log to see why Apache is generating a 400 status code when this request is triggered.  The ModSecurity CRS rules are not triggering and causing this to be logged (if it was, there would be Message data under section H below and a full rule trigger in section K).  This seems to have been logged in the audit_log file based on the SecAuditLogRelevantStatus settings which will audit log when the web server generates a 4xx level response.
>
> -Ryan
>
> -----Original Message-----
> From: Peter Termaten [mailto:pet...@gm...]
> Sent: Friday, March 27, 2009 9:14 AM
> To: mod...@li...
> Subject: [mod-security-users] Logging of internal dummy connections
>
> Hi all,
>
> After upgrading to Apache 2.2.8, my modsec logfile gets polluted with
> messages triggered by 'internal dummy connections', like below.
>
> modsecurity_crs_21_protocol_anomalies contains an exception Rule for
> this type of traffic, but does not suppress the logging of the status
> 400 rule.
> How can I refine this rule and make sure no logging takes place?
>
> (Adding ctl:ruleRemoveById=960913 does not have the desired effect, nor
> does adding ctl:ruleEngine=off.)
>
> Thanks,
> Peter
> ===================
>
> # Exception for Apache internal dummy connection
> SecRule REQUEST_LINE "^GET / HTTP/1.0$"
> "chain,phase:2,t:none,pass,nolog,ctl:ruleRemoveById=960019,ctl:ruleRemoveById=960008,ctl:ruleRemoveById=960015,ctl:ruleRemoveById=960009,id:'999211',severity:'5'"
> SecRule REMOTE_ADDR "^127\.0\.0\.1$" "chain,t:none"
> SecRule REQUEST_HEADERS:User-Agent "^Apache.*\(internal dummy
> connection\)$" "t:none"
>
> ========================
>
> --de3b6c52-A--
> [27/Mar/2009:12:51:54 +0100] W-bm5sJtjvIAAGFhALsAAAAJ 127.0.0.1 46459
> 127.0.0.1 80
> --de3b6c52-B--
> OPTIONS * HTTP/1.0
> User-Agent: Apache/2.2.0 (Fedora) (internal dummy connection)
>
> --de3b6c52-F--
> HTTP/1.1 400 Bad Request
> Content-Length: 226
> Connection: close
> Content-Type: text/html; charset=iso-8859-1
>
> --de3b6c52-H--
> Stopwatch: 1238154714998502 219 (- - -)
> Producer: ModSecurity for Apache/2.5.6 (http://www.modsecurity.org/);
> core ruleset/1.6.1.
> Server: Apache/2.2.8 (Ubuntu)
>
> --de3b6c52-K--
> SecRule "RESPONSE_STATUS" "@rx ^400$"
> "phase:5,t:none,chain,log,auditlog,pass,msg:'Invalid
> request',id:960913,severity:2"
>
> --de3b6c52-Z--
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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
>
>




------------------------------------------------------------------------------
_______________________________________________
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