Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: The argument for moving SSH off port 22 - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
The argument for moving SSH off port 22

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)

Rick

293 Posts
ISC Handler
Move the server to a nonstandard port and put a TCP tarpit on port 22.
John Hardin

62 Posts
"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.
Ken

40 Posts
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?
Ken
4 Posts
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.
Ken
3 Posts
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.
Mike7

43 Posts
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.
Mike7
2 Posts
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.
pktman

14 Posts
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.
Anonymous
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...
Peter Bance

9 Posts
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.
UnknownNick

11 Posts
I wouldn't consider it security through obscurity... Mainly because I wouldn't consider it a measure to make your SSH more secure. I'd call it, security through increasing your visibility into who is attacking your system. If you move off of port 22, anybody touching port 22 is up to no-good (outside of misconfigured clients). That's a handy piece of information right there. At the end of the day, what do you gain and what do you lose... In my opinion, it buys me more doing it than not, so I do it. But of course I don't rely on it for 'security'.
RyanG

2 Posts
Disable root login (as already suggested) and enable pam_tally2, if for no other reason than a quick way to get stats like this:

Login Failures Latest failure From
root 65534 01/06/15 09:32:39 173.
bin 366 01/05/15 15:24:22 116.
daemon 23 01/05/15 15:30:11 116.
adm 59 01/01/15 00:59:17 146.
lp 22 12/16/14 09:11:51 185.
sync 5 11/24/14 17:59:09 u12906.
shutdown 3 11/24/14 17:58:23 u12906.
halt 4 12/13/14 20:45:20 46.
mail 22 11/24/14 17:54:46 u12906.
uucp 79 12/27/14 12:36:21 200.
operator 42 01/05/15 15:38:21 116.
games 38 01/05/15 15:31:53 116.
gopher 13 01/05/15 15:40:50 116.
ftp 418 01/05/15 15:34:01 116.
rpcuser 9 11/24/14 17:57:53 u12906.
rpc 8 01/05/15 15:48:21 116.
ntp 3 12/04/14 07:07:52 ec2-54-93-184-85.
vcsa 3 11/24/14 17:59:56 u12906.
sshd 32 01/05/15 15:24:15 116.
nobody 70 12/27/14 12:38:26 200.
openvpn 6 11/08/14 13:29:13 162.
nfsnobody 9 12/13/14 08:39:02 46.
RyanG
1 Posts
I'm confused. Moving SSH (or any other service) off its normal port does absolutely nothing to reduce or stop the scanning noise in the logs. You're still going to get scanned whether the port is used or not. If you're deciding to simply ignore and not log drops, that's an entirely different matter.

If you are not using positive access controls in front of your limited-use service, you're on your way to committing career suicide. "Limited-use" means things like SSH that are used by a small subset of the world like your admins or employees. Source IP control or jump boxes are a great way to keep the noise out of the application logs.

If you're not using two-factor authentication, which can include a known source IP, you're either negligent or independently wealthy because you don't need that job you're about to lose. Ditto if you rely on just the native or built-in application controls for protection.

The question you should always ask yourself (and answer honestly) is this: "What bad things can happen if the controls I have in place fail?"

Things like "What happens if another admin "temporarily" changes the SSH config to allow root access and forgets to change it back ever?". If you have Tripwire or some other configuration monitoring tool to detect those changes, you've limited your exposure window. If you don't, you had better be using two-factor auth or source IP limiting. Or be independently wealthy.

This discussion is similar to whether it is a good thing to implement an HTTP to HTTPS redirect for HTTPS-only sites. My position has always been "no" unless it is a general use application like a public web site. Yet you see this on SSL VPN systems all the time. Way back when the vast majority of scanning hit TCP 80 and never TCP 443. Even if you had 443 open to the world you rarely saw non-legitimate traffic hit it. Not so much today. It's not 50/50 yet but it's definitely up there. The attackers and scanners are magnitudes of orders better tan they were five years ago.

Never expose services to the world that the world does not need access to. It's that whole "least privilege" thing.
Anonymous
Long ago I moved ssh to a non-standard port, it greatly reduced the noise but it still was attacked occasionally.
The solution was to install port knocking (I used fwknop). This way the ssh port was opened for a 30 second window
only after an authenticated "knock" on another port. Worked great.

Peter
Anonymous
I have been running SSH on an ephemeral port for at least eight years. When I first set up SSH on port 22, it was less than an hour before there were numerous brute force attacks and exploits being thrown at it. My decision to move SSH off its standard port wasn’t for security, but to keep my logs from growing like crazy. Since I have moved SSH to ephemeral port, I have not had any illicit attempts to access it.
Anonymous
Moving the port number officially makes no sense, because on most implimentations the port # can be changed, and many network admins do just that to a port # of there own choosing, SSH is the kind of thing that does not need to have a standard port # for it to work so the assignment in practical terms is network admin dependent anyway.

