Thanks for the update Guillaume. Good to know so that we don't spin our wheels on our end. We should still look to see if there is another method for identifying these conditions.
-Ryan From: Guillaume Bilodeau <[email protected]<mailto:[email protected]>> Date: Mon, 2 May 2011 08:16:55 -0500 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Owasp-modsecurity-core-rule-set] Slow HTTP DOS protection not behaving as expected Hi all, I have opened a bug report at Apache and they have confirmed that issues in HTTPD Core are causing the following problems: - Apache doesn't always return a 408 when a request time out is detected (various cases) - Apache doesn't handle a request time out properly when the URL corresponds to a RedirectMatch directive More details here: https://issues.apache.org/bugzilla/show_bug.cgi?id=51103 Thank you all for your time and precious help! Cheers, GB On Tue, Apr 19, 2011 at 9:16 AM, Guillaume Bilodeau <[email protected]<mailto:[email protected]>> wrote: Our latest tries looked like this: In modsecurity_crs_11_slow_dos_protection.conf: #SecReadStateLimit 10 <IfModule reqtimeout_module> RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500 </IfModule> SecRule RESPONSE_STATUS "@streq 408" "phase:5,t:none,nolog,pass,setvar:ip.slow_dos_counter=+1,expirevar:ip.slow_dos_counter=60" SecRule IP:SLOW_DOS_COUNTER "@gt 5" "phase:1,t:none,log,drop,msg:'Client Connection Dropped due to high # of slow DoS alerts'" First test http_dos_cli --host 1.2.3.4 --port 80 --path /doLogin.html --slow-headers --post --connections 1000 --rate 1000 --timeout 5 Tool establishes connections, starts sending headers After 20 seconds, requests start timing out Within a minute, tool cannot connect anymore Outside IP can connect to Apache In error_log: [Tue Apr 19 08:55:09 2011] [info] [client 5.6.7.8] Request header read timeout [Tue Apr 19 08:55:09 2011] [error] [client 5.6.7.8] request failed: error reading the headers In Wireshark: HTTP response code 400 (Bad Request) Second test http_dos_cli --host 1.2.3.4 --port 80 --path /doLogin.html --slow-post --post-field j_username --connections 1000 --rate 1000 --timeout 5 Tool establishes connections, starts sending post data Tool caps at 1000 connections, never receives any error Outside IP cannot connect to Apache In error_log: [Tue Apr 19 09:01:20 2011] [info] [client 5.6.7.8] Request body read timeout In Wireshark: HTTP response code 200 (Found) So... In both cases, Apache (mod_reqtimeout I suppose) seems to be enforcing the header / body timeout correctly. It's just that it's not returning a 408 in either case. On Sat, Apr 16, 2011 at 10:18 AM, Ryan Barnett <[email protected]<mailto:[email protected]>> wrote: Have you tried using header=timeout directive against the slow dos tool to prevent slow headers? Wonder if that part works for you or if it also is returning the 200. If that doesn't work then maybe it is related to Solaris OS. These settings worked for me on Mac OSX and Ubuntu. On Apr 16, 2011, at 9:58 AM, "Guillaume Bilodeau" <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote: We're using an Apache 2.2.17 that was built from scratch on a Solaris box. On Sat, Apr 16, 2011 at 9:44 AM, Ryan Barnett <<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote: What apache version are you using? On Apr 16, 2011, at 9:43 AM, "Guillaume Bilodeau" <<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>> wrote: A little more information on the 200 return code: It seems that mod_reqtimeout is not closing the connection after the 20 seconds, but rather truncating the request and letting it go through. So the request is actually processed, and since the URL is referring to an actual resource, a 200 code is returned. Surely there must be a problem with our configuration? Or maybe our Apache build? Cheers, GB On Sat, Apr 16, 2011 at 12:55 AM, Brian Rectanus <<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>> wrote: Probably not "disastrous" :) You have the overhead of the TCP 3-way handshake and also the shutdown, but the browsers should be using SSL session resumption, which is not connection based. It uses cached SSL session IDs and should be reused on each connection up to the timeout - just make sure this is enabled in the Apache config. Personally, I find that about 3 second timeouts w/low request limit works well for keepalives, so it may be enough to just limit the keepalive timeout and number of requests (say 3 second timeout w/9 requests limit instead of completely disabling them). It really depends on your latency requirements for your site. -B On Thu, Apr 14, 2011 at 2:37 PM, Guillaume Bilodeau <<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>> wrote: > We will try turning off connection keep-alive to see how Apache will react. > However, isn't turning this off going to have a disastrous impact on > connection performance, especially since all traffic will be SSL? > > On Thu, Apr 14, 2011 at 3:19 PM, Ivan Ristic > <<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>> > wrote: >> >> Yes, it's probably because of keep-alives. Sounds like a bug in the >> reqtimeout module, because, if the connection stays open, the module >> isn't achieving much. >> >> IIRC, ModSecurity will turn off keep-alives on a connection on which it >> blocks. >> >> >> On Thu, Apr 14, 2011 at 8:11 PM, Guillaume Bilodeau >> <<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>> >> wrote: >> > Hi Ryan, >> > We installed WireShark and started sniffing on all traffic. It seems >> > that >> > Apache is returning a 200 status code instead of a 408 when the request >> > reaches 30 seconds, so from what I understand ModSecurity can't do much >> > about that. The funny thing is, if we follow one of the TCP streams, we >> > see >> > that http_dos_cli keeps sending data even after receiving the 200 code. >> > Maybe something to do with keep-alive connections? >> > Cheers, >> > GB >> > On Thu, Apr 14, 2011 at 2:12 PM, Ryan Barnett >> > <<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>> >> > wrote: >> >> >> >> OK, if mod_reqtimeout is installed and that directive is working, then >> >> after 30 sec if Apache has not received the entire request body then it >> >> should terminate the request with a 408 status code. The ModSecurity >> >> CRS >> >> rules are simply monitoring if/how many 408 alerts are generated by >> >> Apache >> >> per client. After a certain amount, then ModSecurity will step in on >> >> subsequent requests in phase:1 and do drop actions. >> >> >> >> So, by monitoring your Apache error log while you are running your >> >> http_dos_cli tool, does Apache generate 408 alerts after 30 secs? If >> >> not, >> >> then I don't think that the mod_reqtimeout module or directive is >> >> working. >> >> >> >> -Ryan >> >> >> >> >> >> From: Guillaume Bilodeau >> >> <<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>>> >> >> Date: Thu, 14 Apr 2011 13:07:41 -0500 >> >> To: Ryan Barnett >> >> <<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>>> >> >> Cc: >> >> >> >> "<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>>" >> >> >> >> <<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>>> >> >> Subject: Re: [Owasp-modsecurity-core-rule-set] Slow HTTP DOS protection >> >> not behaving as expected >> >> >> >> Hi Ryan, >> >> >> >> I'm no Apache expert, but AFAICT the req_timeout module is installed. >> >> A >> >> /server-info shows the req_timeout.c module with the RequestReadTimeout >> >> parameter. >> >> >> >> Thanks, >> >> GB >> >> >> >> On Thu, Apr 14, 2011 at 1:56 PM, Ryan Barnett >> >> <<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>>> >> >> wrote: >> >> Did you install the reqtimeout module? >> >> >> >> # >> >> # Mitigate Slow HTTP POST attacks >> >> # >> >> # Must have the mod_reqtimeout module installed >> >> # You should adjust the RequestReadTimeout body directive setting to a >> >> limit >> >> # that will allow any legitimate slow clients or large file uplaods. >> >> # >> >> <IfModule reqtimeout_module> >> >> RequestReadTimeout body=30 >> >> </IfModule> >> >> >> >> -Ryan >> >> >> >> >> >> >> >> From: Guillaume Bilodeau >> >> >> >> <<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>><mailto:<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>>>> >> >> Date: Thu, 14 Apr 2011 12:33:52 -0500 >> >> To: >> >> >> >> "<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>><mailto:<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>>>" >> >> >> >> <<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>><mailto:<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:<mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>><mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>>>> >> >> Subject: [Owasp-modsecurity-core-rule-set] Slow HTTP DOS protection not >> >> behaving as expected >> >> >> >> Hi all, >> >> >> >> We are trying to setup the OWASP Core Rule Set to protect our >> >> application >> >> from Slow HTTP DOS attacks. >> >> >> >> We have setup ModSecurity 2.5.13 on our Apache 2.2.17 instance, loaded >> >> the >> >> module, and included all CRS base rules plus >> >> modsecurity_crs_11_slow_dos_protection.conf. We didn't change the >> >> settings >> >> defined in the conf file, so SecReadStateLimit is set to 5 and >> >> RequestReadTimeout is set to body=30. We are using the http_dos_cli >> >> command >> >> line tool to do our tests, with the connection parameter set to 500. >> >> >> >> When running the slow-headers test, ModSecurity seems to be protecting >> >> the >> >> application correctly, dropping most (all?) requests from the tester's >> >> IP >> >> and allowing requests from a different IP to be served. However, when >> >> running the slow-post test, ModSecurity doesn't seem to be doing >> >> anything. >> >> From what I understand, the test successfully creates the 500 >> >> connections >> >> and keeps them open; none of them are dropped. Requests coming from a >> >> different IP are not served and eventually time out. A tail -f >> >> error_log >> >> shows nothing except the eventual message on MaxClients (set to 300 >> >> now) >> >> being reached. Interestingly, when we kill the http_dos_cli process, >> >> the >> >> error_log is then flooded with hundreds of entries such as this: >> >> >> >> >> >> [Mon Nov 22 17:44:46 2010] [warn] ModSecurity: Access denied with code >> >> 400. >> >> Too many connections [6] of 5 allowed in READ state from 211.144.112.20 >> >> - >> >> Possible DoS Consumption Attack [Rejected] >> >> >> >> (this has been taken from the SpiderLabs blog entry, dates and IPs are >> >> obviously different) >> >> >> >> Any idea on why this isn't behaving like we're expecting it to be? >> >> >> >> Thanks! >> >> GB >> >> >> >> >> >> >> >> >> > >> > >> > _______________________________________________ >> > Owasp-modsecurity-core-rule-set mailing list >> > <mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> >> > >> > <mailto:[email protected]<mailto:[email protected]>> >> > >> > [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> >> > <<https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set>https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set> >> > >> > <https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set> >> > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set >> > >> > >> >> >> >> -- >> Ivan Ristić > > > _______________________________________________ > Owasp-modsecurity-core-rule-set mailing list > <mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> > > <mailto:[email protected]<mailto:[email protected]>> > > [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> > <<https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set>https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set> > <https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set> > https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set > > _______________________________________________ Owasp-modsecurity-core-rule-set mailing list <mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>><mailto:<mailto:[email protected]<mailto:[email protected]>>[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> <https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set>https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. _______________________________________________ Owasp-modsecurity-core-rule-set mailing list [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. _______________________________________________ Owasp-modsecurity-core-rule-set mailing list [email protected] https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
