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 (826165)]

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.

[JohnGrahamCumming (684871)]

Clock drift is an issue, hence the fact that three overlapping minutes are kept active at once.

Re:Neat in theorey, imho.

[egomaniac (105476)]

I saw that, but I agree with GP that this won't fly in practice. Even with NTP servers it's too easy to have your systems end up out of clock sync, so now you're blacklisted and don't know why or how to fix it.

Re:Neat in theorey, imho.

[AvitarX (172628)]

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.

[Brian Gordon (987471)]

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)

SSH implementations have defects

[tepples (727027)]

SSH is a secure protocol anyway.

Just because the SSH protocol offers security services such as authentication and privacy doesn't mean that all implementations are without defect [slashdot.org].

Re:Neat in theorey, imho.

[mr_mischief (456295)]

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.

Re:

[cowbutt (21077)]

If this is a problem, write a wrapper script that uses ntpdate to immediately set the clock from the same NTP server as the servers you're trying to connect to. Not great for multi-user machines, but should be fine for desktops and other single-user machines with a modicum of care (e.g. making sure 'make' isn't running whilst you do so...)

Re:Neat in theorey, imho.

[AndyST (910890)]

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.

[Rob_Ogilvie (872621)]

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

Re:

[spun (1352)]

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

Yes, it's called Linux on VMWare. There are workarounds, but they involve recompiling the kernel, setting boot options, and VMWare tools settings. Without the workarounds, even with ntp enabled, clocks can skew on the order of seconds every minute. I've seen systems get a minute out of whack in under ten minutes. With some settings, ntp actually makes it worse, as ntp and VMware perform dueling clock-skews.

Re:

[camperdave (969942)]

The clock drift issue is fairly easy to solve. Just make the secure machine a time server, serving its own time. The client machine first syncs to the server, then proceeds with the port hopping ssh.

Re:

[Wornstrom (920197)]

or just use tcp_wrappers...

Re:

[JohnGrahamCumming (684871)]

Your passphrase to determine the ports is pretty much what tumbler [sf.net] does.

Re:

[Sancho (17056)]

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 authenticat

"Obscurity" tag is misleading

[egomaniac (105476)]

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:

[Loibisch (964797)]

[...] and any mistake automatically blacklists you. Sounds ridiculously impractical IMHO.

Yup, anything that would potentially that easily deny me access to my own machine won't get installed.
It's all fun and games till you've locked yourself out from an only remotely accessible server...

Re:

[$RANDOMLUSER (804576)]

It's not that different a concept from Frequency hopping [wikipedia.org].

Re:

[mea37 (1201159)]

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

Re:

[russotto (537200)]

To someone without the key, frequency hopping "looks like" random noise.

No, it doesn't. It looks pretty much like you'd expect -- spikes in power more-or-less uniformly (but discretely, not continuously) distributed over some part of the spectrum.

Check this link for pictures:

http://www.metageek.net/docs/sample-recordings/video-baby-monitor [metageek.net]

Re:"Obscurity" tag is misleading

[morbiuswilters (604447)]

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.

Actually, it gets better than that...

[PRMan (959735)]

If you are a competitor of these guys, simply forward people silently to one of their ports in a hidden iframe.

Bingo, permanent ban.

Re:"Obscurity" tag is misleading

[sumdumass (711423)]

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.

More or less obscure than password encryption?

[YeeHaW_Jelte (451855)]

What exactly is the difference with password encryption? Would you say that password encryption is also security through obscurity? Because all the points you raise to argument that this works due to obscurity also apply to password encryption, IMHO.

Re:

[YeeHaW_Jelte (451855)]

All you are saying is that the obscurity in password encryption is multitudes larger than the obscurity in shimmer. This still does not change the argument that both are security through obscurity methods.

Re:

[GodfatherofSoul (174979)]

Well, this is still security through obscurity.

In that case, isn't cryptography just "security through obscurity" since the real key is buried in known iteration of numbers?

Re:"Obscurity" tag is misleading

[sumdumass (711423)]

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:

[egomaniac (105476)]

Re-read my comment. You're assuming that a single connection attempt is good enough, whereas I explicitly said that I was assuming that you'd have to reconnect.

Isn't this port knocking

[crow (16139)]

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:

[doofusclam (528746)]

I'd imagine port knocking is easier to implement, as you don't have to keep changing the port an app is listening on. You could cryptographically change the knocking sequence, which would be far easier than the solution described here.

Re:

[AndyST (910890)]

And you send UDP packets, so there's no indication from the server that the machine is even powered up unless you are successful.

