I have my Virtual Machine with Ubuntu 20.04 installed. In it I'm using Apache2 web server as a WAF with ModSecurity 2.9.3 module that uses OWASP rules, it is listening to port 80 and 443.
Then I have installed XAMPP to use in it the DVWA application. Since the Apache web server in XAMPP can't listen to the same ports of Apache2 (there would be a conflict), Apache web server is listening to 8012 for HTTP and 4431 for HTTPS.
I got through the process to make the DVWA requests passing through the WAF and reach the application by using VirtualHosts. Everything is okay at the moment. The Project involves the testing of the WAF against malcious attacks, and it works fine for mosts of the attacks, ModSecurity detects and blocks SQL Injection, XSS , FLI, RFI, and so on, but when I test the DDoS attack, it detects it as a SCANNER attack and I don't know why (and then it blocks the attack).
I tested the DDoS attack with WFuzz and Hydra, trying to guess the password of the admin in a particular page of DVWA. For WFuzz I used this command :
wfuzz -c -w ~/SecLists/Passwords/probable-v2-top207.txt -b 'security=low;
PHPSESSID=cookieSession' 'http://localhost/dvwa/vulnerabilities/brute/
?username=admin&password=FUZZ&Login=Login'
Wfuzz starts sending the requets which get immediately blocked (error 443) and in the log error file of Apache2, I get some messages referred to the attack of this type ( + other messages related to what ModSec does) :
[Thu Apr 07 09:50:33.960952 2022] [:error] [pid 3803:tid 140532596565760]
[client 127.0.0.1:47826] [client 127.0.0.1] ModSecurity: Warning. Match of "rx
^(?:urlgrabber/[0-9\\\\.]+ yum/[0-9\\\\.]+|mozilla/[0-9\\\\.]+ ecairn-grabber/[0-9\\\\.]+
\\\\(\\\\+http://ecairn.com/grabber\\\\))$" against "REQUEST_HEADERS:User-Agent"
required. [file "/usr/share/modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf"]
[line "55"] [id "913100"] [msg "Found User-Agent associated with security scanner"]
[data "Matched Data: Wfuzz found within REQUEST_HEADERS:User-Agent: Wfuzz/2.4.5"]
[severity "CRITICAL"] [ver "OWASP_CRS/3.4.0-dev"] [tag "application-multi"] [tag
"language-multi"] [tag "platform-multi"] [tag "attack-reputation-scanner"] [tag
"paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/118/224/541/310"] [tag
"PCI/6.5.10"] [hostname "localhost"] [uri "/dvwa/vulnerabilities/brute/"] [unique_id
"Yk6XyWgIm0NzeaCPwEBVrAAAAE0"]
At first I didn't know why the detection was related to a SCANNER attack. From
[msg "Found User-Agent associated with security scanner"][data "Matched Data: Wfuzz found within REQUEST_HEADERS:User-Agent: Wfuzz/2.4.5"]
I thought that the problem was related to the User-Agent: Wfuzz/2.4.5.So I tried a custom User-Agent :
wfuzz -c -w ~/SecLists/Passwords/probable-v2-top207.txt -b 'security=low;
PHPSESSID=cookieSession' -H 'User-Agent:Mozilla/5.0 (X11; Ubuntu; Linux
x86_64; rv:98.0) Gecko/20100101 Firefox/98.0' 'http://localhost/dvwa/vulnerabilities
/brute/?username=admin&password=FUZZ&Login=Login'
However this time, the requets were received by the DVWA (error 200), but even after like 100 requests ModSecurity was not detecting the DDoS attack (I was not getting 443 error), even though "I" was doin lots of requests in the application. Using Hydra I get basically the same result. Any suggestions/help is very appreciated, this is not a life problem because I can delete this part from the project but I would like to know what's not functioning. I've been trying looking at OWASP rules files but I was getting nowhere with them and basically everyone in the web say that no one should be messing/editing those rules.
My goal would be :
After ModSecurity detects 20 tries, it blocks the upcoming requests, sending back to the attacker 443 error.
OWASP ModSecurity Core Rule Set Developer on Duty here. First thing to note, ModSecurity version 2.9.3 is quite old (2018!). The current v2 release is version 2.9.5, which features important security and bug fixes. You should seriously consider using the latest version for anything beyond a private sandbox.
Second thing to note, OWASP Core Rule Set (CRS) version 3.4 is our development branch. It's under heavy development and is being radically changed right now (this very week, even). You'll probably want to use our latest official release, which is version 3.3.2 (see https://github.com/coreruleset/coreruleset/releases/tag/v3.3.2).
Wfuzz is indeed listed as a scanner (you can find it listed in the file
rules/scanners-user-agents.data). CRS rule 913100 inspects the User-Agent headers of requests and compares them against the contents ofscanners-user-agents.data. That's why you're seeing log lines containing "Found User-Agent associated with security scanner": the presence of "Wfuzz" causes that rule to match. You can find the rule in the filerules/REQUEST-913-SCANNER-DETECTION.conf, if you're interested.ModSecurity is not designed to prevent (D)DoS attacks. It can be made to do so, but it isn't good at it. In fact, just a few days ago, we removed the DoS capabilities from the CRS v3.4/dev branch (like I said, the dev branch is being radically changed as we speak!). For an explanation on this topic, see https://github.com/coreruleset/dos-protection-plugin-modsecurity-v2#plugin-expectations-suitability-and-scale.
If you really want to test DoS rules, take a look at the CRS 3.3.2 release, which still included our DoS rules as standard (in the file
rules/REQUEST-912-DOS-PROTECTION.conf). Find the section "Anti-Automation / DoS Protection" in the main configuration file,crs-setup.conf, to configure the DoS rules for use. There are also blog posts and tutorials available online that walk through how to write your own DoS protection rules for ModSecurity, similar to what you described (e.g. "detect 20 requests, then block further requests"). It just requires leveraging ModSecurity's persistent collections mechanism, to store state information between requests (e.g. a running count of "how many requests has this IP address sent?").But, to reiterate the point: neither ModSecurity or OWASP CRS will stop DoS attacks by default.
Good luck with your project!