Ouch, camouflage on a tank is a good analogy. Nice response post.
In addition to, as the author encourages, being "weary of the 'by obscurity'" argument (as I'm sure we all already are), I would also advocate being wary of it :)
No it isn't. Every server runs SSH, so this is more like there's a field, and you know there's a tank in the field, but you can't see it.
The next thing you do then is take out your standard radar device which scans the field, and pinpoints exactly where the tank is in 3 seconds, and then you aim your tank buster at that spot and fire.
In my experience most of the time "attackers"/script-kiddies just scan over a range of IPs for port 22, and if it's not open on your computer, they just move on to the next IP. That's why you get thousands of requests for port 22 and very few on say port 21.
Of course, not that it would stop someone willing to spend more than a few seconds on attacking your server, but still makes the camo analogy a quite nice one in my opinion.
Or, you put up a fake, camouflaged tank and let the enemy reveal themselves when they attack it. (Leave 22/tcp open as a honeypot, triggering an immediate iptables drop).
2. Next he talks about this non-root listener issue. He
claims that you shouldn’t run your SSH daemon on a
non-privileged port because anyone can spin up a daemon
up there. Great point, except you can still do that even
if you run your main one on 22.
I don't think I understand this point at all. What is it that you're trying to say?
Are you sure you understood the original post's point?
djc@capelis.dj:~$ nc -l -p 14
nc: bind to source :: 14 failed: Permission denied
nc: bind to source 0.0.0.0 14 failed: Permission denied
nc: failed to bind to any local addr/port
djc@capelis.dj:~$ nc -l -p 1414
^C
See the difference?
(Edit: The original blog entry has now been edited to slightly clarify the wording. But the update mostly seems like an attempt to rapidly justify the author's original point.)
To be fair, you could get the advantages of both by running SSH on a different privileged port than 22. Many of the lower numbered even-numbered ones are good options as for historical reasons those are all mostly unassigned. (Pretty much any even number below 16 isn't used by much.)
But I agree, the privileged ports point isn't something that should be brushed aside.
> To be fair, you could get the advantages of both by running SSH on a different privileged port than 22.
ephemeral port range are a tunable at least on FreeBSD. However tuning stuff like this is fraught with disaster consider how difficult it is to guess an ssh password vs all things that can go wrong when changing sshd's listening port. But do it if you want, I bill by the hour.
What can go wrong by changing the listening port of sshd?
I have changed the port on my vps purely for less clutter in my logs, but I haven't had anything go wrong because of it.
It introduces a communications problem. Which machines are running SSH on a non-standard port and what is it? Plus some tools are harder to set up, IIRC SVN+SSH is one of them.
When you have to use the java applet of the Control Panel in your browser to manage your VPS. If your sshd is not on port 22, typically the applet won't find it and you're screwed.
So you're operating with a compromised user account capable of killing your sshd on port 1234 but there's no other local escalation exploits?
Seems like something a little script or patch could fix up really easily - make sure your daemon is running on port 1234. If it's not, take whatever defensive measures you think would be effective.
Or instead of doing a script or a patch, you could just do the right thing in the first place and run your daemon on any of the literally over one thousand ports set aside for privileged services.
Running on a privileged port doesn't change which other hosts can connect to the privileged server though. At best it tells the client that the server is probably running as root (or has the appropriate capability bit).
If you're worried about an impostor sshd on that host then I would tend to agree that it's simply not prudent to be connecting to that server at all, let alone passing key material or credentials.
The absolute best way to know that is to know the public host key and verify your keys. Additionally, you don't have to resort to high ports to achieve a best of breed. Just !=22 is enough to avoid majority of skiddies.
> You don't get that from it being on 22; you get it from verifying host keys.
You know how you just wrote a blog post talking about how more layers of security are better even if all you're gaining is obscurity? This isn't an exception. And it is a valid point that by moving from a privileged port to a non-privileged port, you just traded away a layer (arguably a more useful one than you gain by moving away from 22) for absolutely no reason. (You could move to a different privileged port and still get everything else.)
tl;dr: You advocate giving up an actual layer of protection for a layer of obscurity. This is especially puzzling when you could get both.
Further, the reality of the situation is that as a practical matter most sysadmins are terrible about key management and when they see those warnings the very next thing they almost always do is immediately delete the key and hastily attempt to login to the machine via ssh. (The better ones to see what's going on and try and fix it, and the worse ones just assume that the key changed because sysadmins change keys all too often without notifying users and don't investigate at all.)
It turns out that humans are annoyingly predictable.
I'd say it differently, though. Instead of defending the original point, which was bad, I'd instead say among all other controls--most important of which is patching, removing passwords, etc.--one control is running below 1024.
I could go for that.
Except I actually think the gain from being up high (over 60K) is greater than the gain from being below 1024. It's not about being invincible, it's about not being a target at all.
Firstly, I like the tone you used to concede your original point.
As to whether the port should be below 1024 or above 60000, I am undecided. I'd love to see some empirical data on this: let's say I run ssh over several days on port 22, port 762 and port 90332. How many connections do I get for each port?
Privileged ports isn't an example of security through security. Maybe you could call it security by convention. Still, it relies on a number of assumptions, none of which can be relied upon if a system is compromised, and if the system isn't compromised... well, you don't have a problem now do you?
Honestly, the only win of a using "privileged ports" these days is you don't have to worry about the odds of some other service randomly binding to your port. Since most systems spin up ssh well before they spin up services that bind to random ports, and generally don't ever shut down ssh, that isn't much a win, but either way, it is NOT a _security_ win.
How are you going to log in to your shell, with your environment, without a daemon that has the suid bit? A user can never install such an sshd without having root permissions at some point.
If you run ssh on a static port, then it really does not matter whether it is 22 or 2200, as long as it remains static, and everyone knows the correct port.
If it turns out that that daemon is logging your passwords, then someone has already compromised your host.
What makes you sure, that the daemon listening on port 22 is is a 'true and sanctioned sshd'?
Because of it uses a port under 22?
If you have fear that a port of your server listens on any unprivileged port and it than you have far more problems with that box then the sshd.
_If_ a port is opened by a user that emulates the sshd daemon to grab your passwords that means that:
a) this is the usual port you use for ssh
b) your box is hacked, then the real sshd daemon that usualy would listen at this high port is replaced by something else. That means sombody has root access to that box (the sshd has to be killed for that)- big big OUTCH
c) you box isn't hacked but you have some non trustwoth people have access to that box, that use some exploits for rights traversal
All in all I would say, constructing a security issue of using a non standard ssh port is academic. If that could be abused you have far more problems on your system than that changed ssh port.
On our production servers I use the following:
1. ssh access with keywords is disabled
2. ssh access for root is not allowed
3. ssh access is allowed from one trusted IP address only
4. restrict users with access to ssh to only the needed ones
5. users with git access get as shell '/usr/bin/git-shell'
optional: If you're paranoic like me and like some technical baublery you step 3 this way that users have a VPN to the server with the trusted IP
His argument is that we can't be sure whether we're talking to the real SSH running or some rogue SSH run by an unprivileged user. That's why SSH servers have their server host keys with fingerprints you're supposed to verify using a different channel when first connecting: if someone managed to spin up a rogue SSH server, it would have a different host key and you would get a big fat warning from your SSH client that the server key doesn't match.
That's what file system permissions are for, on the private key.
(I might be wrong about this, but...) I've seen quite a few instances where SSH refuses to let people even try to log in if there's a chance that a private key has the wrong permissions applied, so as to minimize the risk of someone accidentally letting others read it -- as you suggested.
You'll find the default SSH config on the more noteworthy Linux distributions to do this 90% of the time time without even asking :)
No, they couldn't. sshd usually runs as root* so it can create shells for in user that's logging in. Therefore, only root could kill the daemon. Also, as mentioned by the sibling post, its configuration files are usually(if not you have a serious problem) only writeable by root so nobody else could modify them.
* Note, I guess you could run an sshd that only allows logging in to a single user and runs as that user but both points above still stand even in that case.
Could a non root user just read the host keys from sshd,
No, file permissions.
then kill it and serve them?
Users with uid != 0 cannot kill other user's processes.
Or could it even just MITM it?
No, host key verification ensures that you are talking to the intended ssh daemon without packets being intercepted. The host key is a public key of the SSH server, which is verified by the client to be the key registered for that particular host. Since only the server has corresponding private key, the MITM cannot eavesdrop on the key exchange.
UNIX is built as a multi-user operating system. You may not use that ability very much, but there's a reason the operating system was built this way and there's a reason these things work the way they do. It is completely valid to point that out.
You're free to say you don't care, but it isn't really valid to brush aside the point by pretending a security model that's there for a reason isn't there.
Also it isn't uncommon at all for an attacker on a server to get access to a regular account and not a root account in their initial vector. It is often too easy to escalate, but do you really want to help them out more?
In fairness, multi-user linux systems have been losing popularity for a long time, with KVM/xen-based VPS services taking over for having significant advantages in security and software compatibility.
A young software engineer in today's environment can easily never have any exposure to a truly multi-user OS.
I think you're misunderstanding - GNU/Linux is a multi-user OS regardless of if it is run in a kvm/xen/etc container or on bare metal.
Even if only one person (or no persons) ever log in, the machine is capable of running processes under multiple users and it is best practice to maintain this so that all users do not share the same level of privilege.
Yes, but he's noting that a younger engineer may have never encountered a system with multiple users, so wouldn't think that being able to open a privileged port is more terrifying than being able to spin up netcat on 10032.
The ability for someone to "spin up a daemon on your server" would also be called an unprivileged exploit. The ability to spin up a daemon on port 22 on your server, however, would be called a privilege-escalation exploit waiting to happen.
If a zero-day gets discovered in the kernel that allows the former, you'll be hoping that it isn't also the latter. This is why trusting unprivileged ports is a bad idea.
(...until, you know, we finally start using DNS service-records for this sort of thing.)
Something as simple as an exploit against a php script could lead to unprivileged code execution & something as minimal as memory exhaustion could kill off your sshd process. If the sshd process is killed, and the attacker knows what port it was on (netstat -na | grep LISTEN), the attacker could spawn their own daemon on the unprivileged port that was previously being used for sshd, and that daemon could be used to collect plain-text passwords that people try to use when logging in. Heck, they could craft their daemon to log all keystrokes & which could grab the local root password.
This is a very valid point and a good reason to choose a port in the privileged range if you use an alternative port for SSH. I wonder, though, what is the worst it can do if you don't use password authentication? E.g., to offer you a fake shell and try to capture your sudo password a rogue daemon would have to have access to your public key, which as an unprivileged user it shouldn't.
Run it on a port where (port != 22 && port < 1024). Problem solved. Not every non-standard port is unprivileged. Lots of people run SSH on port 443 to get around firewalls.
I run my SSH daemons on port 1022. It reduces brute-force attacks significantly without reducing security in any way that I'm aware of. I also have a ~/.ssh/config file in my laptop that tells SSH to use port 1022 whenever I'm connecting to one of my own remote machines so I don't even need to type anything extra when I use ssh, rsync, etc.
I agree but I think TFA should clarify that it's probably a good idea to run sshd on a non-standard port < 1024.
While other posters are right to point out that server certificate should make sure nobody can truly hijack your sshd there's no point in taking the risk unless for some reason all privileged ports are in use.
Not to mention that ssh's key model is a bit broken since there's not built-in way to distribute the keys/check the keys against an authority like with SSL. Most people just accept the key they're given when they first connect (I know I do).
You can verify the fingerprint, can't you? Not that I always do it (even is just the "first time", as you said), but IMHO the SSH model is definitely better than a central authority you have to pay to get your certificate signed.
They just need to scan once to find the port speaking SSH, then brute force as usual.
If you want actual more protection run a bogus SSH (with no login allowed) on 22 and a thousand unused ports... then they have to try them all or guess which port is actually able to log in.
OTOH, not running on port 22 prevents you from drive by scans.
You are right that it doesn't protect from a targeted attack. In my experience (10 years as a sysadmin and dev), I've never had a targeted attack -- all the attempts against my machines are drive by.
Having port 22 open can end my IPs on a list of "let's try to break later".
It's not close to a complete solution, but I find it beneficial.
> Not to mention that ssh's key model is a bit broken since there's not built-in way to distribute the keys/check the keys against an authority like with SSL.
I think the recent NSA news indicate that the SSL authority model is broken. Any 3rd party authority can be subverted by legal (e.g. NSL) means.
SSH's model leaves that only semi-solved. you CAN distribute your own "known_hosts" file, thereby avoiding the need for either an SSL-style authority, or remembering every host's key. Alternatively, you can use something like SSHFP+DNSSEC/DNSCurve or Monkeysphere if you like the underlying trust models.
ssh's key model is NOT broken. SSL's models IS practically broken. ssh just leaves a little less specified.
I would never have known about this had I not read this article and the comments here, and have been running SSH servers for a very long time.
The solution I'm particularly fond of is mentioned in Daniel's blog comments, which is to use iptables to block externalip:22 and redirect a non-standard port to localhost:22.
I'm with you on that one. Setting up OpenVPN is a day worth of work at most and gives you the freedom not to have to worry about this stuff in the future.
VPN is not mutually exclusive with using SSH. What he's saying is that people should firewall their SSH ports to only allow access from trusted IPs, and VPN's make that easier to do.
Yes, in a sense those things are mutually exclusive.
You can get in a network by VPN or SSH. Yes, after that you can also log into a computer by SSH, but the question remains - why access the network by VPN instead of SSH?
Its kinda silly to move the port, a targeted attack is going to start with an portscan of you box, the attacker is going to say "oh what’s this here on port 2222?" and promptly discover that its ssh listening on a high port. Port knocking would make that discovery less likely I suppose but its still all treating a symptom of a bigger problem.
So why not solve the problem with something a little more proactive like turning off password auth and go for sshkeys only. Maybe toss in something like fail2ban if you want to interrupt kiddies scanning your boxen.
That said high port ssh can be nice if you're frequently on restrictive networks and getting out on port 22 is impossible.
I think you've missed the point. Ultimately, moving the port isn't securing the service but is just one more layer. It won't hold against a focused attacker but will hold against a majority of casual scanners just looking for a large number of SSH targets. The goal isn't to do keys OR move the port. The goal is to combine all the factors at your disposal to disrupt and discourage attacks.
I completely agree, moving the port is a must just to change up the configuration from everyone else's. Configuration items like port numbers are meant to be tweaked, especially when you can just stick a unique SSH port in your ssh_config.
However, it's not hard to imagine these scanners have moved further past the days of the Morris worm and aren't just simple port scanners. Identifying what services are on what ports is a relatively easy process that doesn't remove much from the discovery phase of a bot or script kiddie. Hell, code review metasploit for a half hour and rip theirs out.
Thats where fail2ban is useful, pick a number of failed auth attempts on any service you care to integrate, lets say 8 PAM failures, and trigger a rule that inserts an iptables rule to drop/reject the attackers IP for 5minutes. That will time out the ssh scan for all but the most patient scanners. If you shared the fail2ban database across hosts you could inject null routes for the offender into your router or block them at your firewall.
I think you have missed the point - you should tell why using non-standard port is less secure, not provide me an alternative, because I would also argue VPN is better fail2ban.
You cannot neglect the fact that there are vast amount of bots scanning only port 22 in the Internet. We know this because we have found the evidence in our OWN logs, not from those security experts always saying security through obscurity is bad and therefore we should do nothing.
Documenting and configuring it has a non-zero cost which could be spent doing something else more impactful.
I've never seen an infrastructure where there was a sufficiently advanced state of security such that obscuring the port numbers of services was the at top of the todo list.
Unless people recommending these things work for shadow organizations I've never heard of, I'm pretty sure it's something done without any kind of cost-benefit analysis.
What are the odds of a SSHd zero-day? Or, more specifically, what are the odds that someone with zero-day knowledge would be so stupid as to decide to risk the vulnerability being discovered by others by using it in a horizontal search of all running SSHds?
Because it has to both be more likely than any other attack that could be mitigated (and port obscurity would have to be the most effective solution) with the same effort.
Pretty sure that for virtually all infrastructures, auditing that your systems are properly isolated, users and services have the least privilege possible prevent massively more probable attacks, and that firewalling services or port knocking or really anything are more effective solutions for this attack.
Well, apparently with Zmap [1] you can do internet-wide scans in less than an hour from a single host, so I can't imagine they'd have that much trouble finding any open SSH ports on a smaller IP range.
So just changing the SSH port will do little, but enabling port knocking would help it stay hidden.
Here is something to think about, the author is right, but if you follow many ssh setup tutorials that say to move to say port 25000, you are less likely to be port scanned than the default, but still more likely than if you had used something totally random like say port 42 or 818. By me even writing this clever hackers will start scanning those ports too, just to be sure they are hitting everyone. That being said, any port is better than the standard one and picking an unused port instead of the standard ssh port will give a reasonable 80/20 benefit for a lot of people.
Port scanning is generally automated (edit: and scans all ports, not just the handful you listed), so it doesn't actually matter which port you pick as long as it's not 22. Port scanners like nmap are widely available, so the time to actually figure out which port is running SSH is quite short in practice.
Basically, there are two classes of people:
1. Those who use port scanners.
2. Those who do not.
If you are being attacked by someone in class 1, then moving your port gives you absolutely no protection. Thus moving your port is only worth anything at all if the percentage of class 2 people is significant.
However, if you also consider the probability a person in each class has of actually compromising your machine, then the security looks less convincing. Yes, it might be true that 95% of people don't bother to use a port scanner, but the most competent hackers are almost certainly going to be in the 5% that do use one.
Anyway, those 0.999999 that don't scan the ports are doing lame attempts of guessing the password of your box, while the 0.000001 is doing that, but also trying new exploits that have a chance of working.
As a consequence, the chance of one of those 0.999999 bots invading your computer is zero, the chance of one of the 0.000001 doing the same is non-zero.
Who is going to bother with a portscanner when there are plenty of targets on port 22. The targets on other ports are more likely to have been set to use keys, or at least have better passwords.
When you set the system to use keys, all those attempts at accessing just don't happen, and the log does not get polluted. Since the log pollution is the main complaint of people that change the port, I think you are wrong.
There are indirect scanning techniques that induce and measure traffic from ordinary non-compromised hosts. When the attacker notices that he gets banned for scanning he'll do that.
The reason he's right is most attacks on SSH are one-dimensional.
In most cases the dimension is IP range - an automated process moves from IP address to IP address examining port 22 for any common vulnerabilities. Rarely do these processes check all ports. Moving your SSH deamon to a different port prevents those automated processes from then hitting your security layer on whichever port you are running.
The other dimension of attack is when an attacker is focusing on your IP address specifically. Then he probably is going to nmap your IP and discover which port(s) SSH is running on. Changing the default port for SSH doesn't help here, but this use case is far less common.
Like others have said, changing port doesn't remove the need for security measures (cert-based/passwordless login, disable root, fail2ban) but it reduces any of those even being tested in the first place when most of your attempted attacks are IP-range based.
Turning off passwords and only using keys also mitigates the standard brute force attacks that happen. Frankly I'd much rather do that then have my server on a non-standard port.
Even better yet is pam_abl. If any IP or user fails authentication faster than a configured rate pam_abl will block logging into that user or any authentication attempts coming from the same IP address and it's all nicely tied into PAM so you don't have to worry about yet another fail2ban vulnerability or someone spoofing some important IP address and tricking your server into blocking it.
Bots frequently exploit changes that were recently fixed upstream. Not perhaps 0-days, but maybe a couple days after the original fix. How up-to-date do you really keep your SSH server? On the off chance the attacker gets to an exploit faster than you get around to updating your machine, then keys won't keep you safe. Using a non-standard port in that scenario might very well save you from the botnets, if the GP's argument about the dimensionality of attacks is correct.
> Frankly I'd much rather do that then have my server on a non-standard port.
Frankly, the problems with key security and management are much worse than are being discussed. Using only keys is fine as long as your keys are secure and you know which is which and control all access and immediately remove any key which needs to be. In a complex environment, this is extremely difficult and more prone to security breaches than password access.
Security is as strong as your weakest link. If you can't protect your port 22, any other ports are probably easy to take over too. Are you saying you get extra time since attacker has to find this new port? I am not totally sure what you mean. Please educate me.
It's more of an annoyance. If you require password based login, port 22 will lead to constant attempts that fill the logs. Move to any other port,and you'll see none.
Curiously, that was my primary motive for moving SSH on a couple of servers off 22. It had nothing to do with any notion of security and everything to do with the annoyance of filling up my auth logs with mindless login attempts by dozens of bots.
Maybe that's the wrong reason, but irritation can be a decent motivator. :)
Your premise is wrong – while the security of encryption, for example, is as weak as the weakest out of algorithm, key, random numbers used etc., the security of a system solely attacked via the SSH daemon is the sum of each layer of defence (or at least the strongest of these layers); that is, an attacker has to pierce each layer individually and successfully attacking one of them (e.g. finding the SSH port or the correct port knocking sequence) is not enough to render the whole defence void.
Actually, one thing I've found useful is keeping an sshd listening on port 443. I know, I know, sacrilege reusing the HTTPS port, right?
The benefit of this is that it can allow you to tunnel through an HTTP proxy (e.g., like in a corporate environment). Many HTTP proxies only allow traffic through to port 80 and port 443. The benefit of ssh on port 443 is that if the proxy is handed a CONNECT verb, it will transparently just transmit data between your client and the remote server, irrespective of what that content is. In fact, this behaviour is what makes HTTPS remain secure when going through an HTTP proxy.
You can use this to tunnel ssh through an HTTP proxy. Putty supports this out of the box, but if you're using openssh, you'll need corkscrew also.
You can always try to tunnel to an ssh server on port 22, but most proxies will hand you HTTP403 on any CONNECT request to a non-port 443.
I use sshttp for this - support for both port HTTP and HTTPS. I don't serve any webpages, but I wanted the option to also use a more aggressive SSH holepunch on the same port, and just naked SSH if I could.
> Many HTTP proxies only allow traffic through to port 80 and port 443. The benefit of ssh on port 443 is that if the proxy is handed a CONNECT verb,
Thats not how HTTPS works, there is no HTTP proxy for 443. You are in a corporate environment where nothing is let out on port 80, except through their HTTP proxy. However, port 443 is allowed out.
> In fact, this behaviour is what makes HTTPS remain secure when going through an HTTP proxy.
That would be a MITM against https and it doenst work that way.
If you would go over the http proxy to connect to your sshd on port 443, that would be stupid as the proxy would see your connections. Its much easier and better to just connect directly without asking the proxy.
Right. Sorry, in case I wasn't clear, the HTTP proxy acts as a proxy for HTTP on port 80, but tunnels HTTPS traffic (and anything else including ssh) on port 443. The tunnelling is done using the HTTP CONNECT verb.
Standard or not standard port, you still should use port knocking in a way or another (or only enable it for the specific IPs that can access it ever). Internet don't even should be able to know that you have there a service that is only for you or for a very small amount of people.
If a remote vulnerability is discovered in the server (happened in the past, don't rule it out for the future), you will be attacked, and it won't be a brute force attack to be blocked by fail2ban or similar. You can be scanned in any time, put in a database as "having ssh version x running in y port" and get ready for future use.
And if well simple port knocking could be defeated inspecting your traffic, there are variants like fwknop that are resistant to that kind of interception or replaying.
Agreed. Contrary to the naysayers, port knocking is an unalloyed good.
Whatever your setup is, it's better if it doesn't show up in a scan at all.
The "knock is a weak password" argument is silly - nobody suggests using only the knock, but rather to use the knock in addition to your existing auth scheme.
On my personal boxes I use a combination of non-standard ports, disabling password auth (seriously, this will do more for your security than anything else), and fail2ban. Even with key authentication fail2ban still blocks several IPs a day.
The "change-port" discussion for SSH is so boring :-/ OpenSSH is I guess the most secure daemon on all your servers. People should more think about to change the HTTP(S) ports of their non-public facing sites and other daemons and frameworks they use.
> OpenSSH is I guess the most secure daemon on all your servers.
Probably correct. However, sshd should be the only public facing daemon that hasn't dropped root privileges immediately after binding to its privileged port.
So it should be the only daemon that can directly offer root privs to an attacker.
I say "should" because it's a big world out there and people do some bizarre and indefensible things. Sometimes merely lazy things, but the net effect is the same.
It is almost the same thing to offer non-root privs, because of the great number of patched and unpatched priv escalation holes in Linux. Almost guaranteed you will be able to get root if you get normal user privs.
Anyone use Dome9? (http://dome9.com) they close all of your ports and open them on demand via chrome extension or mobile app for when you want to use SSH.
In moving sshd to an alternate port, I've noticed two things: a greatly decreased amount of log noise from dictionary attacks, and a moderately increased amount of portscans.
It's reasonably clear to your average net malfeasant that any host running recognizable services is going to be running sshd.
So why not do both?
Put a dummy sshd on 22/tcp, deny all auth attempts, log whatever keeps you swimming in interesting data.
Then run real sshd elsewhere, possibly filtered, possibly port knocked, and hopefully permitting key-based auth only.
And use sshguard, because the only thing you should care on a secured host is power consumption. One of my boxes went to 33% on all CPU threads during a sk attack.
I've done this in the past with some pretty good results. Though, I've dropped it because I found myself constantly locking myself out of my own machines.
I can't deny, it is a cool technique though. PortSentry is a good tool to use for just this. Anytime someone came to :22 and the machine just disappears.
So really the only problem you had with the argument is the security via obscurity? Yeah, me too. Otherwise, his point were spot on and you didn't address them directly.
a: $port != 22 is enough to thwart most bots and skiddies.
If you think the port number is a guarantee that you are
safe or that you are communicating with a blessed ssh you
are sadly mistaken.
b: Uhh the port number means nothing.
Host keys are there for a reason... Someone does not
understand the functions of SSH.
http://www.snailbook.com/ <- great book
c: If you are not investigating fingerprint issues when
logging in via SSH and you call yourself a sysadmin,
please stop. You are going to be the reason your company
ends up in the news because your shit got owned and
2,000,000 user account hashes were leaked blah blah.
d: If you are not using key based auth and you have a fly
by night keystore policy. Which means you have a
keystore - stop. The whole keystore for SSH shit
irritates me. I cannot tell you how many times I have
heard sysadmins say a that a single private key is a
"best practice". It is not a best practice it is a
stupid practice and really prevents you from protecting
unauthorized logins on other machines for the obvious
reasons.
Put your public keys on bitbucket.com or source
management. Put your private keys on an encrypted disk
in an encrypted archive if you must. This is still dumb
imho because it is not needed.
Leave one account (root) with console only/no ssh access
that will allow for keys to be revoked/recreated when
users need new keys.
f: Spinning up daemons is a big deal for non-priv users?
So spinning up a remotely accessible Lisp out of emacs
from a screen that is running in the background is bad?
Hmm, here I thought that computers were meant to be tools
for humans to get work done... Sorry, background processes
are part of getting shit done. Users should be able to spin
up the stuff they want to spin up in the network segments
they have access to without the bureaucracy of misguided
fools making the jobs of others more difficult because
they think spinning up a gunicorn process or a custom daemon
is worse than their unpatched kernel, apache tomcat and mysql
listening on a publicly accessible address. Stateful firewalls
and hosts allow/deny are there for a reason.
Sorry for the snarky reply here but there are a lot of people
chiming in that obviously have very little knowledge about
managing *nix ops and remote access. I have pretty strong opinions
about this kind of stuff. Especially the single key stupidity and
not checking host fingerprints.
Sorry for deviating for the topic, but I think it must be said: "Sorry for the snarky reply" is not enough, considering that you wrote it at the same time you could have gone back and rewrite the text into a polite, well-worded argument. That's just condescension - if you really were sorry, you'd have rewritten your text.
By replying like that you've ensured that your point won't come across - for all I know you might be technically right, but using that tone ensures that lots of people will refuse to read past the second paragraph.
If your argument is solid, that's all you need. IMHO, snark makes your point come across as bragging, and no one likes that.
"Sorry for the snarky reply" is not enough, considering that you wrote it at the same time you could have gone back and rewrite the text into a polite, well-worded argument. That's just condescension - if you really were sorry, you'd have rewritten your text."
You are right. I am not sorry for the snarky reply.
"By replying like that you've ensured that your point won't come across - for all I know you might be technically right, but using that tone ensures that lots of people will refuse to read past the second paragraph."
Okay.
"If your argument is solid, that's all you need. IMHO, snark makes your point come across as bragging, and no one likes that."
I run my ssh server on port 443 in addition to 22, because some network connections block anything except 80 and 443, and this allows me to easily proxy through that broken network connection.
(Actually, I appear to have stopped doing this. But it's something to consider if you are on weird networks on a regular basis.)
188 comments
[ 3.4 ms ] story [ 97.2 ms ] threadIn addition to, as the author encourages, being "weary of the 'by obscurity'" argument (as I'm sure we all already are), I would also advocate being wary of it :)
The next thing you do then is take out your standard radar device which scans the field, and pinpoints exactly where the tank is in 3 seconds, and then you aim your tank buster at that spot and fire.
Of course, not that it would stop someone willing to spend more than a few seconds on attacking your server, but still makes the camo analogy a quite nice one in my opinion.
Are you sure you understood the original post's point?
See the difference?(Edit: The original blog entry has now been edited to slightly clarify the wording. But the update mostly seems like an attempt to rapidly justify the author's original point.)
But I agree, the privileged ports point isn't something that should be brushed aside.
ephemeral port range are a tunable at least on FreeBSD. However tuning stuff like this is fraught with disaster consider how difficult it is to guess an ssh password vs all things that can go wrong when changing sshd's listening port. But do it if you want, I bill by the hour.
galacticdominator% sysctl net.inet.ip.portrange net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 10000 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023
Read the article.
Seems like something a little script or patch could fix up really easily - make sure your daemon is running on port 1234. If it's not, take whatever defensive measures you think would be effective.
If you're worried about an impostor sshd on that host then I would tend to agree that it's simply not prudent to be connecting to that server at all, let alone passing key material or credentials.
You don't get that from it being on 22; you get it from verifying host keys.
You know how you just wrote a blog post talking about how more layers of security are better even if all you're gaining is obscurity? This isn't an exception. And it is a valid point that by moving from a privileged port to a non-privileged port, you just traded away a layer (arguably a more useful one than you gain by moving away from 22) for absolutely no reason. (You could move to a different privileged port and still get everything else.)
tl;dr: You advocate giving up an actual layer of protection for a layer of obscurity. This is especially puzzling when you could get both.
Further, the reality of the situation is that as a practical matter most sysadmins are terrible about key management and when they see those warnings the very next thing they almost always do is immediately delete the key and hastily attempt to login to the machine via ssh. (The better ones to see what's going on and try and fix it, and the worse ones just assume that the key changed because sysadmins change keys all too often without notifying users and don't investigate at all.)
It turns out that humans are annoyingly predictable.
I'd say it differently, though. Instead of defending the original point, which was bad, I'd instead say among all other controls--most important of which is patching, removing passwords, etc.--one control is running below 1024.
I could go for that.
Except I actually think the gain from being up high (over 60K) is greater than the gain from being below 1024. It's not about being invincible, it's about not being a target at all.
As to whether the port should be below 1024 or above 60000, I am undecided. I'd love to see some empirical data on this: let's say I run ssh over several days on port 22, port 762 and port 90332. How many connections do I get for each port?
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#T...
Honestly, the only win of a using "privileged ports" these days is you don't have to worry about the odds of some other service randomly binding to your port. Since most systems spin up ssh well before they spin up services that bind to random ports, and generally don't ever shut down ssh, that isn't much a win, but either way, it is NOT a _security_ win.
You might be surprised how often StrictHostKeyChecking is no. Are you checking it on your active installs?
If you run ssh on a static port, then it really does not matter whether it is 22 or 2200, as long as it remains static, and everyone knows the correct port.
If it turns out that that daemon is logging your passwords, then someone has already compromised your host.
If you have fear that a port of your server listens on any unprivileged port and it than you have far more problems with that box then the sshd. _If_ a port is opened by a user that emulates the sshd daemon to grab your passwords that means that:
a) this is the usual port you use for ssh
b) your box is hacked, then the real sshd daemon that usualy would listen at this high port is replaced by something else. That means sombody has root access to that box (the sshd has to be killed for that)- big big OUTCH
c) you box isn't hacked but you have some non trustwoth people have access to that box, that use some exploits for rights traversal
All in all I would say, constructing a security issue of using a non standard ssh port is academic. If that could be abused you have far more problems on your system than that changed ssh port.
On our production servers I use the following:
1. ssh access with keywords is disabled 2. ssh access for root is not allowed 3. ssh access is allowed from one trusted IP address only 4. restrict users with access to ssh to only the needed ones 5. users with git access get as shell '/usr/bin/git-shell'
optional: If you're paranoic like me and like some technical baublery you step 3 this way that users have a VPN to the server with the trusted IP
(I might be wrong about this, but...) I've seen quite a few instances where SSH refuses to let people even try to log in if there's a chance that a private key has the wrong permissions applied, so as to minimize the risk of someone accidentally letting others read it -- as you suggested.
You'll find the default SSH config on the more noteworthy Linux distributions to do this 90% of the time time without even asking :)
* Note, I guess you could run an sshd that only allows logging in to a single user and runs as that user but both points above still stand even in that case.
No, file permissions.
then kill it and serve them?
Users with uid != 0 cannot kill other user's processes.
Or could it even just MITM it?
No, host key verification ensures that you are talking to the intended ssh daemon without packets being intercepted. The host key is a public key of the SSH server, which is verified by the client to be the key registered for that particular host. Since only the server has corresponding private key, the MITM cannot eavesdrop on the key exchange.
You're free to say you don't care, but it isn't really valid to brush aside the point by pretending a security model that's there for a reason isn't there.
Also it isn't uncommon at all for an attacker on a server to get access to a regular account and not a root account in their initial vector. It is often too easy to escalate, but do you really want to help them out more?
A young software engineer in today's environment can easily never have any exposure to a truly multi-user OS.
Even if only one person (or no persons) ever log in, the machine is capable of running processes under multiple users and it is best practice to maintain this so that all users do not share the same level of privilege.
But maybe I just miss computers where finger, write, wall and talk were all useful commands.
And people say things are more social now? The growth of hypervisors made our operating systems desolate and lonely! :)
If a zero-day gets discovered in the kernel that allows the former, you'll be hoping that it isn't also the latter. This is why trusting unprivileged ports is a bad idea.
(...until, you know, we finally start using DNS service-records for this sort of thing.)
No, that is very, very wrong. This is SOP for an account on a system
nc -l 9000 <- spinning up a daemon on your server
I run my SSH daemons on port 1022. It reduces brute-force attacks significantly without reducing security in any way that I'm aware of. I also have a ~/.ssh/config file in my laptop that tells SSH to use port 1022 whenever I'm connecting to one of my own remote machines so I don't even need to type anything extra when I use ssh, rsync, etc.
While other posters are right to point out that server certificate should make sure nobody can truly hijack your sshd there's no point in taking the risk unless for some reason all privileged ports are in use.
Not to mention that ssh's key model is a bit broken since there's not built-in way to distribute the keys/check the keys against an authority like with SSL. Most people just accept the key they're given when they first connect (I know I do).
[1] http://tools.ietf.org/html/rfc4255
http://web.monkeysphere.info/getting-started-ssh/
So I figured I'd share it here: https://news.ycombinator.com/item?id=6617132
If you want actual more protection run a bogus SSH (with no login allowed) on 22 and a thousand unused ports... then they have to try them all or guess which port is actually able to log in.
You are right that it doesn't protect from a targeted attack. In my experience (10 years as a sysadmin and dev), I've never had a targeted attack -- all the attempts against my machines are drive by.
Having port 22 open can end my IPs on a list of "let's try to break later".
It's not close to a complete solution, but I find it beneficial.
I think the recent NSA news indicate that the SSL authority model is broken. Any 3rd party authority can be subverted by legal (e.g. NSL) means.
SSH's model leaves that only semi-solved. you CAN distribute your own "known_hosts" file, thereby avoiding the need for either an SSL-style authority, or remembering every host's key. Alternatively, you can use something like SSHFP+DNSSEC/DNSCurve or Monkeysphere if you like the underlying trust models.
ssh's key model is NOT broken. SSL's models IS practically broken. ssh just leaves a little less specified.
http://blog.habets.pp.se/2011/07/OpenSSH-certificates
Everyone who's expecting to see HTTPS will see it on :443 as well.
The solution I'm particularly fond of is mentioned in Daniel's blog comments, which is to use iptables to block externalip:22 and redirect a non-standard port to localhost:22.
* Because anything but the IP address of your office or VPN connection should be blocked at the firewall level for that port
You can get in a network by VPN or SSH. Yes, after that you can also log into a computer by SSH, but the question remains - why access the network by VPN instead of SSH?
So why not solve the problem with something a little more proactive like turning off password auth and go for sshkeys only. Maybe toss in something like fail2ban if you want to interrupt kiddies scanning your boxen.
That said high port ssh can be nice if you're frequently on restrictive networks and getting out on port 22 is impossible.
edit(spelling)
However, it's not hard to imagine these scanners have moved further past the days of the Morris worm and aren't just simple port scanners. Identifying what services are on what ports is a relatively easy process that doesn't remove much from the discovery phase of a bot or script kiddie. Hell, code review metasploit for a half hour and rip theirs out.
What if non-targeted attack like a robot scanning all port 22 in your datacenter?
You cannot neglect the fact that there are vast amount of bots scanning only port 22 in the Internet. We know this because we have found the evidence in our OWN logs, not from those security experts always saying security through obscurity is bad and therefore we should do nothing.
Documenting and configuring it has a non-zero cost which could be spent doing something else more impactful.
I've never seen an infrastructure where there was a sufficiently advanced state of security such that obscuring the port numbers of services was the at top of the todo list.
Unless people recommending these things work for shadow organizations I've never heard of, I'm pretty sure it's something done without any kind of cost-benefit analysis.
What are the odds of a SSHd zero-day? Or, more specifically, what are the odds that someone with zero-day knowledge would be so stupid as to decide to risk the vulnerability being discovered by others by using it in a horizontal search of all running SSHds?
Because it has to both be more likely than any other attack that could be mitigated (and port obscurity would have to be the most effective solution) with the same effort.
Pretty sure that for virtually all infrastructures, auditing that your systems are properly isolated, users and services have the least privilege possible prevent massively more probable attacks, and that firewalling services or port knocking or really anything are more effective solutions for this attack.
So just changing the SSH port will do little, but enabling port knocking would help it stay hidden.
1. https://zmap.io/zmap-talk-sec13.pdf
Basically, there are two classes of people:
1. Those who use port scanners.
2. Those who do not.
If you are being attacked by someone in class 1, then moving your port gives you absolutely no protection. Thus moving your port is only worth anything at all if the percentage of class 2 people is significant.
However, if you also consider the probability a person in each class has of actually compromising your machine, then the security looks less convincing. Yes, it might be true that 95% of people don't bother to use a port scanner, but the most competent hackers are almost certainly going to be in the 5% that do use one.
ie. 1. is targeting you specifically, 2. is bot targeting everyone
when presented with two options, thinking of those options as 50:50 is natural, but it's really more like 0.0000001:99.9999999
As a consequence, the chance of one of those 0.999999 bots invading your computer is zero, the chance of one of the 0.000001 doing the same is non-zero.
http://nmap.org/book/idlescan.html but IIRC there are more ways than this to do it.
That was my biggest reason not to bother changing the port.
Is there any real reason beyond that? (I do use fail2ban to block repeated attempts.)
In most cases the dimension is IP range - an automated process moves from IP address to IP address examining port 22 for any common vulnerabilities. Rarely do these processes check all ports. Moving your SSH deamon to a different port prevents those automated processes from then hitting your security layer on whichever port you are running.
The other dimension of attack is when an attacker is focusing on your IP address specifically. Then he probably is going to nmap your IP and discover which port(s) SSH is running on. Changing the default port for SSH doesn't help here, but this use case is far less common.
Like others have said, changing port doesn't remove the need for security measures (cert-based/passwordless login, disable root, fail2ban) but it reduces any of those even being tested in the first place when most of your attempted attacks are IP-range based.
Personally, I trust netfilter/iptables' rate limiting more.
Frankly, the problems with key security and management are much worse than are being discussed. Using only keys is fine as long as your keys are secure and you know which is which and control all access and immediately remove any key which needs to be. In a complex environment, this is extremely difficult and more prone to security breaches than password access.
Maybe that's the wrong reason, but irritation can be a decent motivator. :)
The benefit of this is that it can allow you to tunnel through an HTTP proxy (e.g., like in a corporate environment). Many HTTP proxies only allow traffic through to port 80 and port 443. The benefit of ssh on port 443 is that if the proxy is handed a CONNECT verb, it will transparently just transmit data between your client and the remote server, irrespective of what that content is. In fact, this behaviour is what makes HTTPS remain secure when going through an HTTP proxy.
You can use this to tunnel ssh through an HTTP proxy. Putty supports this out of the box, but if you're using openssh, you'll need corkscrew also.
You can always try to tunnel to an ssh server on port 22, but most proxies will hand you HTTP403 on any CONNECT request to a non-port 443.
More info at http://daniel.haxx.se/docs/sshproxy.html.
Thats not how HTTPS works, there is no HTTP proxy for 443. You are in a corporate environment where nothing is let out on port 80, except through their HTTP proxy. However, port 443 is allowed out.
> In fact, this behaviour is what makes HTTPS remain secure when going through an HTTP proxy.
That would be a MITM against https and it doenst work that way.
If you would go over the http proxy to connect to your sshd on port 443, that would be stupid as the proxy would see your connections. Its much easier and better to just connect directly without asking the proxy.
If a remote vulnerability is discovered in the server (happened in the past, don't rule it out for the future), you will be attacked, and it won't be a brute force attack to be blocked by fail2ban or similar. You can be scanned in any time, put in a database as "having ssh version x running in y port" and get ready for future use.
And if well simple port knocking could be defeated inspecting your traffic, there are variants like fwknop that are resistant to that kind of interception or replaying.
Whatever your setup is, it's better if it doesn't show up in a scan at all.
The "knock is a weak password" argument is silly - nobody suggests using only the knock, but rather to use the knock in addition to your existing auth scheme.
Probably correct. However, sshd should be the only public facing daemon that hasn't dropped root privileges immediately after binding to its privileged port.
So it should be the only daemon that can directly offer root privs to an attacker.
I say "should" because it's a big world out there and people do some bizarre and indefensible things. Sometimes merely lazy things, but the net effect is the same.
1) I don't run HTTPS on the box I SSH into
2) I might hit an overly restrictive WiFi that only allows traffic out over HTTP and HTTPS
Which is another reason why you might not want to run SSH on another port. You might not be able to reach it.
It's reasonably clear to your average net malfeasant that any host running recognizable services is going to be running sshd.
So why not do both?
Put a dummy sshd on 22/tcp, deny all auth attempts, log whatever keeps you swimming in interesting data.
Then run real sshd elsewhere, possibly filtered, possibly port knocked, and hopefully permitting key-based auth only.
I can't deny, it is a cool technique though. PortSentry is a good tool to use for just this. Anytime someone came to :22 and the machine just disappears.
b: Uhh the port number means nothing. Host keys are there for a reason... Someone does not understand the functions of SSH. http://www.snailbook.com/ <- great book
c: If you are not investigating fingerprint issues when logging in via SSH and you call yourself a sysadmin, please stop. You are going to be the reason your company ends up in the news because your shit got owned and 2,000,000 user account hashes were leaked blah blah.
d: If you are not using key based auth and you have a fly by night keystore policy. Which means you have a keystore - stop. The whole keystore for SSH shit irritates me. I cannot tell you how many times I have heard sysadmins say a that a single private key is a "best practice". It is not a best practice it is a stupid practice and really prevents you from protecting unauthorized logins on other machines for the obvious reasons.
e: The original article http://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-... Is wrong and misguided. port knocking or knockd is an obscurity measure, precisely the kind he argues against. The linked article from the OP calls this out.f: Spinning up daemons is a big deal for non-priv users? So spinning up a remotely accessible Lisp out of emacs from a screen that is running in the background is bad? Hmm, here I thought that computers were meant to be tools for humans to get work done... Sorry, background processes are part of getting shit done. Users should be able to spin up the stuff they want to spin up in the network segments they have access to without the bureaucracy of misguided fools making the jobs of others more difficult because they think spinning up a gunicorn process or a custom daemon is worse than their unpatched kernel, apache tomcat and mysql listening on a publicly accessible address. Stateful firewalls and hosts allow/deny are there for a reason.
Sorry for the snarky reply here but there are a lot of people chiming in that obviously have very little knowledge about managing *nix ops and remote access. I have pretty strong opinions about this kind of stuff. Especially the single key stupidity and not checking host fingerprints.
Are you talking about a host key, user key, what? Confused.
By replying like that you've ensured that your point won't come across - for all I know you might be technically right, but using that tone ensures that lots of people will refuse to read past the second paragraph.
If your argument is solid, that's all you need. IMHO, snark makes your point come across as bragging, and no one likes that.
You are right. I am not sorry for the snarky reply.
"By replying like that you've ensured that your point won't come across - for all I know you might be technically right, but using that tone ensures that lots of people will refuse to read past the second paragraph."
Okay.
"If your argument is solid, that's all you need. IMHO, snark makes your point come across as bragging, and no one likes that."
Okay.
Running services on non-standard ports will make the next admin that takes over this server want to track you down and smother you in your sleep.
(Actually, I appear to have stopped doing this. But it's something to consider if you are on weird networks on a regular basis.)