Cryptographically Hiding TCP Ports 206
JohnGrahamCumming writes "The shimmer project implements a cryptographically-based system for hiding important (e.g. SSH) open ports in plain sight. By automatically forwarding from a range of ports all but one of which are honeypots and by changing the ports every minute only a user knowing a shared secret can determine the location of the real SSH server."
"Obscurity" tag is misleading (Score:5, Insightful)
Still, requires a shared secret plus synchronized clocks, and any mistake automatically blacklists you. Sounds ridiculously impractical IMHO.
Isn't this port knocking (Score:5, Insightful)
So while this is a little different, it's inferior.
Re:Obscurity? (Score:2, Insightful)
Not so smart, though. (Score:3, Insightful)
In both cases you need to keep a crypto key secret otherwise you'll end with secuity hole. A shuffled one, but still a hole.
Complete Waste of Time (Score:3, Insightful)
1) Another piece of information needed
2) If your SSH server has a buffer overflow or similar in it.
And both seem useless.
1) You are surely going to keep your SSH key in the same place as the code to access this thing. If you wanted a similar level of security, why not hide your SSH key in two pieces?
2) Now we have to completely test two programs instead of one.
Seriously, what security problem is this supposed to fix?
Fascinating (Score:1, Insightful)
It does however provide a degree of hardening for the *daemon that provides the service*, by reducing its surface area. This is worthwhile to investigate, but automatic blacklisting is problematic. If all of your services depend on the accuracy of the local time server, you now have a single point of failure for every service hardened in this way.
Maybe not quite ready for production environments, but a fascinating idea that has great potential.
Re:"Obscurity" tag is misleading (Score:4, Insightful)
Now if I am not understanding something correctly and you need the key to even get access to a/the port then I am wrong. I mean if the ports are all blocked and the key opens them for you to attempt authentification? But as I understand it, the port it already there and exposed along with numerous fake ports, you just don't know which one it is without the key and that is obscurity.
If this is how I am thinking, then combining it with something like port knocking where the ports aren't even available until another challenge succeeds might make it better.
Re:"Obscurity" tag is misleading (Score:3, Insightful)
Frequency hopping has a much broader domain to "hop" across.
Frequency hopping requires the communication to keep hopping even after it's established. Not only can't you connect without the key, you can't even keep a conversation going without the key. You can't hear or be heard at all, in fact.
To someone without the key, frequency hopping "looks like" random noise. This works becuse there is random noise on the RF spectrum for the FH signal to "look like". There is no such "noise' in the domain of IP port connections.
Actually, it gets better than that... (Score:3, Insightful)
If you are a competitor of these guys, simply forward people silently to one of their ports in a hidden iframe.
Bingo, permanent ban.
Re:Neat in theorey, imho. (Score:3, Insightful)
Honestly, people spend way too much time worrying about hiding their SSH ports. Use public key authentication and disable password authentication, and no one's going to brute-force their way in.
SSH implementations have defects (Score:3, Insightful)
Re:Neat in theorey, imho. (Score:5, Insightful)
Once someone logged into that server using their own key or pass phrase, the only command they could run was ssh. All the other servers in the network only allowed ssh in from that ssh box, and by policy their keys and pass phrases had to be different on the ssh server than on the internal boxes. Each failed attempt at logging in caused a 5-second wait, and after three a 12-hour wait.
Is it as secure as having the real port hop around and synchronizing that with the clients via a shared secret? Well, I guess that depends on just how secret the shared secret is. We never had any problems, though, and the only thing our people had to take with them were the name of the server, their private key or passphrase, and the proper port to use. They usually didn't have much problem remembering three of those, and the you have the same issue with private keys no matter what (that being that they're only as secure as the system on which they are stored).
There's probably some security advantage to the solution presented in TFA, but I'm just not sure it's worth the extra coordination hassle compared to people's home-grown solutions. It seems like every fifth post in the comments is about alternative ways to safeguard ssh ports. Surely not knowing which someone is using provides a bigger hurdle than getting past any single one of them. When you're practicing security by obscurity, which is what this really boils down to, then being more obscure is probably a good thing.
The best fix for brute force is the old idea you mention of an enforced wait between attempts. It's a pain when you're locked out of a server you're legitimately allowed to use, but it's very useful to keep brute-force attacks down. Giving a couple of chances with a short wait and then imposing a much longer once after 2 to 5 tries seems to be a pretty good balance.
Re:"Obscurity" tag is misleading (Score:3, Insightful)
Well, this is still security through obscurity.
In that case, isn't cryptography just "security through obscurity" since the real key is buried in known iteration of numbers?