0

I'm trying to troubleshoot Fail2ban recognizing our http-get-dos trigger, but not actually banning the offending host. I can see it adding entries to iptables rules, but they don't have any affect.

So I tried to manually ban a host, and I cant get that to work either.

I'm trying to drop all traffic from a specific host. I inserted a DROP rule, and appended a DROP rule, so they bookend everything. I've X'ed out the ip address of the host I'm trying to ban. This host can still connect to my web server, and get web pages.

I must be missing something stupid. Here's the iptables -nvL output:

sudo iptables -nvL
Chain INPUT (policy ACCEPT 6226 packets, 31M bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *       XX.XX.XX.XX         0.0.0.0/0
85222 7764K fail2ban-xmlrpc  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
85222 7764K fail2ban-HTTP  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
85222 7764K fail2ban-HTTP  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
 137K   16M fail2ban-BadBots  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
   82  7136 fail2ban-sasl  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 25,465,587,143,220,993,110,995
   82  7136 fail2ban-postfix  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 25,465,587
 137K   16M fail2ban-apache-overflows  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
 137K   16M fail2ban-apache-noscript  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
16620 1181K fail2ban-ssh-ddos  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 22
16621 1181K fail2ban-ssh  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 22
    0     0 DROP       all  --  *      *       XX.XX.XX.XX         0.0.0.0/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 6649 packets, 5149K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain fail2ban-BadBots (1 references)
 pkts bytes target     prot opt in     out     source               destination
 137K   16M RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain fail2ban-HTTP (2 references)
 pkts bytes target     prot opt in     out     source               destination
 170K   16M RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain fail2ban-apache-noscript (1 references)
 pkts bytes target     prot opt in     out     source               destination
 137K   16M RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain fail2ban-apache-overflows (1 references)
 pkts bytes target     prot opt in     out     source               destination
 137K   16M RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain fail2ban-postfix (1 references)
 pkts bytes target     prot opt in     out     source               destination
   82  7136 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain fail2ban-sasl (1 references)
 pkts bytes target     prot opt in     out     source               destination
   82  7136 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain fail2ban-ssh (1 references)
 pkts bytes target     prot opt in     out     source               destination
16621 1181K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain fail2ban-ssh-ddos (1 references)
 pkts bytes target     prot opt in     out     source               destination
16620 1181K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain fail2ban-xmlrpc (1 references)
 pkts bytes target     prot opt in     out     source               destination

and here's the iptables -S output:

sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-BadBots
-N fail2ban-HTTP
-N fail2ban-apache-noscript
-N fail2ban-apache-overflows
-N fail2ban-postfix
-N fail2ban-sasl
-N fail2ban-ssh
-N fail2ban-ssh-ddos
-N fail2ban-xmlrpc
-A INPUT -s XX.XX.XX.XX/32 -j DROP
-A INPUT -p tcp -m tcp --dport 80 -j fail2ban-xmlrpc
-A INPUT -p tcp -m tcp --dport 80 -j fail2ban-HTTP
-A INPUT -p tcp -m tcp --dport 80 -j fail2ban-HTTP
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-BadBots
-A INPUT -p tcp -m multiport --dports 25,465,587,143,220,993,110,995 -j fail2ban-sasl
-A INPUT -p tcp -m multiport --dports 25,465,587 -j fail2ban-postfix
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-overflows
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-noscript
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh-ddos
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -s XX.XX.XX.XX/32 -j DROP
-A fail2ban-BadBots -j RETURN
-A fail2ban-HTTP -j RETURN
-A fail2ban-HTTP -j RETURN
-A fail2ban-apache-noscript -j RETURN
-A fail2ban-apache-overflows -j RETURN
-A fail2ban-postfix -j RETURN
-A fail2ban-sasl -j RETURN
-A fail2ban-ssh -j RETURN
-A fail2ban-ssh-ddos -j RETURN
-A fail2ban-xmlrpc -j RETURN
  • How do you know that that IP address is still connecting to your server and getting web pages? – Michael Hampton Jul 03 '20 at 04:09
  • I control both servers. I have a tail -f on my fail2ban log, and I can see the http-get-dos entries fly by when I run my wget loop script. I can also confirm that wget is successfully connecting and saving the css file the script has it downloading 200 times. – Joe Miller Jul 03 '20 at 04:25
  • Are you using CloudFlare or a similar service? – Michael Hampton Jul 03 '20 at 04:30
  • They are AWS EC2's. We are not using any additional services. No CDN. – Joe Miller Jul 03 '20 at 04:34
  • No load balancer? – Michael Hampton Jul 03 '20 at 04:45
  • Didn't consider that, it is the only instance behind a load balancer. – Joe Miller Jul 03 '20 at 04:50
  • In that case consider that it's the load balancer connecting to your server, the malicious client is connecting to the load balancer! – Michael Hampton Jul 03 '20 at 04:54
  • The apache logs show the IP address of the server, not the load balancer. So that's what triggers Fail2Ban. How would you configure iptables on an EC2 instance behind an AWS load balancer? – Joe Miller Jul 03 '20 at 04:56
  • You don't, you have to either return a 403 or block them at the load balancer. Consider something like https://github.com/anthonymartin/aws-acl-fail2ban – Michael Hampton Jul 03 '20 at 04:57
  • Thanks, I'll try that out, and update this post. To be clear, using iptables does not work at all when the server is behind a load balancer? – Joe Miller Jul 03 '20 at 05:01
  • iptables is a firewall, and can only block things that are actually connecting to your server. – Michael Hampton Jul 03 '20 at 05:23
  • My two cents: in that case, I think iptables should run on the load balancer (if it is a linux box). In that case you could install fail2ban on the load balancer and give access to apache logs so it can work properly. You can give it access to logs by either: share log folder via NFS (easier, but a possible stability/security problem), or sending apache logs to the balancer via remote syslog. (trickier but cleaner) – Qippur Jul 03 '20 at 11:41
  • another option is to keep fail2ban on apache server and edit fail2ban scripts to run iptables commands on load balancer (also tricky) – Qippur Jul 03 '20 at 11:49

0 Answers0