The "security by obscurity" one-liner is one of my favorite examples of the sort of black-and-white thinking that is harmful to software engineering.
The truth is that playing defense is as much an exercise of technical design as it is economics.
Yes - if someone finds the SSH port, they have a window of opportunity, and you will be owned if you are not properly securing your server through the normal channels.
However, now they only have a small window of opportunity (say, 30 seconds). This does a few things:
- it takes time (money) to attack a target. without access to the OTP secret, randomly assigning ports dramatically increases the cost (time) of attacking you. throw in a tar pit and it's even worse. if you're not a high value target, the attacker moves on.
- now, any failed authentication attempt to your SSH server is a highly credible threat. repeat attempts are even more suspect - you are being targeted, and they probably have the OTP secret. effectively, you are able to resource your team more efficiently, because you can filter out noise.
security is not black and white. if you are a valuable enough target, someone will find a way in. defense in depth helps you manage your defense with limited resources.
I like this analysis, but I'm having a hard time seeing the advantage over port-knocking, which could also be randomized using OTP and would never reveal the SSH server to a port scan.
> The "security by obscurity" one-liner is one of my favorite examples of the sort of black-and-white thinking that is harmful to software engineering.
My primary problem with people going for "security through obscurity" is that very often there are things which are intentionally obfuscated or obscured, in such a way that the implementer thinks that their method of hiding things will provide a significant measure of security. But then all of the other more common sense security precautions that should be implemented before the obscurity are ignored.
If I had a dollar for every industrial/embedded/M2M/IOT type thing that tries to be secure through obscurity but has other gaping holes in it, once you're familiar with the technical workings of the product...
agreed - I would not deploy this as is, but the idea is interesting and I could imagine the concept being given some UX love in a different application
Except that passwords, private keys, and safe combinations cannot be guessed in 0.1 seconds the way that a port can (65k possible values and a SYN packet really isn't large). There is a line to be drawn between high-entropy secrets and using an unpredictable port number.
Ah, misunderstanding on my part. For what it's worth, it doesn't say IP address, just listening address which I just took as whatever place (IP,port tuple) it listens on, and unless one has a huge IP range (uncommon with typical setups) I can see how "people" take that to mean port changing by default if they, like me, don't read carefully enough.
Huge ranges of IPv6 addresses are extremely common, virtually no ISP can be bothered to allocate smaller blocks than a /64. The minimum allocation of addresses recommended is a /32, which is 65k addresses.
You also know they don't mean port numbers because there's no such thing as a 6-digit port number.
From tfa:
"""Imagine your SSH server only listens on an IPv6 address, and where the last 6 digits are changing every 30 seconds"""
Layering has additional costs, like requiring additional client configuration and software and (in this case) only working over IPv6.
The number one step any public‐facing SSH server should take is to switch from password auth to keys only. Anyone who’s still concerned can put it behind a WireGuard VPN. Layers typically added beyond that (like changing port, etc.) don’t even register on the security scale, so to speak.
The tweet that inspired the post mentioned port knocking which has always been rather ridiculous given those alternatives.
The search space is too enormous. Which is why you (somebody with a SSH server) should do IPv6 and then forget this other weirdness. [You should do publickey and so on, but I mean the Tosh stuff is "weirdness"]
Suppose you can write code that can try to connect to the SSH server on one million IP addresses per hour, if they respond you attempt an attack. You can try all of the servers in the entire IPv4 Internet in a few months even with a pretty naive algorithm.
But if you do this with IPv6 you won't ever finish trying addresses and indeed almost certainly won't find even one server (let alone successfully attack one) in your lifetime.
So immediately you need a more expensive attack method. Maybe you buy a supply of "passive DNS" (name -> address answers stripped of information about who asked, many big DNS providers sell this) which is not cheap and not well suited to this problem but it gets you somewhere. You pull out IPv6 addresses and try to SSH connect to them from your supplied list. This could work, but now you need to hope that your potential victims revealed themselves to you, all the juicy SSH servers in the world are invisible otherwise.
Trouble with extra layers, there's a point where it results in complexity. Which, in my experience, is more likely to be the root cause of a security problem.
I'm not saying this little demo is a disaster or anything. But for example, perhaps it requires an awareness of this scheme in an external firewall's rules, and maybe another machine pops up in the rather large IPv6 range that's now available.
At its extreme, these sorts of approaches can bring a lack of clarity which layer is providing the actual security.
I actually looked into this a few months ago and if memory serves, the last default setup authentication bypass was in something like 2003. Since then, I think the worst thing has been user enumeration. And 2003 was a very different world in terms of how much we cared about hardening, so ssh being reliable throughout all that time is really quite something.
No, the TOTP is[0] a shared-secret bitstream (like a stream cypher), which provides new randomness per use (obscurity means it relies on the attacker not knowing how it works in the first place). This is very weak security, similar to a combination lock or PIN, and should not be used in place of proper SSH crypto, but it is actual security. (The point, IIUC, is to quickly exclude drive-by attackers, so that serious/targeted attacks are higher above the noise floor.)
Except that if they know you are using this technique (e.g. from snooping traffic) then it is straightforward to bypass, either by tailgating onto a recent connection attempt (if they can snoop) or just brute forcing it (they can test the whole key space in seconds).
There must be better ways to leverage long term shared secrets, recent authentication success, etc. I'd like to see something like Signal's ratchet mechanism.
I don't know why people knock on "security by obscurity" in general, it's a great defense for many threat models that an average individual would fall under.
A lot of credential stealing viruses just look for specific folders or file names for examples, some vulnerability scanners look for specific ports, etc ...
I view it as a cost-benefit analysis between implementing security by obscurity versus actual security. If you have real security, then you don't need security by obscurity. If you have security by obscurity, you still need real security. So it's obvious which is a better ROI. That's not to say security by obscurity layered on top can't be useful, such as filtering out noise, but I think the point most people are trying to make is "this thing is not a solution to your security problem, it is a potentially dangerous distraction".
If you have real security, then you don't need security by obscurity. If you have security by obscurity, you still need real security.
If "real security" was a real thing and anybody knew how to actually do that, things like the Colonial Pipeline ransom-ware attack, etc. wouldn't happen all the time. As people have been saying since David Lightman in 1983 "Hey, I don't believe that any system is totally secure."
That's not to say security by obscurity layered on top can't be useful
I think that most people who would implement this (or similar schemes) realize exactly that, and are practicing "defense in depth". Could it be a "dangerous distraction?" Sure, in principle. But I don't see any particular reason that this would be more so than other elements of a "defense in depth" strategy.
"real security" means security that is not dependent on secrecy of implementation to remain secure. In the context of this post, it means configuring key-based access and disabling password-based access. If you do this, then the security-by-obscurity-based technique in the OP is unnecessary and redundant. Could key-based SSH access theoretically be cracked? Maybe (probably not, but let's say maybe for the sake of argument). But if so, a rotating listening address is probably no obstacle to an attacker of that caliber.
Could key-based SSH access theoretically be cracked? Maybe (probably not, but let's say maybe for the sake of argument).
Of course it could. Unless you're really going to posit that there are no bugs in any widely deployed ssh server implementations. Doesn't seem very likely to me.
Anyway... if you're being specifically targeted by a highly advanced adversary, it probably doesn't matter what you do. I tend to assume that most of us, most of the time, are not in that position, and should employ a layered, "defense in depth" strategy. Whether or not this specific technique is something worth deploying or not is an open question to me. My position is simply that we shouldn't just dismiss it out of hand without deeper consideration.
It’s because they had some security experts say it (about things like moving your open mail relay to port 7384 to ‘secures’ it) and it’s the only thing they know about security.