I think things are fine as they are, as admins can use the port used, and use access attempts to port 22 to there advantage for tarpitting or blacklisting, and most already do.
MAEDATA

4 Posts
Quoting Anonymous:it wont take long determined hacker to do a vertical scan on an IP to find ssh port.
Another reason to run a TCP tarpit on unused ports.
John Hardin

62 Posts
Quoting Anonymous:I'm confused. Moving SSH (or any other service) off its normal port does absolutely nothing to reduce or stop the scanning noise in the logs. You're still going to get scanned whether the port is used or not. If you're deciding to simply ignore and not log drops, that's an entirely different matter.



Might not be a big deal when dealing with 10-20 users running SSH. But in research institution dealing with thousands of legit SSH users from all sorts of locations and tens of thousands of illegitimate logins a day its a huge deal.

With SSH running on port 22, each scan/login attempt equals:
- Log Entry(s) from Cisco Firewall build/establish/teardown/etc
- Log Entry from SSH Server (auth logs)
- Log Entry from AAA/Radius Server
- Log Entry from Two Factor Auth Server

That is, at least, four log entries going into my Splunk server per failed login attempt. Am required to monitor and report on failed login attempts for remote access. Which means have to go through those logs to determine which were legit users, try to figure out which are real users having login issues, not to mention the scanners accidentally hitting on a legit account and locking user out. IP Block lists, dynamic banning, and tarpits did us no good as virtually all scans against SSH have been distributed. Its very rare (other than from a specific country) to see a full scan of all ports, we almost always see distributed scans for just well known ports.

With SSH running on port X while the world still scans for port 22. Port 22 scan equals:
- Log Entry from Cisco Firewall for traffic drop

That is a HUGE difference when it comes to log analysis and customer service for researchers/students. Instead of seeing ten thousand or more login attempts hitting Radius/2Factor auth servers each day only see a couple of thousand. Because in general the scanners aren't scanning the port our SSH server is on. Everything is still monitored, but makes it much easier to write alerting rules and makes it much easier for cyber defenders to respond when rule is triggered.

Makes a huge difference in log analysis and ability to support end users. User's accounts don't get locked out as often by scanners, easier for helpdesk to pro-actively identify users with login issues, easier to identify the targeted attacks from people who know where our SSH server is. Its a huge win.
pktman

14 Posts
Wow, I guess you all luck out to not have to read my previous 'dissertation' on the ports issue for SSH. My web session timed out.

More briefly,

If you have the facility to deviate from the norm, you should, IF you can administratively maintain that change. Shooting for an industry wide change is no good, any newly preferred default will then become the new target.

We can, as more knowledgeable admins than the average Joe, help reduce our OWN security exposure by using alternatives, as mentioned. However how many of us are there, and how does this impact the 'world at large'? It'd be nice to hear that 70% of the world population has isc.sans.edu set as their homepage on their web browsers. Sans can attest that this is not the case. Percentage-wise, we're such a very small number, it'd not impact much of anything. Even if you could miraculously change 70% of the world, the remaining 30% is reason enough for alarm.

That said, protect YOURSELF, as much as you can reasonably handle. Run alternative ports. The majority of course, will continue to run whatever the default installation package selects, accounting for 99.999% of world.

Its going to take an entirely different approach to REALLY make a difference in security, at large--port base firewalling isn't going to help the big picture, whether publicly or behind the corporate lines. But, since we're at least diligent enough to read ISC, at least we can better ourselves and not become common fodder. Sounds selfish? Yep, but its reality. When the rest of the world also feels its as important as you do, they'll fix what they can as well. Setup your ACLs and deny lists. Keep them well documented, and don't hoard your security configuration information.
spooledone

7 Posts
> One interesting comment is that security by obscurity is not a security measure

This is a pet peeve[1] of mine.

"Security [through|by] obscurity" is not a good security plan, but it is an effective tool. When I visit the bank, I don't walk around with a big stack of cash in my hand. I tuck it away where it is out of sight. I *obscure* the fact that I am carrying a lot of money. If I can avoid an attack, my other security measures[2] won't be tested.

The same concept applies to systems.

Dan

[1] Not that I am in the habit of making pets of peeves. Like wild animals, it is best to release peeves as soon you are able.

[2] Such as crying like a little girl.

[3] HTH, HAND.
ComputerX

6 Posts

Sign Up for Free or Log In to start participating in the conversation!