Cryptographically Hiding TCP Ports 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."
Re:Neat in theorey, imho. (Score:4, Informative)
Re:Neat in theorey, imho. (Score:4, Informative)
Re:"Obscurity" tag is misleading (Score:2, Informative)
It's all fun and games till you've locked yourself out from an only remotely accessible server...
Re:Isn't this port knocking (Score:2, Informative)
Re:Obscurity? (Score:2, Informative)
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? (Score:2, Informative)
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]
not as good as port knocking (Score:3, Informative)
Re:Neat in theorey, imho. (Score:3, Informative)
Re:Newbie Question about SSH Security ... (Score:5, Informative)
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.
Re:"Obscurity" tag is misleading (Score:3, Informative)
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]
Use ssh-faker instead (Score:1, Informative)
With ssh-faker, all ip addresses are denied access to sshd until the connecting machine provides the proper ssh-faker password. At that point, ssh-faker inserts an entry in
Advantages over this system:
A lot simpler to impliment. Sshd already uses tcpd and
No need for any special client software at the remote end in order to be able to connect to your system. You just need a working telnet program and you can insert your current IP address into
Absolutely no "lucky guess" aspect. With 48 ports open, three of which are "valid", a hacker has a 3 in 48 chance of randomly guessing the correct, operational, ssh port, at which time the only security you have remaining is the strength of your passwords (if you allow password based ssh logins).
This can be mitigated by disallowing password based logins, but doing so means you "must" carry your ssh-key data with you everywhere you might need to log in from. Ssh-faker gives you the security of a password-less login sshd without the need to carry your key data with you (and be able to make use of it).
Disadvantages of ssh-faker:
1) You need to have a working perl interpreter on the machine running sshd. No big deal on a full PC box, but might be a problem on low memory embedded systems.
2) You will need to connect twice from where-ever you are, first with a basic telnet to input the ssh-faker password, and a second time with your real ssh client to log in. Not such a big deal for all of the advantages provided.
3) The ssh-faker password is sent as cleartext. This leaves it open to a sniffing attack. But, keep in mind that this shimmer system as a 3 out of 48 chance of random guessing. A sniffing attack requires an actual attacker located on a link along the way sniffing your data to locate your ssh-faker password. If you are being targeted with this level of precision, well, you most likely have bigger problems that neither ssh-faker nor shimmer will cure. Note also that the ssh-faker password is only sent once per each new IP you are using. Once an IP is inserted, you don't need to resend the password. So an adversary must be interested and sniffing exactly when you once enter your ssh-faker password. Any other time, and she is out of luck.