Cryptographically Hiding TCP Ports

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."

Comments

"Obscurity" tag is misleading

[egomaniac]

I see this got tagged "obscurity", but this isn't security-through-obscurity. If you actually RTFA, you'll see that hooking up to the wrong port automatically blacklists you. So it's not like you can just try different ports until you find the right one -- any attacker without the shared secret will almost immediately be blacklisted, assuming that they have to reconnect a few times (e.g. to try different SSH passwords).

Still, requires a shared secret plus synchronized clocks, and any mistake automatically blacklists you. Sounds ridiculously impractical IMHO.

Re:"Obscurity" tag is misleading

[sumdumass]

I'm not saying that it wouldn't add a layer of security. But as I understand it, It seems that I could stumble onto the right port in the first place and hack my way in using zombies or not. The key only points you to the right port and then you validate. This is like placing 500 ignition keys to a car in a fish bowl and telling someone they win the car they can pick one key and start the car. So if I was to pick the right port then validate or hack my way in without validating, the security did nothing. The only real security is the random chance I wouldn't find the right port/car key and whatever is normally there to stop my entry. The security key is more or less just convenience so that i can find the right port the first time.

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

[mea37]

There are substantial differences. Enough so that, while the sound similar, they are really nothing alike.

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.

Isn't this port knocking

[crow]

Isn't this essentially the same as port knocking? Actually, it's not as good, as you can get lucky with this. With port knocking, you have to send a secret sequence of packets (possibly one that changes with time) before the port is available for your host to connect to. And you send UDP packets, so there's no indication from the server that the machine is even powered up unless you are successful. And, of course, there's the variation where you send a single UDP packet with an encrypted payload that instructs the server to open up a port for you.

So while this is a little different, it's inferior.

Re:Neat in theorey, imho.

[mr_mischief]

I used to run a network with an ssh-only server. All it had facing the world as an actual service was OpenSSH's sshd on a fixed nonstandard port. It also had two fixed and four randomly hopping honeypot ports that added any /24 network that hit them to a 24-hour firewall DROP rule.

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.