Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Cryptographically Hiding TCP Ports

CmdrTaco posted more than 6 years ago | from the can't-see-the-ones-for-the-zeros dept.

Encryption 206

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

cancel ×

206 comments

Sorry! There are no comments related to the filter you selected.

Neat in theorey, imho. (4, Interesting)

c0l0 (826165) | more than 6 years ago | (#21954142)

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. (3, Informative)

JohnGrahamCumming (684871) | more than 6 years ago | (#21954160)

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

Re:Neat in theorey, imho. (3, Informative)

egomaniac (105476) | more than 6 years ago | (#21954204)

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. (4, Interesting)

AvitarX (172628) | more than 6 years ago | (#21954428)

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. (3, Interesting)

Brian Gordon (987471) | more than 6 years ago | (#21955288)

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 (2, Insightful)

tepples (727027) | more than 6 years ago | (#21955852)

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. (1)

nacturation (646836) | more than 6 years ago | (#21955884)

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.
Or you could use public key authentication for your SSH security rather than just passwords. I have a 1 in 10^8 chance of guessing your 8 digit code. You have a 1 in 2^1024 (often less) chance of guessing the correct private key. Combine that with blocking brute force attacks [bgnett.no] and that's all the security you practically need.
 

Re:Neat in theorey, imho. (1)

cowbutt (21077) | more than 6 years ago | (#21954986)

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. (1)

Midnight Thunder (17205) | more than 6 years ago | (#21955198)

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

But if you have ever used one of those RSA generators you will find that it will sometimes take three or four attempts before connecting to your VPN. This is even with the valid pass-key.

Sometimes being too smart is the wrong answer.

Re:Neat in theorey, imho. (1)

morbiuswilters (604447) | more than 6 years ago | (#21954198)

I agree that it's pretty nifty, but seems like a lot of work that is more failure prone than just using a firewall to exclude invalid IPs.

Re:Neat in theorey, imho. (1)

Wornstrom (920197) | more than 6 years ago | (#21954980)

or just use tcp_wrappers...

Re:Neat in theorey, imho. (5, Interesting)

AndyST (910890) | more than 6 years ago | (#21954268)

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. (1)

Anonymous Coward | more than 6 years ago | (#21955196)

By 'local clock' do you mean the machine's clock, which displays the time in the BIOS menus?

I have 20 Dell Poweredge 1950 machines. The time drifts by several minutes each day. I'm trying to figure out if my system's time is drifting due to the machine, or due to a Linux issue.

Re:Neat in theorey, imho. (0)

Anonymous Coward | more than 6 years ago | (#21954432)

... 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 ;)
Try booting the kernel with notsc, this will fix your timeskew issue.

Re:Neat in theorey, imho. (5, Funny)

Rob_Ogilvie (872621) | more than 6 years ago | (#21954474)

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. (1)

jandrese (485) | more than 6 years ago | (#21955492)

IMHO, this is a problem with NTP. It's really hard to figure out if it's working or not and the documentation is obtuse and spends page after page going on about security features nobody wants to deal with (it's hard enough to get NTP working without the security stuff). While I admire the difficulty in getting clocks synchronized down to the picosecond over the internet, some work on the UI would be greatly appreciated.

Re:Neat in theorey, imho. (0)

Anonymous Coward | more than 6 years ago | (#21954596)

Cant you use OpenNTP on one server to get the proper time & get all the others to use that server? I realise this might not be as fault tolerant as other solutions but if your clocks are out by up to a minute, I'd think missing a few time updates isn't that important anyway.

Re:Neat in theorey, imho. (1)

thatseattleguy (897282) | more than 6 years ago | (#21954712)

There are programmatic ways to mitigate the clock-skew problem. To give just one example off the top of my head, if the remote user attempts to connect to the port just "behind" (in time+crypto sequence) or just "ahead" of the current "correct" port, they could get a waiver - not a full connection, but not an autoblacklist, either. That wouldn't necessarily solve the problem completely, but would allow other opportunities/methods of authenticated assuming that both ends can recognize at that point that there's a clock-skew issue. (details left to the reader and implementer on that)

I believe that SecureID and other systems that require a token produced by a crypto device implement something like this, where there's a "greylist" to allow semi-synced remote users another shot at authenticating.

Re:Neat in theorey, imho. (1)

BuckaBooBob (635108) | more than 6 years ago | (#21954850)

Port Knocking is the way to go. With no ports answering alot of the Port Scan "Network Spam" would go away.. They should stop trying to invent a new wheel for everyone to ride and focus on a way to use a passphrase to determine what ports should be probed in what order with what time span. Leaving ports open Just encourages hackers to continue to probe your machine. Honeypots or no..

Re:Neat in theorey, imho. (1)

JohnGrahamCumming (684871) | more than 6 years ago | (#21955014)

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

Re:Neat in theorey, imho. (2, Insightful)

Sancho (17056) | more than 6 years ago | (#21955230)

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.

Re:Neat in theorey, imho. (1)

cream wobbly (1102689) | more than 6 years ago | (#21954862)

No, I don't believe you're running NTP correctly.

Re:Neat in theorey, imho. (1)

camperdave (969942) | more than 6 years ago | (#21955104)

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.

fp (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#21954156)

First thei steal your idears and then they call you a troll! Excellent karma whoring!

"Every Which Way but Loose" by Eddie Rabbit (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21954504)

I've always been the kind of man who doesn't believe in strings
Long term obligations are just unnecessary things
But girl you've got me thinkin', while I'm drinking one more beer
If I'm headed for a heartache, then why the hell am I still here

I'm testin' my resistance and its wearin' mighty thin
I got the feelin' I should leave before the roof caves in
My mind tells me to move along but my body begs me stay
And now I feel the need to hold you close and love the night away

Chorus:

While you're turnin' me
Every which way but loose
You turn me every which way but loose
Inside the fire's burnin' me
In mind you just keep turnin' me
Every which way but loose
Baby there's no excuse
To turn me every which way but loose

When the sun comes up in the mornin' it should find me someplace new
But right this minute all I want is to lay here next to you
Those memories still keep callin' me from somewhere in my past
Better hurry if they want me cause I can feel me fading fast

"Obscurity" tag is misleading (4, Insightful)

egomaniac (105476) | more than 6 years ago | (#21954172)

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 (2, Informative)

Loibisch (964797) | more than 6 years ago | (#21954264)

[...] 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:"Obscurity" tag is misleading (1)

$RANDOMLUSER (804576) | more than 6 years ago | (#21954294)

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

Re:"Obscurity" tag is misleading (3, Insightful)

mea37 (1201159) | more than 6 years ago | (#21954680)

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 noise on the RF spectrum for the FH signal to "look like". There is no such "noise' in the domain of IP port connections.

Re:"Obscurity" tag is misleading (5, Interesting)

morbiuswilters (604447) | more than 6 years ago | (#21954298)

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... (2, Insightful)

PRMan (959735) | more than 6 years ago | (#21954914)

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 (4, Interesting)

sumdumass (711423) | more than 6 years ago | (#21954300)

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:"Obscurity" tag is misleading (1)

morbiuswilters (604447) | more than 6 years ago | (#21954348)

That's still not security through obscurity because it requires a shared secret to work. The method for determining the next port is not completely encoded in the algorithm, but instead is dependent on an external key. Using zombie machines would be little more than brute forcing the key, although the relatively small number of TCP ports results in a very short key length.

Re:"Obscurity" tag is misleading (1)

mea37 (1201159) | more than 6 years ago | (#21954604)

Nope. The key is what tells you what port to connect to. I can connect to the right port by brute force, never discovering the key. In other words, I can circumvent the true shared secret. (By "true shared secret", I mean the only "secret" that has any level of associated security. "I'm thinking of a number from 1 to 10" isn't a shared secret in any useful sense of the term.)

Re:"Obscurity" tag is misleading (3, Insightful)

sumdumass (711423) | more than 6 years ago | (#21954656)

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.

More or less obscure than password encryption? (1)

YeeHaW_Jelte (451855) | more than 6 years ago | (#21954482)

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:More or less obscure than password encryption? (1)

mea37 (1201159) | more than 6 years ago | (#21954552)

There are 16 possible ports; I can try all of them independently. The blacklisting tries to block brute force, but it won't work against a hacker who knows what's going on (which is why this is security through obscurity).

In any good password scheme, there are at least billions of possible passwords. Even so, passwords are not as good as dual-key schemes, which have even more possiblilities.

The analysis is completely different for shimmer vs. password-based authentication.

Re:More or less obscure than password encryption? (1)

YeeHaW_Jelte (451855) | more than 6 years ago | (#21954674)

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:More or less obscure than password encryption? (1)

mea37 (1201159) | more than 6 years ago | (#21954710)

Well, the experts in cryptography say it is different, but suit yourself.

Re:More or less obscure than password encryption? (1)

Sancho (17056) | more than 6 years ago | (#21955482)

Generally speaking, security through obscurity means that knowing the inner workings of the security system gives a hacker enough information to let said hacker in without much trouble. The common example is a case where knowing the algorithm is enough to let you in--if the hacker knows the algorithm, either through a corporate leak or by reverse engineering the software, then the system is said to be using security through obscurity.

Non-obscurity based security systems often have open algorithms--the user has a secret of some sort which he uses to authenticate himself to the system. It's perfectly true that the secret could be guessed or compromised, but this is true of nearly every security system on Earth. The simple point is that the system isn't relying on secrecy of the workings of the system itself.

It's entirely possible for a system which relies on security through obscurity to be more secure than an open system which relies on a secret. A black box with a chip and leads sealed in epoxy is unlikely to be hacked. A password system which requires that passwords be dictionary words will be hacked rather quickly. Yet the former is still security through obscurity (albeit with a layer of physical security which makes it harder to find the obscure component), and the latter still relies only on a mapping of a username and a secret.

The system described in the article really straddles the line, but not because the port is easily guessed. The obscurity portion of the system is in the fact that a single, shared secret is used (a secret which might be leaked and compromising the security of the whole system.) Shared secrets are fine when used to salt an actual authentication secret, but they're only barely better than worthless when used as the sole authenticator for a particular layer of your security model.

Frankly, the person who came up with this system was probably trying to avoid the rampant SSH brute-force attacks which clutter up all of our logs. There are much better ways of handling this, in my opinion.

Re:More or less obscure than password encryption? (1)

kkwst2 (992504) | more than 6 years ago | (#21955834)

I would argue that neither are. Security through obscurity is more an idea than a design principle. It's talking about ways to get around the security OTHER THAN the encryption key (password). The encryption key can be strong or weak, but it's not usually considered security through obscurity. Having several backdoors and hoping that nobody finds out about them would be security through obscurity, the obscurity being the "secret" backdoors. For shimmer, it would be whether there is some other way to guess/figure out the open port other than having the sequence algorithm. The idea itself isn't really security through obscurity.

Re:"Obscurity" tag is misleading (1)

mea37 (1201159) | more than 6 years ago | (#21954464)

I'm not too sure about that.

Ok, if it's not security through obscurity, then the attacker is allowed to know everything but the shared secret (i.e. doesn't know how to determine the correct port). We're testing for added security, so any authentication built in to the underlying service doesn't count (unless it interacts with Shimmer in a way that creates even more security than the sum of the parts; but I assert that it doesn't).

So the attacker knows that there are 3 sets of 16 ports. He knows what ports are in each set and when each set became active and when it will expire. He knows that one port from each set is good, and the other 15 are bad; but he doesn't know which one.

So what are you going to do if your attacker has access to 16 IP addresses on 16 different networks? Hackers have been known to arrange that kind of thing. So I run 16 parallel attempts to connect, and 15 of them get blacklisted. I still win.

Alternately: What are you going to do if the attacker is in a position to watch traffic to and from your box for a while? It would be pretty easy to find the real port if you could watch connections by legitimate users.

Looks to me like it is, indeed, security through obscurity.

Re:"Obscurity" tag is misleading (1)

egomaniac (105476) | more than 6 years ago | (#21954568)

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.

Re:"Obscurity" tag is misleading (1)

mea37 (1201159) | more than 6 years ago | (#21954758)

Re-read my post. I'm making no such assumption.

Re:"Obscurity" tag is misleading (1)

morbiuswilters (604447) | more than 6 years ago | (#21955438)

Yes, this is a horrible, insecure idea but it is still not security through obscurity. Having access to the source code and algorithm does not allow you to guess the port any more easily than by brute force (assuming there are no flaws in the cryptographic method used to determine the port). The small number of ports makes brute forcing easy, but that still does not make this security through obscurity. Short passwords are also insecure, but that doesn't change the cryptographic strength of the underlying authentication mechanism. The ports can be sniffed, but so can any plaintext password, which is precisely why the proposed idea is about as stupid as sending unhashed, 3 letter passwords over the wire. Security through obscurity means that an attempt at security has been embedded in the algorithm itself and not in the key, which is not the case here. Please read up on Kerckhoff's principle. [wikipedia.org]

Re:"Obscurity" tag is misleading (1)

DomerMike (1215392) | more than 6 years ago | (#21955298)

Actually, the blacklist isn't really an effective solution to the scanning problem, given the proliferation of botnets. All I'd need is a botnet consisting of 65,535 hosts to scan every TCP port on your system in a distributed fashion. Not an unusual size nowadays.

Isn't this port knocking (5, Insightful)

crow (16139) | more than 6 years ago | (#21954202)

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

doofusclam (528746) | more than 6 years ago | (#21954278)

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:Isn't this port knocking (2, Informative)

AndyST (910890) | more than 6 years ago | (#21954390)

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

Anonymous Coward | more than 6 years ago | (#21954790)

in the real world there's a bunch of routers and other network devices that don't send correct ICMP or even at all; the friendly ol' internet where all hosts are nice to each other is long dead, hoss..

Re:Isn't this port knocking (2, Interesting)

Dr. Manhattan (29720) | more than 6 years ago | (#21954840)

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

Re:Isn't this port knocking (1)

caluml (551744) | more than 6 years ago | (#21955854)

I suspect that the vast percentage of viewers to this site are Anonymous/not logged in, and hence can't see your sig. So here's the link: SSH not secure enough? Try Ostiary [homeunix.net] .

Re:Isn't this port knocking (0)

dave420 (699308) | more than 6 years ago | (#21955140)

You get blacklisted if you try an incorrect port, so getting lucky is pretty impossible.

Re:Isn't this port knocking (0)

Anonymous Coward | more than 6 years ago | (#21955558)

You get blacklisted if you try an incorrect port, so getting lucky is statistically improbable.

Fixed that for you. Personally, I like my security schemes to be deterministic.

Obscurity? (0)

matt4077 (581118) | more than 6 years ago | (#21954238)

Passwords are security by obscurity, too. It's just that the obscurity is neatly focused on a single point and can easily be changed. This scheme is quite like that, actually. But ssh+strong passwords is easier to setup and can be used for honeypots equally well. This only protects against remote exploits, which (as far as we know) don't happen too often.

Re:Obscurity? (0)

Anonymous Coward | more than 6 years ago | (#21954446)

Open ports are no hazard to security if the server is well programmed. It will be fun to find the Obfuscated port, but if the server is weak it will fall all the same. Security is only as strong as the weakest link. In this case the weakest link being, as often is the case, the administrator.

Re:Obscurity? (2, Informative)

bugs2squash (1132591) | more than 6 years ago | (#21954536)

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:Obscurity? (2, Informative)

jmodule (609349) | more than 6 years ago | (#21954538)

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:Obscurity? (1)

matt4077 (581118) | more than 6 years ago | (#21955072)

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 properties of a password it's equally well suited. Using ports, such as in this case, is an example (though with some differences: ports are easy to try/guess so you need blacklisting).

Re:Obscurity? (1)

morbiuswilters (604447) | more than 6 years ago | (#21955554)

Then you are incorrect. You are splitting hairs with your definition and missing the real point that embedding secrets in the algorithm is not secure. The "that's security by obscurity" argument is a completely valid one to make, assuming the proposed idea really meets the criteria. That doesn't appear to be the case here, even though the proposal does suffer from an extremely small keyspace and requires sending a plaintext key across the wire. So it is insecure, but it fails the obscurity argument. Still, the very definition of "security through obscurity" is embedding secrets in the process and not the key and you can't just disagree with the definition of a term you had no part in defining.

Re:Obscurity? (1)

Sancho (17056) | more than 6 years ago | (#21955744)

This secret doesn't have all of the properties of a password, though.

At the very least, it's shared. This makes it unsuitable for use on a multi-user system, but if that's ok with you, then fine. It also, ultimately, hashes down to a pretty small set of values (ports). All this to ... what? Prevent logs from being filled with failed connection attempts? Protect your server against brute-force attacks? There are better ways to handle both of these problems.

Excuse me, but I have had enough. (1)

Noryungi (70322) | more than 6 years ago | (#21954410)

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.

Re:Excuse me, but I have had enough. (1)

mathimus1863 (1120437) | more than 6 years ago | (#21954708)

I agree, this is overboard. But it is feasible. The time syncronization is not a huge issue: the same program which executes this type of secure protocol can easily keep track of the time syncronization issues since it will have access to both clocks when logged in.

For instance, if the interval is changed every minute, and the connection is used at least once a month, the syncronization state can be tracked pretty reliably. Even if the connection is only opened once per year, it could easily allow 2-4 failed attempts to allow for mis-syncronizations.

What are these passwords, kemo-sabi? (4, Interesting)

igb (28052) | more than 6 years ago | (#21955124)

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:Excuse me, but I have had enough. (1)

0xABADC0DA (867955) | more than 6 years ago | (#21955238)

Passwords won't help you avoid traffic shaping and 'no server' rules from your ISP, but automatically changing port numbers and servers that no longer 'exist' when the ISP's batch process gets around to connect to them to look for 'unauthorized use' will.

Re:Excuse me, but I have had enough. (1)

Chineseyes (691744) | more than 6 years ago | (#21955764)

People use exotic ports as a security measure? I've always done it to keep my log files from becoming bloated from script kiddies attacks. When I see something out of the ordinary in my log files now I can be reasonably certain it is more serious than an automated script.

Not so smart, though. (2, Insightful)

VincenzoRomano (881055) | more than 6 years ago | (#21954424)

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.

Wierd Coninsidence (1)

fotoflo (1018618) | more than 6 years ago | (#21954436)

Oddly, Last night i came up with a new way of doing this, and today this appears on slashdot. Here is my idea: UDP packets are are sent in a specified order to specified ports, this scheme can come from some kind of private key. The packets contain a signature file, which may be divided into several segments, each one containing the reply IP. After the sequence is complete, the SSL port uncloaks on a specified port.

Re:Wierd Coninsidence (1)

bobintetley (643462) | more than 6 years ago | (#21954774)

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:Wierd Coninsidence (1)

fotoflo (1018618) | more than 6 years ago | (#21954954)

good thing i didn't start writing a prototype then, huh?

Re:Wierd Coninsidence (1)

Sancho (17056) | more than 6 years ago | (#21955812)

It's not really a private key--at least, not in the same way that SSH public/private keys are used. Generally speaking, you don't transmit your private key all over the internet when you want to use it.

Simple error in the method (0)

Anonymous Coward | more than 6 years ago | (#21954494)

The way he describes the work there is a chance it will NOT generate 16 distinct ports, since he AES encrypts 0-15 and then takes the result mod N (where N is some number of ports you wish to use) to get port assignments.

AES does not guarantee these numbers will be distinct. Minor error, but these toeholds are how methods are broken. Someone who does not understand these simple items should not be designing security protocols, IMHO.

Re:Simple error in the method (1)

JohnGrahamCumming (684871) | more than 6 years ago | (#21954970)

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.

Complete Waste of Time (2, Insightful)

Chris_Jefferson (581445) | more than 6 years ago | (#21954564)

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?

Fascinating (1, Insightful)

Anonymous Coward | more than 6 years ago | (#21954576)

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.

Re:Fascinating (1)

Sancho (17056) | more than 6 years ago | (#21955882)

Actually, one could argue that it increases the daemon's surface area. Instead of 1 port, 3 ports now forward to the listening service. Although a connection to a non-listening port will trigger a blacklist of the remote IP address, the same could be done with just one listening port.

Of course, since the port changes every minute, that gives very little time for the attacker to crack it before he has to find a new port. Nonetheless, if you're relying on this for security, it seems like a pretty bad idea. It's a lot of work to thwart a brute-force attempt, when using keys will work better.

Neat idea, but impractical.

Port knocking? (1)

Spazmania (174582) | more than 6 years ago | (#21954614)

And this is better than classic port-knocking how?

Interesting... (1)

ZonkerWilliam (953437) | more than 6 years ago | (#21954808)

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.

Re:Interesting... (1)

mea37 (1201159) | more than 6 years ago | (#21954966)

It's a little more complex than that. Say the listening ports are 1001 to 1016, and the real port is 1008. A real user connects to 1008. Fine, but he's going to disconnect from it right away anyway, because that's the daemon's listening port (which needs to be freed back up so it can keep listening). If the service is session-based, then the daemon is going to assign the session to another arbitrary port.

However, you are correct that by watching traffic you could quickly identify the "right" port. It's just a little harder than watching for long-standing connections; you have to actually watch someone connect.

Re:Interesting... (1)

morbiuswilters (604447) | more than 6 years ago | (#21955656)

You obviously have no idea how sockets work. The daemon does not close the connection nor does it need to to open accept new connections. The client IP and port and the server IP and port all combined make a unique connection.

Frequency-hopping spread spectrum (FHSS) (1)

fbonnet (756003) | more than 6 years ago | (#21954906)

It sounds close to the FHSS [wikipedia.org] technique but applied to the Internet. FHSS is often used in military applications to avoid jamming and interceptions. Here, instead of switching carriers, one has to switch ports.

not as good as port knocking (2, Informative)

vrmlguy (120854) | more than 6 years ago | (#21954952)

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.

Re:not as good as port knocking (1)

dk90406 (797452) | more than 6 years ago | (#21955412)

True.
And if you do the math: 15 decoys and one real port. Changes every minute. 15 minutes penalty.
By trying opening random ports, the chance of you hitting the right port in 11 attempts or less (2,75 hours) is approx 51%.

Neat idea, but needs improvement. Like port knocking with honeypot (blacklisting) ports.

Re:not as good as port knocking (1)

Abcd1234 (188840) | more than 6 years ago | (#21955552)

I take it it never occurred to you to just increase the number of ports and knocks? You have 64k to choose from. Go nuts.

Re:not as good as port knocking (0)

Anonymous Coward | more than 6 years ago | (#21955600)

Nice job there. I'm sure you actually read TFA. There are 48 ports being listened to.

"Since both client and server must be time synchronized to the nearest minute shimmer actual holds 48 ports open at a time (16 for the previous minute, 16 for the current minute and 16 for the next minute) to avoid problems due to small amounts of clock drift."

stealth (1)

TheSHAD0W (258774) | more than 6 years ago | (#21955004)

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 a packet containing the destination port along with a 32-bit entry code. (This entry code could be, for instance, the first 4 bytes of the SHA1 of a concatenation of a private key plus the client's IP.) Without receiving this packet the server's port would return no data on the attempted initiation of a connection, resulting in a "stealthed" server port.

Re:stealth (1)

JohnGrahamCumming (684871) | more than 6 years ago | (#21955044)

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

Why bother with aes? (1)

pimpin apollo (664314) | more than 6 years ago | (#21955034)

Maybe i'm missing something here, but the description lists the following steps

1. Get the current Unix epoch time to the nearest minute: minute
2. Get the name of the mirage being shimmered: name
3. Get the shared secret: secret
4. Calculate the SHA-256 hash of a combination of minute, name and secret to create a 256-bit Rijndael key that depends on time (changing every minute) and a shared secret: key.
5. Use key to AES encrypt the numbers 0 through 15 to obtain 16 seeds for port numbers: seeds.
6. Map each seed to a port number in the range specified for the mirage using a simple modulus operation to obtain a list of ports: ports.
7. The first port generated (corresponding to the first seed from encrypting 0) is the port that will be forwarded, the other 15 are traps.

Why are steps 4 and 5 required? Why not simply use 0-15 numbers as salts to the hash described in 4.

The only thing that seems useful is a concern that the SHA hash appears less random than the AES ciphertext. First, I'm fairly sure that such an attack is not publicly known (see comments to linux /dev/random char device), and second, the hash sets the key anyway. In any event, it seems unnecessary to go through these steps to randomize two bytes.

Re:Why bother with aes? (1)

JohnGrahamCumming (684871) | more than 6 years ago | (#21955180)

It's true. I could have used the hash as a CPRNG all by itself, but I thought the implementation with a block cipher was clearer.

Re:Why bother with aes? (1)

gravy.jones (969410) | more than 6 years ago | (#21955456)

Step 4 is required for good cryptographic form of signing and verifying the timestamp data. If I sign a common piece of data and send that hash to the machine I am communicating with which also signs the same common piece of data I signed and then the hash values are compared for identity. It is one way to establish identity or in this case, detect that the system clocks between the client and server are close enough together to allow the next step of the algorithm to go forth.
 
There is a common negative problem on /. that people poop on someone else's ideas and work before they embrace them or say 'good job, keep up the good work'

Distributing Cracking (3, Interesting)

Applekid (993327) | more than 6 years ago | (#21955046)

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

Hm (1)

Loconut1389 (455297) | more than 6 years ago | (#21955164)

Reminds me of something I wrote once that listens on a UDP port that moves on a time based algorithm, you send a signed message to the UDP port and if your key is right, it opens a random port and tells you what that is. You must be in the auth keys/users list and you must know the time algorithm- otherwise the box sits quiet like it was never there.

Re:Hm (1)

JohnGrahamCumming (684871) | more than 6 years ago | (#21955204)

Sounds just like tumbler [sf.net] .

Re:Hm (1)

Loconut1389 (455297) | more than 6 years ago | (#21955316)

I hadn't heard of that. I originally wrote that around '98, so it probably predates both. Nice to see a more serious project.

Re:Hm (0)

Anonymous Coward | more than 6 years ago | (#21955688)

You should sue them. Prior art and all that wonderful stuff. All you need is that self-mailed floppy from back in 98 when you present your case to a judge.

And if you don't; I have a similar utility created back in 1987. It's a on 5.25 floppy and the time stamp of the .c file proves me right. I think that predates your copy.

Re:Hm (1)

Loconut1389 (455297) | more than 6 years ago | (#21955890)

no need- it was internal use and built in to a proprietary app- it didn't use iptables or anything- it just opened the correct port directly. It never made a dime anyway.

Potential DoS scenario? (1)

Lieutenant_Dan (583843) | more than 6 years ago | (#21955268)

Figure out or guess the internal LAN subnet, create your (thousands of) fake TCP-packets and just hit random ports on a server running this. Before you know it everyone will be black-listed and someone has to go locally to the server to clean this up.

Mind you, an IDS will probably see this activity and if there's an IPS it may be able to block the fake packets. Mind you, most places don't have that.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?