Re: [mod-security-users] Drop disruptive action and 403 status codes

[J D. <ge...@na...>]

Hi Christian,

Thank you for testing this for me and my apologies for not trying this out with curl/wget before posting my question.  I should exhaust test cases before posting.

Ok, that's what I was thinking - that Apache records it as a 403 but is not necessarily pushing traffic, which would be the functional equivalent of a deny with 403 status.  I can now see when to use each disruptive action.

- J

> On Mar 10, 2017, at 5:01 AM, Christian Folini <chr...@ne...> wrote:
> 
> Hello,
> 
> I think this is an implementation issue. The client receives the
> drop (-> TCP FIN), but the log has a complete 403. I take it Apache
> insists into recording a 403 (also see access log).
> 
> Here is a curl call:
> $> curl -d "b=1" -v http://localhost/
> * Rebuilt URL to: localhost/
> *   Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 80 (#0)
>> POST / HTTP/1.1
>> Host: localhost
>> User-Agent: curl/7.50.1
>> Accept: */*
>> Content-Length: 3
>> Content-Type: application/x-www-form-urlencoded
>> 
> * upload completely sent off: 3 out of 3 bytes
> * Empty reply from server
> * Connection #0 to host localhost left intact
> curl: (52) Empty reply from server
> 
> Cheers,
> 
> Christian
> 
> 
>> On Wed, Mar 08, 2017 at 05:43:46PM -0500, J Doe wrote:
>> Hi,
>> 
>> I have two questions about the "drop" disruptive action in ModSecurity v. 2.9.1.
>> 
>> Firstly, I note that the wiki states (see: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#drop), that the network connection is closed and a TCP FIN packet is sent to the originator of the traffic.
>> 
>> When I check the audit log for a rule that uses drop as the action, I note the following:
>> 
>> --9cb8e90b-F--
>> HTTP/1.1 403 Forbidden
>> Vary: Accept-Encoding
>> Content-Encoding: gzip
>> Content-Length: 206
>> Keep-Alive: timeout=15, max=100
>> Connection: Keep-Alive
>> Content-Type: text/html; charset=ISO-8859-1
>> 
>> Does this mean that even though the network connection should be closed, the web server (Apache 2.x in this case), is still serving a 403 page to the client ?  Or is this how Apache is responding to the fact that the network connection is closed (ie: it records a 403 but doesn't actually serve the page) ?  I ask because if it is serving a 403 page, then there doesn't seem to be to much difference between this disruptive action and a "deny" action serving a 403 page.
>> 
>> Second, what are the situations that using "drop" over "deny" is a best practice ?  I notice that the wiki states that rules against brute force and DoS attacks should use "drop", but if I am blocking access to resources in general (say I am blocking an aggressive web crawler), would I still want to use "drop" to limit the bandwidth and not provide any clues that I am using a WAF (I would think most malicious actors would view a 403 on a blocked resource as evidence that a WAF is in play) ?
>> 
>> Thanks
> 
>> ------------------------------------------------------------------------------
>> Announcing the Oxford Dictionaries API! The API offers world-renowned
>> dictionary content that is easy and intuitive to access. Sign up for an
>> account today to start using our lexical data to power your apps and
>> projects. Get started today and enter our developer competition.
>> http://sdm.link/oxford
> 
>> _______________________________________________
>> mod-security-users mailing list
>> mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
>> http://www.modsecurity.org/projects/commercial/rules/
>> http://www.modsecurity.org/projects/commercial/support/
> 
> 
> -- 
> https://www.feistyduck.com/training/modsecurity-training-course
> mailto:chr...@ne...
> twitter: @ChrFolini
> 
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/