The argument for moving SSH off port 22

Published: 2015-01-05
Last Updated: 2015-01-06 00:08:22 UTC
by Rick Wanner (Version: 1)
21 comment(s)

An interesting discussion is occurring on reddit on whether Secure Shell (SSH) should be deployed on a port other than 22 to reduce the likelihood of being compromised.  One interesting comment is that security by obscurity is not a security measure, but a way to delay the attacker, so it provides little value.  While it is true that it is difficult to stop a determined attacker who is targetting you, any measure that stops the random script kiddies and scanners from poking at your SSH is not completely useless.

The truth is that I have been deploying SSH on non-standard ports (typically 52222) for more than 15 years on the Internet facing servers I manage.   Of course this is not the only security measure I employ.  I patch daily; use hosts.allow where practical, keys and passphrases instead of passwords, and deploy DenyHosts.  Do I deploy on a non-standard port because of the security advantages to be had by security by obscurity?  Not at all!  I deploy SSH on a non-standard port because it eliminates all the noise that is every present on port 22.  The continual scanning and attempted brute forcing of SSH that has been on the Internet since the beginning of time, and seems to get worse every year, generates a lot of noise in the logs and is at best a nuisance and at worst service affecting for the server.  Why put up with it if you don’t have to?

It decreases the volume so much that I often have to test my defenses to be sure they are working. Sometimes I even deploy a honeypot on port 22 to see what the bad guys are up to. (-;

Opinions?

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu- http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

Keywords:
21 comment(s)

Comments

Move the server to a nonstandard port and put a TCP tarpit on port 22.
"PermitRootLogin no" in sshd_config is the single, best thing one can do to secure ssh on an internet-facing system and should ALWAYS be done. Running something like fail2ban and configuring sshd to run on something other than tcp/22 are close behind.
I always use non-standard ports for control services facing the Internet. Years ago there was a major issue with VNC, but the fact I ran it on a non-standard port meant I had no issues while a patch was produced.

Also, I like to look at it similar to the locks on your automobile: a determined person will easily smash a window, but does that mean it is useless to lock the door?
I started running SSH on standard-but-mismatched ports (eg. 80, 443) after one event when I found myself stuck in a hotel that decided to block 22/tcp outbound.
Agree, there is just too much noise from the scanning.


The firewall we use allows us to white-list the source by FQDN. This helps.
If also allows white-listing by country; which is also useful as we are not in large country such as US.
A side from the obvious deviating from the company firewall policy in addition to port 22 you start having 3322, 4422 and so on. It probably would create more confusion. If firewall allows an SSH or 22 or a custom 4322 it wont take long determined hacker to do a vertical scan on an IP to find ssh port. I would say if you are relatively small it's worth, if you are big and trying to use automation in a long run it's not worth the effort.
I love running SSH and remote VPN tunnels on non-standard ports. Is it security by obscurity.......no. Its a simple matter of conservation of effort and resources.

I once explained it this way in a presentation. You can either stand in the middle of the street and then have to dodge every single car that speeds by or you could stand on the sidewalk and watch the cars speed by. Could still get hit while standing on sidewalk but on a day to day basis its much fewer cars to dodge. So if you had the choice, why would you choose to stand in the middle of the street instead of on the sidewalk?

In one month I get between 50,000-60,000 scan/intrusion attempts on port 22. Normally that will fill up my logs with login attempts for admin, root, admin, allen, alan, allan, amy, april, etc...etc...etc... as the hackers go through every account name known to man with every password known to man. Makes it difficult to analyze logs and determine which are bad logins from legit users and which are brute force attacks. I wrote a script and database to analyze what IP's my legit users were coming from and try to filter out stuff from crap scripts but still took effort to dig through daily logs.

Moving the port to simply something else cleans up my logs and in turn makes me more aware of what is going on. I am now looking at logs that are 1/1000 the size. Can concentrate more on identifying users having problems and less time digging through all the chaff.

I still see all the scripts scanning through port 22, but those are being blocked by firewall now and are less of a concern. I just concentrate on what is actually hitting the SSH servers on the relocated ports. Reduction in complexity/noise in logs gives better awareness and understanding and leads to better over all security. Making a simple change to reduce the load on the analysts is a no brainer. Every year I always have to defend the use of non-standard ports. Because there is always someone who comes a long who likes to play in the traffic.
I agree with the tarpit. I use IP tables to do it on whatever port I chose to put SSH on. I've found that it doesn't seem to matter where you put SSH a determined person always finds it through a scan. So my setup is the following, I don't remember where I came across the iptables config years ago, it may have been here.

in sshd_config:

For my purposes only 4 people need access to the server so an explcit "AllowUsers user1,user2,user3,user4" works well for me, if this doesnt work for you then as another mentioned at least "PermitRootLogin no" .. I use both.

Then make use of "MaxAuthTries X" 3 is a good number, that allows you to mess up your legitimate password once or twice but makes sure that brute-forcers are disconnected on the 3rd fail.

Now here's the fun. To make it extremely painful for a brute force, and I've fallen victim to it myself, add the following rules to iptables so that you can only connect once every X seconds, I have mine set to 10 minutes. So, you essentially get 3 password tries every 10 minutes. And if you have a strict allowusers / no root login all of the user names I've ever seen tried (root,admin,daemon,etc...) will never get in anyway.

-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 600 --name DEFAULT --rsource -j DROP
-A INPUT -p tcp -m state --state NEW -m recent --set --name DEFAULT --rsource -m tcp --dport 22 -j ACCEPT

Take it a few steps further:
* Configure fail2ban as someone else already mentioned to catch persistent brute-forcers and drop their traffic.
* Enable 2 factor auth.. You can use Google auth PAM modules, or even something like ssh key + password combo.

With this config I wouldn't say it's 100% secure as we all know nothing is, but its probably a target the general bot / script kiddie wont wast their time on.
Definitely a good plan (and I like the traffic analogy!), and I wish I could. Trouble is, it was painful enough getting hosting customers to move from FTP to SFTP, I can't imagine teaching them to configure their clients to use a non-default port as well! In fact, some of their software might not even support it :-(

So, Fail2Ban and GeoIP-based blocks on the firewall quell most of the noise, but there's been quite an uptick recently in sources from countries I can't block. Lots of noise, but at least the average SSH username dictionary is lame...
Moving it off the standard port is nice for cleaning up the logs, but nobody has mentioned the most important thing to do ...

# Disable password access.
PasswordAuthentication no

It's not like certificates with all the unnecessary bureaucracy of CAs and password timeouts. SSH keys are very very simple to use and make brute forcing useless.

Diary Archives