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."
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.
1. An ntpd not only syncs time, but adjusts the running speed of the kernel clock. Otherwise it would be nothing more than a ntpdate cronjob.
2. Under GNU/Linux, the local clock may be used to initialize the kernel clock, but those two run independently of each other until shutdown (or manual set). Only then the local clock is set to the kernel time, regardless of what the local clock was doing all the time.
Actually, it seems possible to lock out legitimate users as well, by sending them to a URL like http://example.com:12345/ Since it only appears to be operating at the TCP layer, requests from a web browser would accomplish the goal of blacklisting a target IP. If port 12345 was one of the honeypots at that time, the legitimate user gets blacklisted. Throw it on a malicious web page that uses several XMLHttpRequests to try various ports and you have a pretty good shot at locking the user out.
I have come here to chew memory and kick ass... and malloc() is returning a null pointer.
If your ntp-enabled systems are drifting 15 seconds out of whack with each other, you have bigger problems than additional SSH security.
Rob
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.