Ramblings of a security fanatic: SSH

It is not uncommon to be physically separated from a computer you wish to access. Whether you wish to quickly grab a file from your home computer, or you wish to access a honeypot system from the other side of a city to check logs, SSH is the most readily available solution. But in a security conscious field such as this, the inherent risks are enough to make one a little paranoid about punching a hole in their firewall for the service. To mitigate the risks, I've compiled a list of security techniques ranging from the simple to the complex, and the trivial to the iron-wall-secure.

In this post, I'll assume a UNIX based OS is being used on the host computer. There are many reasons for this, often debated religiously, but I suggest this choice largely because most UNIX based OS's have more flexibility in configuration. In a honeypot setup, I believe an optimal configuration would be a windows environment virtualized within a secure UNIX system. This would allow for a quick backup/restore of the entire windows system once the forensic analysis of a specific attack was completed. Sort of a digital etch-a-sketch or dry erase board.

And without further (uncalled for) rambling, here is the security checklist I've compiled:

1) Change SSH service from port 22
This is often the first security plan recommended when the topic of SSH security is discussed, primarily because of its simplicity. Most web-based SSH attacks are automated, and often target any services running on port 22. Many people argue that this ‘security through obscurity’ model is a bad idea, but they don’t realize the number of automated attacks that are rendered useless by this simple change. The numbers speak for themselves. Changing your SSH service outside of the lower end of 1024 ports will reduce the number of failed login attempts from hundreds or more a day to a handful (if not zero).

2) Move authentication to protocol 2
Many people argue SSH authentication protocol 1 is no more or less secure than protocol 2. I have personally had my computer breached simply because I did not specify which protocol to use, and the log files I studied in the aftermath suggested the script that compromised my system walked right through the authentication as if it weren’t even there. Protocol 1 is effectively useless against the well-informed attacker.

3) Prevent brute-force attacks
Using a script such as Deny-Host, PAM, or Fail2ban, you can (temporarily or permanently) block the IP address of anyone found making repeated failed login attempts. These scripts, added with an hourly cron task, and maybe a few custom bash scripts add all the flexibility you could imagine in making IP banning rules.

4) RSA key login
This is a security measure I have been contemplating for some time. On one hand, a password system is prone to the human element. People often choose weak passwords and even make the decision to write them down, or even share them with others. On the other hand, (if I understand the system as well as I believe I do) an RSA key system is vulnerable in that if any of the client computers (containing the private keys to access the SSH service) are compromised, than your SSH service is effectively compromised as well. An interesting solution is to use the best features of both worlds. While you can’t use both the key and password authentications at the same time with most openSSH software (you can force it to work with a few quick hacks before you compile the openSSH software, but apparently it has security risks and stability issues of its own) there is a better way to get the advantages of both methods. I haven’t tested this one personally, so bear with me if I miss a detail or two, but you can generate an RSA key that is encrypted with a password. Now your private key is no longer critically private. When you go to log in to the SSH service, the client asks for the pass phrase to decrypt the RSA key before sending it off. I’m guessing this is a simple XOR between the pass phrase and the encrypted private key, but XOR is a surprisingly effective encryption technique on something as unpredictable as an RSA key signature when combined with a moderately secure pass phrase. If the client’s system was compromised, there is still a chance of SSH compromise, but it is mitigated. The encrypted key can be bruteforced with an array of attempted pass phrases, (and this is the part I’m really not sure of) or the private key can be picked up when a user logs in to the SSH client since the private key becomes decrypted with the pass phrase before being used in authentication with the SSH server.

5) Localize SSH service
What reason do we really have to allow anyone across the globe log into our system? Often we know exactly who should be allowed in, and more often than not they are in the same few locations when they access the server. Using iptables (and/or tcp wrappers, so I hear) you can restrict access to most of the world. With a bit of research (and this is what I feel particularly clever for finding out) you can find the IP ranges possible for a specific community. It might be difficult in a large city, but where I am, there are only 2 ISPs. Using a little tool I found here: http://www.senderbase.org/senderbase_queries/detail_lookup and a bit of number mapping, I was able to figure out that just about every computer in my city (and a few small surrounding communities) were within two /16 subnets and one /18 subnet. There may be more, and in the case I find myself locked out I’ll have to do an IP lookup, map a new range, and add that to the ‘allow’ rules on the server when I get the chance.

6) Disable root login
This one is very straight forward. We don’t want people using the almighty root account any more than possible, let alone log into it remotely. Also, ‘root’ is a user on just about any UNIX system. An attacker has to log into a valid account. Don’t make it easy for them by giving them access to a username that is so obvious. For this same reasoning, ‘guest’ logins (or any variation of) is a bad idea as well.

7) Tighten login access even more
In the SSH configuration, there are options such as ‘max startups’ and ‘login grace time’ that are set unreasonably high. Do you really expect 8 people to be logging in within the same minute? Do you really need to give them up to 2 minutes to type in their password? Tweaking these numbers a little bit may seem trivial, and they very well could be. But its easy, so its probably worth the time.

8) Disable TCP port forwarding
I really haven’t done much research on this one yet, but the topic came up several times in my reading so I’ll include it here. I’ll post more details on it when I know.

9) Add log analysis tools
This may not be so relevant to those running honeypots, but rarely does your average person check logs. There could be all sorts of suspicious stuff coming in, and who’s really going to check it regularly? There are many log processing tools ranging from simple to complex. Having something to check all your logs for you and actively tell you when something suspicious is going on is much more reliable than promising yourself you will check them regularly. Log checking is like a new year’s resolution. Everyone starts ambitious, but by the second week of January, nobody cares anymore.

10) Port Knocking
Last but not least, my favourite (although regrettably untried) technique. Why have an opening in your firewall at all when you can seal it entirely and have your computer wait for a sort of ‘secret handshake’ before it opens the port for you. A simple script could have your SSH server running on port 2100 with a closed firewall to that port. When your logfiles show someone using the secret knock (for example, ping port 2200, 2205, 2203, 2207 in that order within 60 seconds) then your system will open the port just long enough to make the SSH connection before closing. Again, this system can get as complex and feature-rich as you wish. This scheme can be put together with nothing more than a few scheduled chron tasks and a bash script or two. From there, the sky is the limit. I really want to see this work for myself someday. I’ll get around to it eventually.

Whew! That was a long list. Hopefully you found something new or interesting out of it. Any combination of these techniques can be used, but for the dedicated and paranoid SSH user, ‘all of them’ is the option of choice.

I wouldn’t consider myself an expert on the topic, and any feedback, corrections, or additions anyone can think of are more than welcome.