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

From Amahi Wiki
Jump to: navigation, search
Line 22: Line 22:
  
 
  iptables-save > /etc/sysconfig/iptables
 
  iptables-save > /etc/sysconfig/iptables
- NOTE... This actually doesn't work for F19. They have changed things. So you will loos the settings on reboot and have to manually enter them again. Will udpate once I found the correct way for F19.
+
<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.
  
 
= Disable root ssh access =
 
= Disable root ssh access =

Revision as of 21:32, 29 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.

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: