
Obscurity: Does Changing Your SSH Port Lower Your Risk? - danielrm26
http://danielmiessler.com/blog/security-and-obscurity-does-changing-your-ssh-port-lower-your-risk
======
petercooper
Even if it didn't, it lowers the number of log entries, failed attempts, and
number of connections by several orders of magnitude. I've never regretted
doing it though I pick a far more obscure port than this. None of my clients
have had issues with me doing this either and sshagent makes it transparent to
me.

It's the equivalent of moving your main door to the back of your house. Far
fewer people will knock, even though burglars can still get in.

~~~
notyourwork
Glad you mentioned choosing a obscure port. Not that 24 is wrong though <1024
are reserved for various protocols so usually I tend to select ports above
this reserved range. Never know when you decide to roll out say mail on 25 and
sure enough find out your ssh port is running on 25.

~~~
LordLandon
If you're running a multi-user server, with possibly malicious users, that's
not a good idea. Ports <1024 can only be bound to by root; so if a valid user
of the server can figure out how to crash sshd, he can run his own version on
the same port >1024, and then all your users' password are belong to him.

~~~
petercooper
When I read your comment, I thought "surely you couldn't rig up a fake sshd to
steal passwords" thinking the protocol wouldn't send passwords in plaintext
but instead some hashing would take place. I read the RFC and, wow, it does
send plaintext (though it's over an encrypted transport). Ouch..

~~~
ryanpetrich
Any client that has the server's public key in their known_hosts will throw up
a big fat error.

------
mseebach
Not being on port 22 raises the bar for getting into your server slightly, but
as both the article and others here point out, you still get connections.

That means:

\- If you have a guessable user name / password, you will still get hacked,
and probably also by more determined people - which leads to:

\- Those determined to get into _your_ server will be delayed a few _seconds_
, at most.

It's fine, do it, but only to get the bulk of the automated attacks out of
your firewall / logs. If you're uncomfortable running SSH on port 22, your
setup isn't safe enough, and switching ports is just putting a band-aid on an
infected wound.

Hints:

\- Root can't login from SSH. Use sudo.

\- Public key only.

\- If you have multiple servers, only one can accept SSH connections from the
world. Preferably not in the same IP-subnet, much less domain, as any public
facing server. Use this as gateway to other servers.

\- IP whitelist, if practical.

~~~
goldmab
If you can log in as account xyz over SSH, and account xyz has permission to
do anything with sudo, how is that more secure than letting root log in over
SSH?

~~~
KaeseEs
If root can log in, the username is definitely known to the attacker and they
must figure out the password. If root can't log in, the username of someone
with an entry in sudoers probably isn't known to the attacker, so they must
figure out both the username and password.

~~~
goldmab
I do like this answer, but I'll also point out that making someone guess two
strings is just as secure as making them guess one long string. If root has a
random 10-char password, that's roughly the same number of guesses as a user's
first name with an 8-char password.

~~~
Peaker
Unless they can read the shadow file somehow, or a specific user attack vector
makes it somewhat easier than complete guessing...

------
jefe78
I've always moved my server ports to the 10,000+ range. The number of
connections is trivial.

In conjunction with the following, I've had virtually no issues:

Port 22222 #Easy to remember, rarely hit. Even if it does get hit, it takes
them a little longer to scan up to this range. Move it higher if you want.

Protocol 2 #NO EXCEPTIONS!

LoginGraceTime: 60 #seconds. If you need more than 60 seconds, you're probably
doing it wrong. Change to 30 if your host is fast.

PermitRootLogin No #self explanatory. No means no.

AllowUsers jefe78 otherguy #this should help if you use obscure user names

Now, combine that with denyhosts <http://centoshelp.org/security/denyhosts/>
and some really strict configs and you should be better off than you were.

------
TheCondor
My advice, and I've been doing security for about 10 years now, run SSH on the
normal SSH ports. Keep it patched. Install a good password policy. Centralize
your accounts in an LDAP database. And then, perhaps restrict the SSH access
to the few accounts or users that really need it. Perhaps you could use a jump
host..

The obscurity approach doesn't actually increase security, it does increase
the difficulty to use and diagnose things (it's just another step to remember
and your network is just a little bit different form everybody else') and it
might give you some artificial sense of being more secure. Plus there are off
the shelf tools that can monitor and even dynamically repair those attacks on
the fly (IPS products) and when you start using different ports those tools
don't all work the same way and some won't work at all, in that case the
obscurity would actually reduce your security and reduce the effectiveness of
other tools you use for security.

~~~
danielrm26
The military disagrees, that's why they paint their tanks to match their
surroundings.

If you're saying that you could get confused and the hassle is worth more than
the gain, that's one thing, but to say that there's no benefit is false.

~~~
artmageddon
Quite honestly at worst you'll just keep out clueless script kiddies, but a
determined person can _still_ find your SSH port. It's also worth noting that
your server isn't going to launch a 105mm depleted-uranium tank shell in the
face of some unscrupulous port-scanner :)

~~~
njharman
Number of clueless script kiddies far, far, far outweigh number of determined
people after my particular server.

Reducing risk of actual threats == security.

Dogma, let it go.

~~~
artmageddon
Fair enough regarding making the port harder to find, but I hope it's not your
only countermeasure.

------
relix
This is a failed study.

He should have removed "Port 22" from the config file to get any significant
results. Right now it only says that if an attacker gets an SSH-like answer on
port 22, it's very unlikely he'll try on port 24 as well.

This is unhelpful because if there's a bug in OpenSSH, then even an OpenSSH
"reject all on port 22" configuration* might be compromised.

I think it's very much more likely that an attacker, when not getting any
answer (or being instantly rejected) on port 22, will portscan the server to
see if any other ports are open, and _then_ try the non-standard port, which
in this case is 24.

* I'm unsure if this is possible in SSH (like reject all root logins), but anything non-standard might trigger the "no SSH @ 22" response, so I'm hypothesizing a best-case-scenario config.

~~~
danielrm26
You're assuming a human attacker, which is not the case for the vast majority
of probes and attacks. Bad guys don't generally sit there with a port scanner
going from IP to IP.

This is all scripted stuff we're talking about.

~~~
teaspoon
Scripts can't implement conditional behavior?

~~~
danielrm26
It's not a matter of "can't"; it's a matter of "don't". My understanding is
that scripts check a few places and move on. They're not AI-scripted human
replacements that start scanning the entire Internet on all ports once they
get an RST or a drop on 22.

------
ElliotH
This is generally well regarded security advice. Its what #ubuntu-server tends
to recommend to people if they come in saying their SSH port is being
attacked. Simply changing the port greatly reduces the number of attacks, and
combined with IP blocking (automatic with fail2ban or similar) you are
completely protected from these simplistic automated attacks.

~~~
measure2xcut1x
Maybe I'm stating the obvious, but in my experience an obscure port number
will limit the number of requests, AND you should have a hard firewall in
front of it with IP blocking | filtering.

~~~
antihero
What advantage does having a hard firewall give you over using iptables?

~~~
measure2xcut1x
Less load on the server, plus probably fewer vulnerabilies and simpler admin
on the firewall device. I suppose your mileage will vary.

------
bradleyland
We changed our SSH port if only for the fact that fail2ban was showing up near
the top of the list for CPU time while SSH was running on port 22. After
moving SSH to another port, it's consistently at the bottom.

------
stcredzero
Seems like all security tools are double edged swords. Lots of folks react
against security-by-obscurity, because it can get overconfident fools hurt
badly. Someone please name _any_ security tool that doesn't do this.

That said, first have your basic security squared away. Only then, layer that
with just enough obscurity to avoid attention. By analogy, acquire your
armored vehicle first, then drive it to your camouflaged hiding place. It
doesn't matter if you avoid all but 1 of 10,000 shots, if shrapnel from that
one shot kills you anyways.

------
pwg
He should instead put ssh-faker ( <http://freshmeat.net/projects/ssh-faker/> )
in front of his sshd, and then any attempt to connect from an IP not already
in /etc/hosts.allow will fail to even get to see his sshd, much less attempt
to exploit it.

The advantage of ssh-faker is that if you are logging in remotely from
somewhere that is not your normal haunt, you can remotely add an entry to
/etc/hosts.allow to let yourself past the gate.

~~~
gnosis
_"if you are logging in remotely from somewhere that is not your normal haunt,
you can remotely add an entry to /etc/hosts.allow to let yourself past the
gate"_

If you're "not in your normal haunt" and your attempts to log in are blocked
by ssh-faker, then how are you going to "remotely add an entry to
/etc/hosts.allow to let yourself past the gate"?

~~~
pwg
Because the way ssh-faker works, it sends an sshd connect string, just like a
real sshd, but then waits for you to enter a secret ssh-faker passphrase. If
you enter the passphrase, it adds the IP you are connecting from to
/etc/hosts.allow and then disconnects. So you first telnet to your ssh port,
enter your ssh-faker passphrase, then connect with ssh normally, and log in
(hopefully with only key based auth).

~~~
gnosis
So this requires you to first send a password in plain text (ie. unencrypted
and open to anyone who sniffs the connection) before you can log in? Why
telnet? This really makes no sense whatsoever.

Why not just require an extra ssh password? At least that way it couldn't be
sniffed. And even that is simply ridiculous, as you could just use one
password that's twice as long.

What am I not getting here?

~~~
pwg
It is not perfect. But then, nothing seldom is.

What it does protect from, given that most attackers will not have your ssh-
faker password, is from the attackers obtaining any access to your sshd to try
anything, be it a password scan or whatever. It is another layer in front that
deflects all of the script kiddies, and many of the more intelligent
attackers.

Why telnet? Because ssh-faker is not an sshd, and so you can't submit your
password to it using ssh.

Perfect, no, another layer, yes. Kind of like having a lock on both your front
gate and front door. Those who can't get through the gate lock can not ever
attack the door lock. Those who can get through the gate lock still have to
then attack the separate door lock.

------
growt
I'll just leave that here: <http://en.wikipedia.org/wiki/Port_knocking>

Not that I use or endorse it.

~~~
jefe78
I've used and endorse it. Set it up to accept a knock sequence along the lines
of:

Port 38378, 1292, 65000, in quick succession. IMPOSSIBLE a port scan will ever
hit those ports in that order.

Have that sequence trigger a modification to your iptables or execute some
script to modify sshd_config or whatever else. It works wonders and is another
level of security.

~~~
rarrrrrr
Quite impossible, since TCP ports don't go past 65535. :)

------
poutine
Port obscurity is pointless when there's much better ways to secure your host.

You should be running SSH with keys only, never with password authentication.
Passwords are for encrypting your keys on your local machine and for sudo
which is restricted to specific accounts. Source IP filters really slow you
down, but may work in some circumstances.

As your network gets larger you'll need to restrict any inbound SSH and use a
VPN to a firewall or bastion host and use something like puppet to distribute
your ssh keys. Make sure you do two factor auth to the VPN with a password and
at least some sort of key.

~~~
njharman
> Port obscurity is pointless when there's much better ways to secure your
> host.

Good security is layered. This reduces attacks. Reducing attacks is better.
Changing port is better than not changing port.

And most people posting here obviously didn't read the article because it
clearly stated this was in addition to all the other security measures you put
into ssh.

------
drdaeman
Well, SSH server is secured with `(username, auth_token, sshd_port)` 3-tuple,
where `auth_token` is a password, public key, OTP or whatever else it may be.
By changing the sshd port from default, one, indeed, would somehow increase
security.

People tend to change sshd port so they won't get port scanned. It should be
compared to hiding one apartment's door. However, the real annoyance is that
after some bot detects sshd it starts brute-force attacking it. Compare it to
thief standing in front of your door and trying to pick a lock for a long
time. There are tools like denyhosts[1] and fail2ban[2] to prevent such abuse
- N failed attempts and unless you're from a trusted network - you're banned.

The open question is whenever you gain something valuable, while giving up
your convenience (you'll have to specify `-p` option or register every host in
`$HOME/.ssh/config`)? Most security rightfully relies on `auth_token`, so
first thing to do is to ensure it's strong enough. The rest of changes are
relatively insignificant (just compare 4096 bits of your private key to 16
bits of port number).

I believe people care about their sshd port only because it's noisy in
`auth.log` when they're attacked.

------
teaspoon
Here's a philosophical question. Is choosing a strong password "security by
obscurity"? A 20-character mixed-case random string is only more secure than
the password "password" because so many users default to the latter, and to
short words and dictionary words in general. But it's no easier to generate a
rainbow table for an English dictionary than it is to generate one for an
equally-sized subset of 20-character strings.

------
juiceandjuice
What's even better is setting up an access sequence to allow you to connect to
SSH.

In the past, our experiment had a server that was hit particularly hard with
SSH attempts for some reason. So, you had to visit a page on port 8080, which
would temporarily add your IP to an allow list, in which case you could then
attempt to access ssh on port 22.

It works exceptionally good because port scanners usually start low :)

~~~
getsat
You've reinvented port knocking. Use SPA instead:
<http://www.google.com/search?q=single+packet+authorization>

~~~
juiceandjuice
yeah I couldn't remember what it was called.

The reason we had it as a web page was because it was easier for the
windows/putty crowd.

------
rlpb
There is another side to this risk. Perhaps you do lower the risk of
compromise by changing your port. But you also increase the risk of locking
yourself out somehow (especially if you use other tricks such as limiting IP
ranges).

This may seem unlikely to you, but so is being compromised if you're security
conscious, which you obviously are if you're thinking about changing the port
(you'll stay up to date, disable password authentication, etc).

Most security problems occur when you overlook something. For example, you're
far more likely to be compromised through a vulnerability in a web app you
don't use a package manager for and so don't receive automatic updates for. Or
through a user who set a weak password or compromised another machine with his
key on it. And so on.

I think that on balance it makes little difference when you consider the real
reasons why people get compromised.

------
poink
Of course it lowers your risk. Unauthorized users will make fewer connections,
meaning fewer login attempts, meaning less of a chance of being compromised.

Following from that, of course you should do it. In the vast majority of cases
it's no inconvenience (add a host block to your ~/.ssh/config file if you
don't want to type out/remember the port), so you're talking about a change
that's all upside.

It just doesn't get you off the hook for doing ANYTHING else in terms of
security good practice. You don't get to use insecure passwords (in fact,
preferably you're disallowing passwords entirely in your server config). You
don't get to be lax about cleaning up unneeded accounts. You don't get to
chmod everything 777 and ignore which binaries are SUID/SGID. You don't get to
slack off patching your box.

------
rapind
While I agree, you might be able to argue that the hits on an obscured port
(24 in this example) come from more experienced hackers who would be more able
to compromise your box. And potentially having a non conventional SSH port
might be attractive. I.e. Whatever's behind this hidden door must be more
valuable than what's behind this obvious door.

Overall though I think it would increase security... just might attract some
trouble too.

------
AndyJPartridge
If you change the port, you are saying you know more than the average admin,
and may have more interesting things on your server.

~~~
Vivtek
OK, that makes my brain hurt. (Not saying you're wrong...)

~~~
orenmazor
once you get the script kiddies out, all thats left are the mind games people.
like the bad guy from hackers.

------
jarin
I've got the SSH port on my webserver set to a random >1024 port, and I get at
least 2-3 denyhosts emails per day.

~~~
dspillett
You should not run a system service on a port below 1024. On unix-a-like
systems there is usually a rule that a non privileged user can not listen on a
port below 1024 - Apache and similar services do it by running as root or
similar initially and dropping privileges once the port is open and ready.

If you run SSHd on a port over 1024 you increase the chance that an non-
privileged user on your machine (a user on a shared host, or a compromised
externally accessible application) might somehow crash your SSHd and launch
its own to capture usernames/passwords or such.

Bots scanning for SSH on ports other than 22 will likely scan the whole 65536
range, not just the first 1024, so you don't get extra obscurity by using a
higher port.

~~~
gnosis
_"Bots scanning for SSH on ports other than 22 will likely scan the whole
65536 range, not just the first 1024, so you don't get extra obscurity by
using a higher port."_

Do you have any statistics to back up that assertion? I'd expect most
attackers to concentrate on ports below 1024, with proportionately fewer of
them bothering to scan higher ports.

------
andyv
My strategy for years has been to run SSH on port 22, visible only to hosts
inside my local network via a firewall (iptables) rule. Connecting on port 22
is not allowed from the outside. SSH also listens on port 2222 and can be
connected to from the outside, root logins are not permitted. Works great.

------
Groxx
> _The stats over the weekend were over 18,000 connections to port 22, and
> five (5) to port 24_

In other words: yes, to random probers. Jury's out on non-random (my guess is
no. If they're watching your network, and you _ever_ use the port, it'll get
probed for vulnerabilities).

------
zach
Discussing obscurity in the security community is like talking to coffee
aficionados about Starbucks.

Noneleless, if you can choose between being obscure or being a prominent
potential target...

~~~
danielrm26
That's precisely the attitude I was trying to address with the article. If you
ask the top security people in the world, they agree that obscurity _can_ aid
security if don't correctly.

Those who disagree with this outright are stuck with someone else's thoughts.
Please read: <http://danielmiessler.com/study/security_and_obscurity/>

~~~
zach
Wonderful explanation.

I never run SSH on port 22 on a publicly-visible computer when I can help it.

I thought it astounding that the idea sometimes meets with scoffing, seemingly
with a presumption that such a practice must be the sum total of one's
security precautions.

No matter how effective a security technique is, it can be shouted down as
"taking minimal effort to overcome," "providing a false sense of security" or
"not going to stop a determined attacker." Dude, I live in a Bayesian world, I
just want to improve the probabilities. Then again, that must be effective
rhetoric for getting consulting gigs.

------
16s
Yes. Obscurity works. I mean it's not perfect, but otherwise, why put camo
paint on tanks? Why not just paint them bright pink and let them stand on
their own defensive capabilities?

------
trotsky
If you filter IPs for sensitive services like ssh (and isn't that fairly
standard practice) then I wouldn't expect there to be a real difference in
risk level.

~~~
code_duck
No doubt, IP filtering is the most secure plan. It's not feasible for many use
cases however.

For instance, I have our servers only accessible to my work IP. However, that
means I need to connect to them through there when I am not at work - coffee
shops, hotels, my phone's dynamic IP - so my work server needs to be
accessible to anywhere.

~~~
trotsky
You don't use a VPN in those locations?

~~~
code_duck
I'm not even sure what exactly a VPN is, to be honest. I use SSH and SSH
tunneling to do everything.

~~~
trotsky
The same result as an ssh tunnel just lower on the network stack. In your case
it'd seem that you can filter all your servers except for your one
tunnel/bounce host. A VPN host just wouldn't have anything else on it.

~~~
code_duck
I should look into that. Thanks for the tip.

------
chopsueyar
Here's another obscurity question: Does usings hosts files instead of public
dns for domain lookup lower your risk?

~~~
unshift
no. if you're scanning for open ssh ports you just scan IP blocks, not host
names.

~~~
viraptor
At the same time, I wouldn't leave your domain names open to full listing from
any host. Otherwise finding one correct login, rev-dns of the host and the
whole list of your internal machines might cause many problems...

------
invertd
There is definitely a benefit. However, don't feel too complacent about the
perceived benefit.

