If you are using the apache-prefork and receive this kind of attack ... it can kill all your operation system forking too many process. So  a good reason to enable this feature :)

Note that this is not a definitive solution, but can help you a lot during this kind of attack saving a big part of legit connections.

Thanks

Breno

On Wed, Nov 24, 2010 at 7:47 AM, Breno Silva <breno.silva@gmail.com> wrote:
Christian,

Yes and No :)

Keep it mind that with small number of threads can handle many requests ... so you can also have a large number of long (BUSY_STATE) legit connections with low threads per ipaddress.

However you u have behind your proxy a lot of user doing a LOT of big uploads to a specific server... and the SecReadStateLimit is very small ... it can reject the connection.


On Wed, Nov 24, 2010 at 7:22 AM, <christian.folini@post.ch> wrote:

Thanks Breno,

 

I think I got it.

 

So clients will be save for GET requests, but for long POST requests the mileage may vary.

 

 

Best,

 

Christian

 

 

Von: Breno Silva [mailto:breno.silva@gmail.com]
Gesendet: Mittwoch, 24. November 2010 14:18


An: Folini Christian, IT222 extern
Cc: RBarnett@trustwave.com; mod-security-users@lists.sourceforge.net
Betreff: Re: [mod-security-users] [Owasp-modsecurity-core-rule-set] Advanced Topic of the Week: Mitigating Slow HTTP DoS Attacks

 

This an example

I sent an attack from my PC to my apache server in another machine. And without the protection i sent in the same time using ab ligit connections:

Concurrency Level:      100
Time taken for tests:   32.842 seconds
Complete requests:      500

As you can see it spent too much time to answer my connections


Now i did the same test, but turn on the defense:

Concurrency Level:      100
Time taken for tests:   0.122 seconds
Complete requests:      500

As you can see the legit connections was accepted normally during the attack from the same ip address.

Breno

On Wed, Nov 24, 2010 at 7:10 AM, Breno Silva <breno.silva@gmail.com> wrote:

Hi Christian,

Internally into the modsec you are checking how many threads are in SERVER_BUSY_STATE and limiting the number of this threads per ip address using the SecReadStateLimit. The large part of the proxied connections will leave this state very quickly and the connection will be not counted to be rejected. So a few number of threads should be enough to handle your legit SERVER_BUSY_STATE connections.

Thanks

Breno

 

On Wed, Nov 24, 2010 at 6:31 AM, <christian.folini@post.ch> wrote:

Hi Breno,

 

Could explain the term „bad connection“ a bit? Ryan’s blog post implies a client IP is considered bad

when it has too many connections in read state. Your entry in the CHANGES document reads,

“Add SecReadStateLimit to limit the number of BUSY connections”.

 

I can’t see why a proxy can’t have a lot of legitimate connections

in read state. AFAIK Request Body reading is also considered “read”.

So uploads can remain in READ for a certain time – depending on service.

 

I do not want to pester you too much, but I just want to make sure I

get this correctly – and people are aware that telling good from bad

connections is very tricky. Especially when it comes to request delaying and

you want to make sure you are not locking legitimate users.

 

Best Regs,

 

Christian

 

 

 

 

Von: Breno Silva [mailto:breno.silva@gmail.com]
Gesendet: Mittwoch, 24. November 2010 13:20
An: Folini Christian, IT222 extern
Cc: RBarnett@trustwave.com; mod-security-users@lists.sourceforge.net; owasp-modsecurity-core-rule-set@lists.owasp.org
Betreff: Re: [mod-security-users] [Owasp-modsecurity-core-rule-set] Advanced Topic of the Week: Mitigating Slow HTTP DoS Attacks

 

Hi Christian,

The SecReadStateLimit is not only a threshold for ip address. It is looking for an "anomaly" in connection process. So if you are behind a proxy or a NAT only the bad connections will be dropped. The good ones will pass normally. So legit connections behind the proxy will works fine.

Thanks

Breno

On Wed, Nov 24, 2010 at 1:17 AM, <christian.folini@post.ch> wrote:

Hi Ryan,

Nice post. Thanks. Especially the combination of mod_reqtimeout and ModS
is very elegant in my eyes.

I am not so happy with SecReadStateLimit looking only at the IP address.
How do protect proxies from your countermeasures? A proxy might share multiple
hundred legitimate connections with your server for multiple hundred legitimate
clients, all appearing to come from the same IP address.

Regs,

Christian


-----Ursprüngliche Nachricht-----
Von: owasp-modsecurity-core-rule-set-bounces@lists.owasp.org [mailto:owasp-modsecurity-core-rule-set-bounces@lists.owasp.org] Im Auftrag von Ryan Barnett
Gesendet: Mittwoch, 24. November 2010 02:45
An: mod-security-users@lists.sourceforge.net; owasp-modsecurity-core-rule-set@lists.owasp.org
Betreff: [Owasp-modsecurity-core-rule-set] Advanced Topic of the Week: Mitigating Slow HTTP DoS Attacks


This week's blog post -

http://blog.spiderlabs.com/2010/11/advanced-topic-of-the-week-mitigating-slow-http-dos-attacks.html

--
Ryan Barnett
Senior Security Researcher
Trustwave - SpiderLabs

_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
Owasp-modsecurity-core-rule-set@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set


------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
mod-security-users mailing list
mod-security-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Appliances, Rule Sets and Support:
http://www.modsecurity.org/breach/index.html