Except for the missing dst host unreachable [wikipedia.org] from the last hop before the target. "Stealth"/DROP instead of "Closed"/REJECT add nothing to security. Same with not replying to pings. People listen to Steve Gibson way to often.

Re:

[Dr. Manhattan (29720)]

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

Excuse me, but I have had enough.

[Noryungi (70322)]

First came exotic ports (as if using 922 instead of 22 was security -- it just throws off scripted attacks), then port knocking, and now this ?

Whatever happened to just plain good passwords (including a little helper for good measure [fail2ban.org]), TCPWrappers, sensible firewalling and ssh private/public keys?

I could understand this type of security with more brittle services, things that can be hacked, but this is IMHO going way oervboard.

What are these passwords, kemo-sabi?

[igb (28052)]

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.

Not so smart, though.

[VincenzoRomano (881055)]

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.

Complete Waste of Time

[Chris_Jefferson (581445)]

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?

Port knocking?

[Spazmania (174582)]

And this is better than classic port-knocking how?

Interesting...

[ZonkerWilliam (953437)]

I can see a problem, if you use a sniffer and capture enough packets, should be easy enough to see encrypted session on a single port for a length of time, now add in that true randomness doesn't exist in the computer world unless using radioactive decay or some solution, it should be doable to figure out what ports are being used for the SSH connection. I agree with one reader though, this wouldn't be needed if using best practice methods for passwords, firewalls, IDS/IPS, etc.

not as good as port knocking

[vrmlguy (120854)]

There are 16 ports being listened to, so an attacker has a 1-in-16 chance of finding the correct port. Knocking, using 16 ports and just three knocks, gives an attacker a 1-in-4096 chance of getting through. If you changed the knock pattern every minute, then I could see something like this being useful, but as presented it seems less secure.

stealth

[TheSHAD0W (258774)]

The largest problem w/ the proposed system is that, even though it may make the active port difficult to find, it leaves a large footprint. The open ports may be implemented as honeypots, but if you aren't using the standard tcp stack library it doesn't inconvenience the attacker but instead tells him the target exists. Any vulnerability in the implementation can then be exploited.

I have an alternative proposal. Have a udp or icmp service where, before connecting to a tcp server port, a client must send

Re:

[JohnGrahamCumming (684871)]

Your UDP idea is implemented by tumbler [sf.net].

Distributing Cracking

[Applekid (993327)]

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. :)

Time to break out infinities

[mattr (78516)]

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:

[morbiuswilters (604447)]

Passwords (or any other shared secret) are not security through obscurity. http://en.wikipedia.org/wiki/Kerckhoffs%27_principle [wikipedia.org]

Re:

[bugs2squash (1132591)]

This will probably stop "john" trying to log in from Istanbul as he seems to try 100s of times each day, and I like the C3PO acronym - cute. So far, port knocking has also stopped 'john' and his friends.

It seems too easy to get locked out as one slip blacklists you.

I was shocked to read that even with NTP, some servers' clocks drift so far - I thought it could keep them +/- a fraction of a second worst case (ah, when reality bites)

Re:

[jmodule (609349)]

matt4077: "Passwords are security by obscurity, too."

No, no, no! A password is a *key* and has nothing to do with obscurity. The quote you refer to is using obscurity to mean enhancing an algorithm by "keeping its process a secret." That is not the case here.

See Security through obsecurity is no security [blogspot.com] and Security through obscurity [wikipedia.org]

Re:

[matt4077 (581118)]

I know that idea, I just don't agree with it. When I say "it's obscurity, too" I don't mean that it makes sense to rely on keeping your algorithms secret. It's obviously better to make the key/password the secret, or obscure, part of the system, because it's much easier to change. The wikipedia article above actually says something to that effect. These semantics do make a difference though when a new idea is shot down by the common "that's security by obscurity" argument. If the secret has all the propert

Re:

[bobintetley (643462)]

You've just reinvented Port knocking [wikipedia.org]. And why bother encoding the reply IP in the payload? The packets themselves have the reply IP on and if the idea is that your payload is encrypted verification for the IP, that'd be a real pain in the arse if you're ISP allocates dynamic addresses - just use public key auth for your SSH endpoint when it uncloaks instead.

Re:

[JohnGrahamCumming (684871)]

Correct. But, if you examine the implementation the counter is actually incremented enough times to get 16 distinct ports overcoming the fact that AES might provide a duplicate port or two along the way.

Re:Newbie Question about SSH Security ...

[KillerBob (217953)]

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.