Slashdot Mirror
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."
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.
ZFS: because love is never having to say fsck
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.
Passwords (or any other shared secret) are not security through obscurity. http://en.wikipedia.org/wiki/Kerckhoffs%27_principle
I have come here to chew memory and kick ass... and malloc() is returning a null pointer.
Well, if you use cyphers just to shuffle the TCP ports ... plain SSH with public key authentication would work with the same level of security.
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.
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
There seems to be two reasons this might be useful:
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?
Combination - fun iPhone puzzling
The service itself is not more secure in a mathematical sense; the clock is a rather well-known "secret".
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.
If you are a competitor of these guys, simply forward people silently to one of their ports in a hidden iframe.
Bingo, permanent ban.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
Port knocking is neat, but it suffers from sniffing attacks. Anyone who can sniff the connection can determine the sequence being used. You can use something like one time passwords to make a new set of sequences each time, but then you have to calculate those sequences (one of the neat things about port knocking is that you can do it from pretty much any machine--not just one with a special client.)
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.
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.