Difference between revisions of "Secure SSH against brute force attacks"

From Amahi Wiki
Jump to: navigation, search
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
With more and more people installing Amahi we have more and more Amahi's exposed to the internet when people start opening up ports in their routers to be able to access their servers remotely. Since SSH is used by many this is often also exposed outwards. This opens up for SSH brute force attacks (which can be both fast and effective).
 
With more and more people installing Amahi we have more and more Amahi's exposed to the internet when people start opening up ports in their routers to be able to access their servers remotely. Since SSH is used by many this is often also exposed outwards. This opens up for SSH brute force attacks (which can be both fast and effective).
To bring some kind of default protection to the platform against this I purpose that we include the following iptable rules by default
 
  
 
  [root@dahome ~]# iptables --list
 
  [root@dahome ~]# iptables --list
Line 13: Line 12:
 
   target    prot opt source              destination
 
   target    prot opt source              destination
  
This will allow a couple of failed SSH login attempts and then add a 60 second cool down. Effectively killing any interest in brute forcing the server in question.
+
There are many more or less elaborate ways of doing this, but these three simple rules add good basic protection. This will allow a couple of failed SSH login attempts and then add a 60 second cool down. Effectively killing any interest in brute forcing the server in question.
 +
To add these rules run the following as root
 +
 
 +
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
 +
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
 +
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
 +
 
 +
Rules created with the iptables command are stored in memory. If the system is restarted before saving the iptables rule set, all rules are lost. For netfilter rules to persist through a system reboot, they need to be saved. To save netfilter rules, type the following command as root
 +
 
 +
iptables-save > /etc/sysconfig/iptables
 +
<b>NOTE:</b> This actually doesn't work for F19. They have changed things. So you will lose the settings on reboot and have to manually enter them again. Will update once I found the correct way for F19.
 +
 
 +
What you can do for now is to create a simple script that executes the following on start up to restore the rules saved above
 +
 
 +
iptables-restore < /etc/sysconfig/ipdtables
 +
 
 +
 
 +
= Disable root ssh access =
 +
 
 
Another tip is to disable root ssh access if you don't really need it since that is one of the most common user names used when brute forcing.
 
Another tip is to disable root ssh access if you don't really need it since that is one of the most common user names used when brute forcing.
  

Latest revision as of 06:09, 30 August 2013

With more and more people installing Amahi we have more and more Amahi's exposed to the internet when people start opening up ports in their routers to be able to access their servers remotely. Since SSH is used by many this is often also exposed outwards. This opens up for SSH brute force attacks (which can be both fast and effective).

[root@dahome ~]# iptables --list
Chain INPUT (policy ACCEPT)
 target     prot opt source               destination
 ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh state NEW recent: SET name: SSH side: source mask: 255.255.255.255
 LOG        tcp  --  anywhere             anywhere             tcp dpt:ssh recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: SSH side: source mask: 255.255.255.255 LOG level  warning prefix "SSH_brute_force " 
 DROP       tcp  --  anywhere             anywhere             tcp dpt:ssh recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: SSH side: source mask: 255.255.255.255
Chain FORWARD (policy ACCEPT)
 target     prot opt source               destination
Chain OUTPUT (policy ACCEPT)
 target     prot opt source               destination

There are many more or less elaborate ways of doing this, but these three simple rules add good basic protection. This will allow a couple of failed SSH login attempts and then add a 60 second cool down. Effectively killing any interest in brute forcing the server in question. To add these rules run the following as root

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Rules created with the iptables command are stored in memory. If the system is restarted before saving the iptables rule set, all rules are lost. For netfilter rules to persist through a system reboot, they need to be saved. To save netfilter rules, type the following command as root

iptables-save > /etc/sysconfig/iptables

NOTE: This actually doesn't work for F19. They have changed things. So you will lose the settings on reboot and have to manually enter them again. Will update once I found the correct way for F19.

What you can do for now is to create a simple script that executes the following on start up to restore the rules saved above

iptables-restore < /etc/sysconfig/ipdtables


Disable root ssh access

Another tip is to disable root ssh access if you don't really need it since that is one of the most common user names used when brute forcing.

Alternative Ports

Another technique that can help reduce the automatic probes of the SSH port (port 22), is to use some alternative port. For instance, you could choose a port, say port 9988, and forward that (TCP) port from the outside of your router to your HDA's port 22. To connect to your HDA (in this example myhda.yourhda.com) from outside, you could then do:

   ssh -p 9988 myhda.yourhda.com

If this gets old, you can avoid the -p in the client configuration. In Linux/Mac OS X systems, this can be done with the .ssh/config file, by adding:

   Host myhda.yourhda.com
           Port 9988

and you will not need to type the -p in ssh or other programs that use ssh, like rsync, when accessing your host.

Other Techniques

Other techniques, in some case more advanced, include: