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

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:"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/ [example.com] 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.

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:Isn't this port knocking

[Dr. Manhattan]

I did something a lot simpler, using TCP/IP, and much easier on CPU requirements. (I use it on a 16MHz M68K machine.) See the link in my .sig...

Distributing Cracking

[Applekid]

This approach pretty much assumes that the brute-force attack wouldn't be happening from many different computers on many different IP addresses each attacking an individual port. If we're talking 1 port in 30000 then all you need is a botnet at least as large as 30000 machines. All except one will waste time with their respective honeypots but one will be getting the job done.

I wonder if the DDoS would bring the server to its knees first, though. :)

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:Neat in theorey, imho.

[Brian Gordon]

I don't know, I don't like this at all. It's obviously abuse of TCP/IP, and there's no reason to try to mask what port it's on when SSH is a secure protocol anyway. Also I have my doubts that many OSes TCP/IP stacks can handle so many transient connections, or that it would be implementable at all (cough windows)

DenyHosts SSH script

[HumanCarbonUnit]

This is indeed a nifty hack, however it seems a bit impractical and overly complicated way of protecting SSH.

I use the software script Denyhosts which runs whenever an SSH connection comes into the system
http://denyhosts.sourceforge.net/

You simply set the Account / IP address lockout threshold and so after X number of failed login attempts the system will put the connections source IP address into the hosts.deny file. The IP address stays there until eventually released, or it can stay there forever.

Thus its easy for me to share the login with friends so they can SSH and SFTP into the system and any / all attempts to guess or force a login are blocked after the threshold is reached.

Time to break out infinities

[mattr]

This may sound like tongue in cheek but I assure you I'm serious.

Clearly some aspects of computers not as sexy as high speed graphics lag behind, as some examples the number of bots, the number of ports, the number of concurrent connections (10K problem) and the data transfer speeds possible by consumer hardware, especially when divided by storage media size, all seem to be relatively small numbers still. A ton of bots can game this game, etc.

Obviously it is time to break out the heavy math. First imagine if instead of having only measly thousands of ports you could use a floating point number to designate a port. It's not like we have thousands of ports in hardware right? Meaning virtual port addressing. Needs a big botnet to get through that. You could make the system answer on any port, or only answer on those which are being used. Well floating point still may not have a lot of significant bits to hack, so time to break out the math.

I think Rudy Rucker could have some good ideas for computer security. Not that I'm a mathematician or anything, but if you read his latest book minus 1 there are plenty of descriptions of navigating infinities. If you had a transfinite number of ports I think you might even be able to prove that the obscurity is more secure than anything else in the real world. So while it is a bit of a ticklish idea I'd very much like to see a math-minded hacker think about what would be involved in designating such a number or abstract symbol representing it and using that as a destination address. Thank you.

Re:Neat in theorey, imho.

[Anonymous Coward]

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.

pam_abl http://sourceforge.net/projects/pam-abl/ [sourceforge.net] and let them try ;)

Use a different network to delete blocks

[ccguy]

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.

Add to this a nokia phone and a data cable, gnokii, and a script that when it receives a SMS from a specific phone number with an IP address in the text unblocks it, and you are set. That's what I use and it works pretty well, if I screw up it just costs me a few cents to get back to normal. In fact my (quite trivial) script can do a few other things as well as opening ssh to a particular IP (such as rebooting).