Skip to content

SecConnReadStateLimit and SecReadStateLimit doesn't work with Apache 2.4.x #786

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mariuszzbrowski opened this issue Oct 13, 2014 · 6 comments
Assignees

Comments

@mariuszzbrowski
Copy link

Hello,

I try to protect apache server before Slow HTTP Headers attack using SecConnReadStateLimit and SecReadStateLimit but this directives doesn't work with Apache 2.4.x.

I've tested few version of Apache and ModSecurity on centos 6 and centos 7 servers without success.

Apache version tested:
2.4.3 Package from internal repository
2.4.6 Package form repository
2.4.9 Compiled on my own ./configure --prefix=/usr/local/apache-2.4.9 --with-included-apr -enable-nonportable-atomics=yes --enable-so --enable-ssl

ModSecurity version tested:
2.8.0 Compiled on my own ./configure --with-apxs=path_to_apxs --with-apu=patch_to_apu --with-apr=path_to_apr
2.7.5 Compiled on my own ./configure --with-apxs=path_to_apxs --with-apu=patch_to_apu --with-apr=path_to_apr
2.7.3 Package from repository

ModSecurity configuration (2.7.3 and 2.7.5):
LoadFile /usr/lib64/libxml2.so
LoadFile /usr/lib64/liblua-5.1.so

LoadModule security2_module modules/mod_security2.so

SecRuleEngine on

SecTmpDir /tmp/
SecDataDir /tmp/

SecDebugLog /content/logs/httpd/debug.log
SecDebugLogLevel 9

SecReadStateLimit 50

SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

SecAuditLogParts ABIJDEFHZ

SecAuditLogType Serial
SecAuditLog /var/log/httpd/modsec_audit.log

SecRule RESPONSE_STATUS "@Streq 408" "phase:5,t:none,log,msg:'Counter +1',pass,setvar:ip.slow_dos_counter=+1, expirevar:ip.slow_dos_counter=60,id:'10'"

SecRule IP:SLOW_DOS_COUNTER "@gt 5" "phase:1,t:none,log,deny,msg:'Client Connection Dropped due to high number of slow DoS alerts',id:'11'"

SecDefaultAction "phase:2,pause:3000,deny,nolog,auditlog"

ModSecurity configuration (2.8.0):
LoadFile /usr/lib64/libxml2.so
LoadFile /usr/lib64/liblua-5.1.so

LoadModule security2_module modules/mod_security2.so

SecRuleEngine on

SecTmpDir /tmp/
SecDataDir /tmp/

SecDebugLog /content/logs/httpd/debug.log
SecDebugLogLevel 9

SecConnEngine on
SecConnReadStateLimit 50

SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

SecAuditLogParts ABIJDEFHZ

SecAuditLogType Serial
SecAuditLog /var/log/httpd/modsec_audit.log

SecRule RESPONSE_STATUS "@Streq 408" "phase:5,t:none,log,msg:'Counter +1',pass,setvar:ip.slow_dos_counter=+1, expirevar:ip.slow_dos_counter=60,id:'10'"

SecRule IP:SLOW_DOS_COUNTER "@gt 5" "phase:1,t:none,log,deny,msg:'Client Connection Dropped due to high number of slow DoS alerts',id:'11'"

SecDefaultAction "phase:2,pause:3000,deny,nolog,auditlog"

I've tested configuration using slowhttptest tool and behavior is that ModSecurity don't block new incoming connections after reach Read Connection limit..

With Apache 2.2.15 and ModSecurity 2.7.3 intstalled form Repository on Centos 6 all configuration works perfect.

Has someone had the same problem with apache 2.4.x ?

Please advise.

@doantranhoang
Copy link

When I deploying ModSec 2.8.0 (Build with Apache Runtime in httpd 2.2.15) and Nginx 1.6.2 I also got problem like you.
I think something wrong in ModSec 2.8.0. Has anyone could explain this case for ours?

@zimmerle
Copy link
Contributor

@mariuszzbrowski You may want to achieve similar results by using the directives: SecConnReadStateLimit and SecConnWriteStateLimit.

You may want to look those links:

Regarding the rules that you have created, you may want to look at the '/content/logs/httpd/debug.log'. It should contains useful information how those variables of your rules are being resolved, helping you to figure out what is going wrong.

@zimmerle
Copy link
Contributor

@doantranhoang Can you give more details about what you want to achieve? Or details on the problems that you are facing? Maybe a good idea is to open a new ticket of fire questions to our users mailing list. I would say that you will probably have a fast response if you ask in our users mailing list.

@zimmerle
Copy link
Contributor

@doantranhoang if you are also interested in protect your server from "Slow HTTP", please notice that the SecConnReadStateLimit and SecConnWriteStateLimit directives are Apache only. Let me know what exactly problem that you are facing and we can give you better help.

@doantranhoang
Copy link

@zimmerle Thanks you so much. I'm wrong when not reading docs carefully so I thought SecConnReadStateLimit and SecConnWriteStateLimit directives used for all platforms.

Today I have a problem when I use CRS to detect Slow HTTP Attack with ModSec on Nginx, i setting timeout for requests with Nginx's directives

client_header_timeout 30;
client_body_timeout 30;

Next, I use two following CRS rules in modsecurity_crs_11_slow_dos_protection.conf

SecRule RESPONSE_STATUS "@Streq 408" "phase:5,t:none,log,msg:'Counter +1',pass,setvar:ip.slow_dos_counter=+1, expirevar:ip.slow_dos_counter=60,id:'10'"

SecRule IP:SLOW_DOS_COUNTER "@gt 5" "phase:1,t:none,log,deny,msg:'Client Connection Dropped due to high number of slow DoS alerts',id:'11'"

Test Slow POST Attack with slowloris.pl and check my logs

"POST / HTTP/1.1" 408 .....
"POST / HTTP/1.1" 408 .....
"POST / HTTP/1.1" 408 .....
"POST / HTTP/1.1" 408 .....

It's really has many timeout responses status (408) but ModSecurity rule not capturing this, so two CRS rules above not working. I try to test with others RESPONSE_STATUS or RESPONSE_HEADERS and it working perfetch except 408.

Has anyone try this rules success with Nginx and ModSecurity?

@MarcoRemy
Copy link

Exact same Problem here!
For days i'm trying to mitigrate slow dos attacks with SecReadStateLimit.

System:

Ubuntu 14.04
Apache 2.4.7
Modsec 2.7.7
Modsec CRS 2.2.8

Among my configuration I Include the modsecurity_crs_11_slow_dos_protection.conf. While ruleset-protection against slow POST attacks is working fine the SecReadStateLimit (slow HTTP protection) doesn't work at all. It does not block new connections if limit is reached. Gave me a hard time and i'm convinced not making errors =/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants