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

Neat in theorey, imho.

[c0l0]

Sounds like a neat hack indeed - however, I doubt its practical feasibility.

I manage quite a bunch of remote systems, each one equipped with OpenSSH for adminning and OpenNTP for syncing system clocks, yet their local clocks still drift a little over time; sometimes easily up to quarter a minute or more. So if the interval of changing ports is too narrow, one would eventually lock himself out of the remote system because of unsynced clocks and a wrongly computed destination port. Sucks big time.

... rubbing the crytsal ball even more, I can forsee that if VMWare doesn't fix its abhorrent clockskew problems on Linux guests, and the hype^Wtrend towards virtualization continues, it's going to be a real mess for anyone who's willing to try such a setup in said virtualized environments - though I'll save that rant for a more fitting time, I guess ;)

At the end of the day, choosing some non-standard port in the 30000+-range for sshd (mostly to save logrotate some work by keeping futile scriptkiddie-login-attempts out, but anyway) and turning off password-authentification in favour of pubkeys still provides enough security for just about anybody. Services that don't allow for such measures may be tunnelled over SSH (or e. g. OpenVPN, for more demanding protocols/apps) with ease, again rendering the project's idea somewhat moot to me.

Re:Neat in theorey, imho.

[AndyST]

OpenNTP for syncing system clocks, yet their local clocks still drift a little over time; sometimes easily up to quarter a minute or more. Okay two things most people don't get when ntp is involved.

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.

Re:Neat in theorey, imho.

[AvitarX]

Perhaps a port knocking pattern on a separate set of ports that are never used otherwise.

It should theoretically be impossible to snoop the port not (by virtue of it not being used), but it will be there if and when it is needed.

You could even have it as a seperate 24 hour updating set, long enough that no one should fail it, but still makes snooping it fairly useless.

Of course with up to 3 minutes to used snooped port pattern it is not completely invisible.

If security was super high, and there were a limited number of people needing to access, you could have the login give you an 8 digit code and you would enter that into the client next connection, and it would use that to pick the ports to knock. This would make it impossible to access SSH even after snooping an exchange.

It could also wait 3 minutes before allowing another connection, in the interim running a daemon that accepted and login and spit out "please wait 3 minutes" instead of a real prompt.

Re:Neat in theorey, imho.

[Rob_Ogilvie]

If your ntp-enabled systems are drifting 15 seconds out of whack with each other, you have bigger problems than additional SSH security.

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.

"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

[morbiuswilters]

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.

Re:"Obscurity" tag is misleading

[sumdumass]

Well, this is still security through obscurity. You are in essence hiding a port within many and then attempting to enforce rules based on the many. the problem with security through obscurity is that if the hacker gets lucky then nothing is secure again.

So to keep this in the same context of the article, what if the hacker picks the correct port right off the bat? No black listing, no honey pot, no security other then what was already there without the system. but better yet, what if there was 1000 ports operated in this manor, Could I effectively find the right port by using 1000 zombie machines to connect and then see the response on a second connect attempt to see when the blacklisting comes about? I'm willing to bet that the first connection that survived the longest without black listing is the correct port. So now I can attempt to exploit the server on that port to gain access.

I would think it adds a level of security and might stop the average script kiddie but I'm not sure that it is a level of security beyond the equivilent of security through obscurity.

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.

What are these passwords, kemo-sabi?

[igb]

Surely passwords are the wrong answer. I carry the contents of .ssh from my office machine on a tiny USB thingie from pqi. Very handy when I was at my father in law's last month. I also have Windows binaries of ssh on it. Mount the USB disk, use the id_dsa file from it as my key, job done. Yes, a keystroke logger will get my passphrase, but won't get the key. A very targeted attack would be needed. If I were worried about that, I'd tie our SSH listener into our SecureID infrastructure, but that seems a bit keen.

Re:Newbie Question about SSH Security ...

[KillerBob]

The only truly secure method is to make it terminal access only and accessible only by passcard or some other physical means. (IOW, to turn SSH off) Not exactly feasible for something you want to access remotely.

Passkeys can be relatively secure, or they can be relatively insecure. It depends on the level of security you're implementing in them. Another really easy way to secure it is to make it more trouble than it's worth to break into it. I have my SSH on the standard port of 22 on my server, and am not worried about security at all. I subscribe to the mailing list and it's kept up to date every time a new release comes out. More importantly, my SSH server is configured to only allow one user ID to log in, and to only allow one password attempt before disconnecting. It also doesn't disconnect until after you've entered the password, and will give the same error message no matter what, so you've got no way of knowing why it is that you're not getting through. Finally, the user name in particular that's allowed to log in through SSH doesn't have an e-mail account or home directory, and isn't published anywhere.

No, that isn't going to secure it entirely. It is, however, going to make breaking into it incredibly time consuming and generally not worth it unless you have a personal vendetta or other reason to go after me specifically. Security through obscurity. In this case, get away from Default Pass, and towards Default Reject security model.