Re: [mod-security-users] Working Around Race Conditions in Persistent Storage

[Robert P. <rpa...@fe...>]

ModSec's double-read delta method isn't foolproof; I've seen some similar
behaviors with large (hundreds of MB to several DB) sdbm instances. Tbh
until libmodsec is stable and has support for memcached and redis
persistent storage engines, I think there should be much more documentation
and warning about the uses of on-disk persistent storage for highly
concurrent operations like this. Spinning disks simply weren't meant to
handle this kind of usage, and continuing to offer up things like
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/master/experimental_rules/modsecurity_crs_11_dos_protection.conf
and
https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.0.0-rc1/rules/REQUEST-912-DOS-PROTECTION.conf
without providing a stable, high-performance environment to track this data
is dangerous, imo (and to be clear, this isn't a criticism of the DoS
ruleset or the CRS team's work in this area, but the fact that its
essentially marketed as stable and usable while the community acknowledges
that there's no reasonable expectation of being able to support these
behaviors).

Also, frankly using Apache as a DoS mitigation vector feels like shoving a
square peg into a round hole. Writing complex rulesets to rate limit
certain request patterns seems much better served by a downstream proxy
than the app server itself (and at this point, we're starting to get into
"move the WAF away from the app server" territory); indeed, using Nginx as
a simple proxy with libmodsec to monitor this traffic would likely be a
much more performant solution. Alternatives might also include using
something like OpenResty to provide flexible scripting options for login
traffic analysis in the context of a downstream reverse proxy, without
being locked in directly to ModSecurity's syntax and environment (but still
being able to leverage libmodsecurity if desired).



On Thu, Sep 8, 2016 at 8:38 AM, Christian Folini <
chr...@ne...> wrote:

> On Thu, Sep 08, 2016 at 09:39:25AM -0500, Riemann . wrote:
> > Thanks Christian. We only use Windows servers in production, so I haven't
> > tried this under Unix. It might be that this specific behavior is
> specific
> > to the Windows install (which probably isn't the most typical for ModSec
> > users).
>
> According do Felipe rather not. But it might be worth a try.
>
> > I appreciate your suggestions--and I'll definitely look into using a
> custom
> > Apache log and trying to parse and alert on that as an alternative
> option.
>
> https://www.netnea.com/cms/flying-frog-anti-ddos-script/ might bring
> some inspiration. It's more of a proof of concept, but I still think the
> idea is neat.
>
> Cheers,
>
> Christian
>
>
> --
> There is one rule, above all others, for being a man.
> Whatever comes, face it on your feet.
> -- Robert Jordan
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> 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/
>