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."
Clock drift is an issue, hence the fact that three overlapping minutes are kept active at once.
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.
ZFS: because love is never having to say fsck
It's all fun and games till you've locked yourself out from an only remotely accessible server...
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 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?
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
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
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
Instead of going to all this trouble, simply use ssh-faker (http://www.pkts.ca/ssh-faker.shtml) and you'll achieve at least the same level of security with a whole lot less hassle.
/etc/hosts.allow to allow that one particular IP address access to sshd. Then, you connect again using ssh and get sshd instead of ssh-faker, and you log in.
/etc/hosts.allow /etc/hosts.deny for IP granularity access controls. So installing ssh-faker involves a one line change to /etc/hosts.deny and you are done.
/etc/hosts.allow.
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.