Difference between revisions of "Secure SSH against brute force attacks"
(Created page with "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...") |
|||
| (7 intermediate revisions by 3 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). | ||
| − | |||
[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. | ||
| + | |||
| + | = 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: | ||
| + | |||
| + | * [http://www.linuxjournal.com/article/8957 Dual-factor authentication] | ||
| + | * [https://www.linux.com/learn/tutorials/351079-weekend-project-secure-your-system-with-port-knocking Port knocking] | ||
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:
