Are there additional ways to protect SSH connections besides firewall and RSA Keys?

Question

Sometimes I don't have a static IP and need to administrate my web server remotely. I'm looking for any additional layers of protection I could add to make opening port 22 safer.

Currently I have disabled root password login via SSH. It requires RSA key to login (the private key is stored on a usb smart card).

Are there any known risks with my configuration if port 22 was opened to the public? Besides port 22, iptables only has port 80 and port 443 open to the public.

I'm using a Windows computer to connect to Centos 6 Linux with Putty.

Are there any additional statements I can add to the firewall or SSH config to further limit access to port 22 to only my specific computer so that the port doesn't appear open to people scanning ports? I'm using iptables for the firewall currently.

Answer 1

Your existing configuration seems very secure. However, there are additional things you can use to restrict access.

Port knocking can be used to keep the port closes most of the time. This is implemented using iptables. There are daemons which can be used, or the rules can be implemented entirely in iptables as described in the Shorewall documentation.

If tcp wrappers is enabled. A couple of ruless like the following in /etc/hosts.allow will notify you whenever a remote connection is made to the deamon. The first rule lets local connections work silently, adjust the ip address range as appropriate. The second rule prevents access from addresses which reverse to a number of country TLD, and emails a message for each successful connection. It could be noisy, if you don't use Port Knocking.

sshd :          10.0.0.0/8 192.168.0.0/24 

sshd :          ALL \
            EXCEPT .ar .au .br .by .cl .co .cz .do .eg .gt \
                .id .il .in .jp .ma .mx .nl .pe .pk .pl .pt \
                .ro .rs .ru .sa .sg .tr .tw .ua .vn .za \
                .ae .at .bg .gh .hr .hu .ke .kz .lt .md \
                .my .no .sk .uy .ve : \
            spawn (/bin/echo "SSH connection to %N from %n[%a] allowed" | \
                /usr/bin/mailx -s "SSH Allowed" [email protected])

fail2ban rules can be used to temporarily blacklist hosts which are trying to brute force your server. I've seen occasional attempts when I have had ssh exposed to the Internet.

Answer 2

As others have said, SSH is already up to the task in terms of being secure enough. I think it's pointless to move the sshd daemon to a different point. I liken this to setting up a Wirelss access point and hiding the SSID. It's trivial to by pass these types of security through obscurity measures.

Limiting access not just to root, but to only key users is always a good idea, whether it's with SSH access or anything else for that matter.

One thing that I find helpful though is making use of something like fail2ban. You can use it to detect and take countermeasures to slow down and thwart would-be attackers.

• http://www.fail2ban.org/wiki/index.php/Main_Page

Answer 3

Your SSH installation is already the state-of-the-art in term of security.

There is something you could do but note that it may be more a pain in the neck for you than a real protection. You could change the port from 22 to a less known one in order to receive less attacks and authentication probes.

Answer 4

en.wikipedia.org: Systrace

OpenBsd man page

OpenBsd have such trick, you can launch OpenSsh with limited permissions and additional logging.

Try to wrap /usr/sbin/sshd with /usr/sbin/systrace.

Each access to any system object would be logged by systrace, any access to any file, directory, network ports, memory, system calls, etc.

Generate policy this way:

systrace -A -d /etc/systrace/sshd.policy/ \
         -E /var/log/systrace_sshd.log /usr/sbin/sshd

Edit policy with your favorite text editor:

vi /etc/systrace/sshd.policy/

Thereafter, launch sshd daemon with restrictions:

systrace -a -d /etc/systrace/sshd.policy/ \
         -E /var/log/systrace_sshd.log /usr/sbin/sshd

There are many how-tos about systrace wrapper over shell, but you should wrap sshd, if you are interesting in secure of daemon.

Answer 5

The only risk on the server side is a pre-authentication exploit. There haven't been many (publicly known) in the history of SSH.

Answer 6

I use a tar trap in iptables. Too many failed login attempts and you have to go to the physical machine.

10 times in 15 minutes and you're blacklisted.
9 times in 10 minutes and you're blacklisted.
6 times in 5 minutes and you're blacklisted.

Adjust Accordingly!

#
# - Black List
#
-A BLACKLIST -m recent --name blacklist --set
-A BLACKLIST -j LOG --log-level 4 --log-prefix "TAR-TRAP: "
-A BLACKLIST -j DROP
#
# - SSH Tar Trap
#
-A FIREWALL -p tcp --dport ssh -m state --state NEW -j TAR-TRAP
#
-A TAR-TRAP -m recent --update --name blacklist --seconds 900 --hitcount 1 -j LOG --log-level 4 --log-prefix "BANNED: "
-A TAR-TRAP -m recent --update --name blacklist --seconds 900 --hitcount 1 -j DROP
-A TAR-TRAP -m recent --set --name strike1
-A TAR-TRAP -m recent --set --name strike2
-A TAR-TRAP -m recent --set --name strike3
-A TAR-TRAP -m recent --update --name strike1 --seconds 300 --hitcount 6 -j LOG --log-level 4 --log-prefix "IPT TAR1: "
-A TAR-TRAP -m recent --update --name strike1 --seconds 300 --hitcount 6 -j BLACKLIST
-A TAR-TRAP -m recent --update --name strike2 --seconds 600 --hitcount 9 -j LOG --log-level 4 --log-prefix "IPT TAR2: "
-A TAR-TRAP -m recent --update --name strike2 --seconds 600 --hitcount 9 -j BLACKLIST
-A TAR-TRAP -m recent --update --name strike3 --seconds 900 --hitcount 10 -j LOG --log-level 4 --log-prefix "IPT TAR3: "
-A TAR-TRAP -m recent --update --name strike3 --seconds 900 --hitcount 10 -j BLACKLIST
-A TAR-TRAP -j ACCEPT
#

Answer 7

You can make a rule like this to block ssh connection from certain source IP addresses. The IP range could be public or private.

$ iptables -A INPUT -p tcp -s IP_Range --dport 22 -j ACCEPT

As an example, you can use this one for your private network

$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 22 -j ACCEPT

You can also use tcpwrappers to control ssh access on your centos. TCPwrappers use a combination to /etc/hosts.allow and /etc/hosts.deny files. The following example below shows to set access control which allow to access to sshd from 10.0.0.0/24.

$ vim /etc/hosts.deny
sshd: ALL
$ vim /etc/hosts.allow
sshd: 10.0.0.

You can also make ssh daemon to listen to a different port other than 22.