Thread: [mod-security-users] SecReadStateLimit shutting down server without hitting limit
Brought to you by:
victorhora,
zimmerletw
From: Thomas E. <tho...@gm...> - 2013-09-17 14:44:20
|
mod_security 2.7.3 apache 2.4.4 Trying to get some SlowHTTP defenses up and running using mod_security but SecReadStateLimit is giving me a hard time. It reports ModSecurity: Access denied with code 400. Too many threads [1024] of 15 allowed in READ state from 127.0.0.1 - Possible DoS Consumption Attack even though the only connection existing is my access of mod_status. I cannot see those 1024 threads it keeps on complaining about using ps. Is that behaviour known of ? Cheers, Thomas |
From: Reindl H. <h.r...@th...> - 2013-09-17 14:58:44
Attachments:
signature.asc
|
Am 17.09.2013 16:44, schrieb Thomas Eckert: > mod_security 2.7.3 > apache 2.4.4 > > Trying to get some SlowHTTP defenses up and running using mod_security but SecReadStateLimit is giving me a hard > time. It reports > ModSecurity: Access denied with code 400. Too many threads [1024] of 15 allowed in READ state from 127.0.0.1 - > Possible DoS Consumption Attack > even though the only connection existing is my access of mod_status. I cannot see those 1024 threads it keeps on > complaining about using ps. > > Is that behaviour known of? no idea *but* use iptables for such things instead defend them in the application layer - this is a plain wrong usage of layered security - waht you want is to protect the application layer and not fight inside the application-layer with attacks iptables -A INPUT -p tcp -i eth0 ! -s 192.168.196.0/24 -m multiport --destination-port 80,443 --syn -m connlimit --connlimit-above 50 -m limit --limit 100/h -j LOG --log-prefix "Firewall Slowloris: " iptables -A INPUT -p tcp -i eth0 ! -s 192.168.196.0/24 -m multiport --destination-port 80,443 --syn -m connlimit --connlimit-above 50 -j DROP |
From: Thomas E. <tho...@gm...> - 2013-09-17 15:20:26
|
I tried to follow the advice given at http://blog.spiderlabs.com/2011/07/advanced-topic-of-the-week-mitigating-slow-http-dos-attacks.html which mentions SecReadStateLimit. If using this directive is discouraged why have it in the first place ? Cheers, Thomas On Tue, Sep 17, 2013 at 4:58 PM, Reindl Harald <h.r...@th...>wrote: > > Am 17.09.2013 16:44, schrieb Thomas Eckert: > > mod_security 2.7.3 > > apache 2.4.4 > > > > Trying to get some SlowHTTP defenses up and running using mod_security > but SecReadStateLimit is giving me a hard > > time. It reports > > ModSecurity: Access denied with code 400. Too many threads [1024] of > 15 allowed in READ state from 127.0.0.1 - > > Possible DoS Consumption Attack > > even though the only connection existing is my access of mod_status. I > cannot see those 1024 threads it keeps on > > complaining about using ps. > > > > Is that behaviour known of? > > no idea *but* use iptables for such things instead defend them in > the application layer - this is a plain wrong usage of layered > security - waht you want is to protect the application layer > and not fight inside the application-layer with attacks > > iptables -A INPUT -p tcp -i eth0 ! -s 192.168.196.0/24 -m multiport > --destination-port 80,443 --syn -m connlimit > --connlimit-above 50 -m limit --limit 100/h -j LOG --log-prefix "Firewall > Slowloris: " > iptables -A INPUT -p tcp -i eth0 ! -s 192.168.196.0/24 -m multiport > --destination-port 80,443 --syn -m connlimit > --connlimit-above 50 -j DROP > > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > _______________________________________________ > 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/ > > |
From: Ryan B. <rya...@ow...> - 2013-09-17 15:29:40
|
From: Thomas Eckert <tho...@gm...> Reply-To: "mod...@li..." <mod...@li...> Date: Tuesday, September 17, 2013 11:20 AM To: "mod...@li..." <mod...@li...> Subject: Re: [mod-security-users] SecReadStateLimit shutting down server without hitting limit > I tried to follow the advice given at > > http://blog.spiderlabs.com/2011/07/advanced-topic-of-the-week-mitigating-slow- > http-dos-attacks.html > which mentions SecReadStateLimit. The problem is that mod_status creates many connections to loopback URI and it is exceeding the thresholds set by this directive. This directive needs to have a whitelist capability so you can allow connection from 127.0.0.1 to bypass - https://www.modsecurity.org/tracker/browse/MODSEC-199 > > If using this directive is discouraged why have it in the first place ? Reindl is talking about handling DoS blocking issues at a lower network level (IPTables) vs. using ModSecurity and not specifically about SecReadStateLimit. -Ryan > > Cheers, > Thomas > > > On Tue, Sep 17, 2013 at 4:58 PM, Reindl Harald <h.r...@th...> wrote: >> >> Am 17.09.2013 16:44, schrieb Thomas Eckert: >>> > mod_security 2.7.3 >>> > apache 2.4.4 >>> > >>> > Trying to get some SlowHTTP defenses up and running using mod_security but >>> SecReadStateLimit is giving me a hard >>> > time. It reports >>> > ModSecurity: Access denied with code 400. Too many threads [1024] of 15 >>> allowed in READ state from 127.0.0.1 - >>> > Possible DoS Consumption Attack >>> > even though the only connection existing is my access of mod_status. I >>> cannot see those 1024 threads it keeps on >>> > complaining about using ps. >>> > >>> > Is that behaviour known of? >> >> no idea *but* use iptables for such things instead defend them in >> the application layer - this is a plain wrong usage of layered >> security - waht you want is to protect the application layer >> and not fight inside the application-layer with attacks >> >> iptables -A INPUT -p tcp -i eth0 ! -s 192.168.196.0/24 >> <http://192.168.196.0/24> -m multiport --destination-port 80,443 --syn -m >> connlimit >> --connlimit-above 50 -m limit --limit 100/h -j LOG --log-prefix "Firewall >> Slowloris: " >> iptables -A INPUT -p tcp -i eth0 ! -s 192.168.196.0/24 >> <http://192.168.196.0/24> -m multiport --destination-port 80,443 --syn -m >> connlimit >> --connlimit-above 50 -j DROP >> >> >> ----------------------------------------------------------------------------->> - >> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! >> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint >> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack >> includes >> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. >> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk >> _______________________________________________ >> 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/ >> > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ > hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, > SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk___ > ____________________________________________ 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/ |
From: Reindl H. <h.r...@th...> - 2013-09-17 15:30:40
Attachments:
signature.asc
|
"discouraged" by me not by modsec most likely i see security as a layered thing * network * network firewall * application * application firewall * web-application running inside the application-layer each layer is vulnerable in different ways so if it comes to security catch problems at the first possible one if you can identify and block a request directly in the network layer -> do it there if you have *a lot* of attackers even if modsec will do what you want you are lost because the increased load of having the application layer itself involved to fight against the attack will kill you, the same hard attack filtered with iptables may make the difference and if you ever had the "luck" of a real distributed DOS you start even to consider how to block attacks long before they reach the server machine at all because in some cases otherwise you do not survive Am 17.09.2013 17:20, schrieb Thomas Eckert: > I tried to follow the advice given at > http://blog.spiderlabs.com/2011/07/advanced-topic-of-the-week-mitigating-slow-http-dos-attacks.html > which mentions SecReadStateLimit. > > If using this directive is discouraged why have it in the first place ? > > On Tue, Sep 17, 2013 at 4:58 PM, Reindl Harald <h.r...@th... <mailto:h.r...@th...>> wrote: > > > Am 17.09.2013 16:44, schrieb Thomas Eckert: > > mod_security 2.7.3 > > apache 2.4.4 > > > > Trying to get some SlowHTTP defenses up and running using mod_security but SecReadStateLimit is giving me a hard > > time. It reports > > ModSecurity: Access denied with code 400. Too many threads [1024] of 15 allowed in READ state from 127.0.0.1 - > > Possible DoS Consumption Attack > > even though the only connection existing is my access of mod_status. I cannot see those 1024 threads it keeps on > > complaining about using ps. > > > > Is that behaviour known of? > > no idea *but* use iptables for such things instead defend them in > the application layer - this is a plain wrong usage of layered > security - waht you want is to protect the application layer > and not fight inside the application-layer with attacks > > iptables -A INPUT -p tcp -i eth0 ! -s 192.168.196.0/24 <http://192.168.196.0/24> -m multiport > --destination-port 80,443 --syn -m connlimit > --connlimit-above 50 -m limit --limit 100/h -j LOG --log-prefix "Firewall Slowloris: " > iptables -A INPUT -p tcp -i eth0 ! -s 192.168.196.0/24 <http://192.168.196.0/24> -m multiport > --destination-port 80,443 --syn -m connlimit > --connlimit-above 50 -j DROP |