|
From: baptx <bap...@gm...> - 2020-04-29 14:12:13
|
If modsecurity-crs config files are commented and not used, I can see this message in the file troubleshooting.log: "Could not set variable "IP.bf_counter" as the collection does not exist." I also noticed that I have to remove the LocationMatch tag to log the the 401 Unauthorized page in the file troubleshooting.log. On Wed, 29 Apr 2020 at 12:21, baptx <bap...@gm...> wrote: > Actually, the IP address was not blocked by the configuration I shared but > by modsecurity-crs. > If I disable modsecurity-crs config files in > /etc/apache2/mods-enabled/security2.conf and keep only modsecurity config > files, I can see that my configuration shared previously does not even > block IP addresses at all, do you know why? > > > On Tue, 28 Apr 2020 at 19:05, baptx <bap...@gm...> wrote: > >> Hello, >> >> I would like to block a user IP address after several failed login >> attempts on an Apache web server using HTTP authentication (Basic or >> Digest). >> The configuration I am using should block an IP address after 3 errors >> (HTTP 401 Unauthorized response) but I can still try as many passwords as I >> want. If I try the correct password, I can see the HTTP 403 Forbidden error >> page. And if I press Ctrl+Shift+Del in Firefox to clear "Active Logins", I >> can continue the bruteforce again. >> It looks like ModSecurity is only blocking the page behind the login but >> not an actual bruteforce. Is it a ModSecurity bug or a problem with my >> configuration? >> >> I have added the following configuration in >> /etc/modsecurity/modsecurity_custom_rules.conf, based on the "IP-Based >> Blocking" example of >> https://snippets.aktagon.com/snippets/563-brute-force-authentication-protection-with-modsecurity >> (replace /testpage with a path using HTTP authentication): >> >> <LocationMatch /testpage> >> # Uncomment to troubleshoot >> #SecDebugLogLevel 9 >> #SecDebugLog /tmp/troubleshooting.log >> >> # Enforce an existing IP address block >> SecRule IP:bf_block "@eq 1" \ >> "id:1,phase:2,deny,\ >> msg:'IP address blocked because of suspected brute-force >> attack'" >> >> # Check that this is a GET >> SecRule REQUEST_METHOD "@streq GET" >> "id:2,phase:5,chain,t:none,nolog,pass" >> # AND Check for authentication failure and increment >> counters >> SecRule RESPONSE_STATUS "^401" \ >> "setvar:IP.bf_counter=+1" >> >> # Check for too many failures from a single IP address. Block for >> 10 minutes. >> SecRule IP:bf_counter "@ge 3" \ >> "id:3,phase:5,pass,t:none, \ >> setvar:IP.bf_block,\ >> setvar:!IP.bf_counter,\ >> expirevar:IP.bf_block=600" >> </LocationMatch> >> >> Thanks. >> > |
