0

I have the following lines at the very top of iptables, these are used to prevent SSH brute force attacks and DDOS attacks: iptables segment to prevent SSH brute force attacks and DDOS attacks

What bothers me here is "name: DEFAULT" in all three, I am just wondering whether they will all work or one will overwrite another? Any idea how to test it?

Also, I am using Nginx as a reverse proxy for Apache, am I correct using here ports 80 and 443 (i.e. the ones that Nginx is running on) or should I use Apache ports 7080 and 7081 in iptables?

This is running on VPS with Plesk Onyx and Ubuntu 14.04.

Thanks for your help!


Here are the commands that I used to add these lines to iptables:

iptables -I INPUT -p tcp --dport 80 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 5 --hitcount 20 -j DROP
iptables -I INPUT -p tcp --dport 443 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 443 -m state --state NEW -m recent --update --seconds 5 --hitcount 20 -j DROP
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent  --update --seconds 60 --hitcount 5 -j DROP 
Mike S
  • 1
  • 1
  • 2

3 Answers3

1

The easiest way to achieve this is by installing fail2ban. It will monitor SSH per default, and dynamically bans IPs that fail to often. You can configure it to monitor any log file, however. So you can include HTTP and HTTPS as well.

mzhaase
  • 3,778
  • 2
  • 19
  • 32
  • 1
    Thanks for you suggestion @mzhaase. I have fail2ban running, but I prefer using iptables solution for this purpose as it seems more efficient than scanning logs with fail2ban. – Mike S May 02 '17 at 12:39
  • nope in the end it is the same – djdomi Sep 20 '19 at 15:49
0

Re: "What bothers me here is "name: DEFAULT" in all three, I am just wondering whether they will all work or one will overwrite another?" Adding "--name UNIQUE-NAME" resolves this problem (if it is a problem). Here are updated directives:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set --name SSH
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent  --update --seconds 60 --hitcount 5 --name SSH -j DROP
iptables -I INPUT -p tcp --dport 80 -m state --state NEW -m recent --set --name DDOS-HHTP
iptables -I INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 5 --hitcount 20 --name DDOS-HHTP -j DROP
iptables -I INPUT -p tcp --dport 443 -m state --state NEW -m recent --set --name DDOS-HHTPS
iptables -I INPUT -p tcp --dport 443 -m state --state NEW -m recent --update --seconds 5 --hitcount 20 --name DDOS-HHTPS -j DROP
Mike S
  • 1
  • 1
  • 2
-1

Something like

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m sshbrute --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m sshbrute --update --seconds 60 --hitcount 4 -j DROP

May work for you. All ssh connections (or port 22 connections rather) get tagged as "sshbrute", second command drops any new ssh connection if there are more than 4 new connections in one minute from a particular IP. Don't mess up on your password, or if you do, do it slowly.

ivanivan
  • 1,448
  • 6
  • 6
  • " -m sshbrute" results in error: "iptables v1.4.21: Couldn't load match `sshbrute':No such file or directory" – Mike S May 02 '17 at 13:42
  • 2
    `-m xxx` does not tag packets but actually loads the iptables 'xxx' module. I've not found such 'sshbrute' module, hence the error. I have a similar setup, using `-m recent`. BTW, not sure the `-i eth0` provides any additional benefit (I'd actually forget it while pasting rules from system to system and actually filter on the wrong interface ;-) – Httqm May 23 '19 at 07:03