Slashdot Mirror
Cryptographically Hiding TCP Ports
JohnGrahamCumming writes "The shimmer project implements a cryptographically-based system for hiding important (e.g. SSH) open ports in plain sight. By automatically forwarding from a range of ports all but one of which are honeypots and by changing the ports every minute only a user knowing a shared secret can determine the location of the real SSH server."
Sounds like a neat hack indeed - however, I doubt its practical feasibility.
... 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 ;)
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.
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.
:%s/Open Source/Free Software/g
YTARY!
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.
ZFS: because love is never having to say fsck
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.
Passwords (or any other shared secret) are not security through obscurity. http://en.wikipedia.org/wiki/Kerckhoffs%27_principle
I have come here to chew memory and kick ass... and malloc() is returning a null pointer.
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.
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
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)
Nullius in verba
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 and Security through obscurity
The jModule
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?
Combination - fun iPhone puzzling
If you are a competitor of these guys, simply forward people silently to one of their ports in a hidden iframe.
Bingo, permanent ban.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
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.
Nothing for 6-digit uids?
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.
More Twoson than Cupertino
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.
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.
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.
If you believe everything you read, you'd better not read. - Japanese proverb
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.