Home / server / Questions / 982415
Accepted
xperator
Asked: 2019-09-09 02:59:18 +0800 CST

Is it wise to have fail2ban block 301 brute forces when you have http to https redirection enabled?

  • 772

Recently my servers started getting bombarded by anonymous scanners/brute forces.

This is how my nginx access.log looked like after the attacks :

xxx.xxx.xxx.xxx - - [07/Sep/2019:23:30:16 +0200] "GET /phpMyAdmin/index.php HTTP/1.1" 404 548 "-" "Mozilla/5.0..
xxx.xxx.xxx.xxx - - [07/Sep/2019:23:30:18 +0200] "GET /admin/index.php HTTP/1.1" 404 548 "-" "Mozilla/5.0..

Along with tons of other urls/admin pages/random names they tried to access. I did some research and fail2ban came up. So I installed it.

I left it on for some time but attacks were happening again. I realized the default [nginx-botsearch] does not catch all the attacks, not to mention it's log path was mis-configured.

I did some googling and settled on this custom filter:

# /etc/fail2ban/jail.local

[nginx-404-errors]
enabled = true
port     = http,https
logpath  = /var/log/nginx/*.log
maxretry = 2

# /etc/fail2ban/filter.d/nginx-404-errors.conf

[Definition]
failregex = ^<HOST>.*"(GET|POST|HEAD).*" (404|444|403|400) .*$
ignoreregex =

This worked very well, but the attacker/s decided to hit the http. But the thing is I have a http to https redirection rule on nginx.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri;
}

So now I'm getting tons of 301 redirections logs in access.log. I thought maybe I should just add a 301 to the regex I used above. So now it's :

failregex = ^<HOST>.*"(GET|POST|HEAD).*" (404|444|403|400|301) .*$

The attacks has stopped for now. But I'm worried the normal visitors might get into trouble when trying to reach the site on http and fail2ban might pick on them.

Is this the way I should mitigate this kind of brute force attacks? Or am I supposed to take a different route?

nginx

2 Answers

  1. Best Answer

    I would take into consideration, how your pages are linked within the HTML. If your visitor only gets https://-Links, once he upgraded it's connection to https, you can leave the 301-Bans active. If every single click on your website results in a 301-redirect to it's https-equivalent, it's obviously not wise to do. Also, I recommend to increase the legit amount of 301's up to 10 or 15.

    Much more problematic is the ban after just 2 hits to a 404 page. This will make the use of a content management system on your website very difficult, as every try to link to a nonexistent image or URL will result in a BAN. Raise the limit significant to a two-digit number. Ten 404-Requests won't break your server. They happen regulary even at legit usage, especially on multi-language-Sites, missing favicon.ico, new page deployments, delayed image uploads, etc...

    • 1

  2. The best thing to do now would be redirecting http to https as http is becoming obsolete. Google also ranks https pages higher than non http pages. Best thing to do will be setting up permanent redirect from http to https so that people can't access http version of the site. Looking into ur config., i don't feel like u r going to face any problem. If you face any problem (check ur log regularly) then please post the logs here and i will be happy to help u out.

    • -1