0

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?

xperator
  • 437
  • 2
  • 11
  • 23
  • Fail2Ban can be made to communicate with an external firewall like CloudFlare to ban any IPs that trigger a rule. I have an [article on fail2ban integration with CloudFlare](https://www.photographerstechsupport.com/aws-amazon-web-services/protecting-amazon-linux-server-fail2ban-cloudflare-wordpress/) that works for AWS and CloudFlare, but the technique is broadly applicable. Basically, if anyone hits a URL which is only used by attackers ban them immediately. If they trigger a softer rule they get a few goes then get banned. – Tim Sep 08 '19 at 23:21

2 Answers2

1

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...

t2m
  • 136
  • 1
  • 7
  • Your explanation is logical. I changed my `maxtry` to 10. and yeah all links are in https. Right now I'm trying to look for a solution to insta ban the ip's that scan for 'admin' keyword in the url. I know I have to just do a `if` in nginx and return 444 if the regex matches `admin` but I can't find a way to have fail2ban use that information and instantly ban the ip that is trying to be funny with all their `/phpmyadmin`, `/wp-admin`. Let me know if you have a solution for that as well. Thanks! – xperator Sep 09 '19 at 17:38
-1

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.

Rahul Biswas
  • 119
  • 1
  • 1
  • 13