I'll put my two cents in here as well. If it's security you are concerned about, I'd advise against any sort of scheme like this.
Implementing a port-knocking system has two effects on security: First it increases security a small amount, in that people who don't know about your port knocking scheme don't have an opportunity to exploit a weak ssh password or latent vulnerability on the underlying ssh access mechanism. Second, it decreases security by a largish amount in several ways. The protected system becomes vulnerable to implementation errors in the port knocking system itself. It offers no protection against those who have the knowledge of the "secret handshake". And (in my opinion) it encourages an attitude of "I don't have to pick a strong password or upgrade to the latest ssh to fix a vulnerability today because my system is protected by a port- knocking handshake". The security you gain by adding this to your access control system can be summarized by considering what portion of this system you are planning to keep secret (like a password) and never divulge to anyone. If you're planning to gain security from the fact that nobody knows about your port-knocking system, you'd better make sure you keep that information as secret as your ssh password. If the "open saysme" method is obvious to anyone watching squid logs, and the ssl webpage takes an 8-character password, you be better off just adding 8 characters to your ssh passphrase. See: http://catless.ncl.ac.uk/Risks/22.56.html#subj10.1 If you create a cgi script to verify your (webpage) password before using privleged access to open the ssh ports, are you *really sure* you didn't make a mistake and allow a clued attacker a way to use the (never designed to be really secure) cgi system to completely bypass the (designed to be secure, but mistakes happen in theory) ssh access controls and open the system wide. Adding complexity to an already-pretty-good system almost never adds security. "Has no obvious vulnerabilities" is not the same as "Obviously has no vulnerabilities". On the other hand, the amount of security you are gaining or losing by adding a system like this is likely to wash out in the noise, unless you're aiming for the kind of security not normally discussed on open mailing lists. Are you sure you're running the latest patches? Do you know where *all* the software on this box came from? Are you the only one with access to the hardware? Etc, etc, etc. WE are, after all, talking about a system connected directly to the Internet. -----Original Message----- From: Rick DeNatale <[EMAIL PROTECTED]> Sent: Feb 4, 2005 10:05 AM To: Triangle Linux Group <[email protected]> Subject: [TriLUG] Port Knocking Alternatives? I've been thinking about ways to keep ports like ssh closed to the internet until I need them. Port knocking seems to be a popular technique but I'm not sure that that's what I want. For one thing it won't work if the incoming client is behind a firewall which blocks outgoing traffic on one or more of the knock ports. So I was thinking of something like a cgi on my webserver which I could talk to via ssl. This could accept a passphrase and alter the firewall rules to open up another port for the client's ip address, perhaps for some time period, or whatever policy I wanted to apply. Is anyone aware of anything which does this or something similar? Another nice thing to support might be, under client request, instead of opening up port 22 for sshd, redirect port 443 to 22 for that client in order to let ssh tunnel through a firewall which allows outgoing https but not ssh, I've also thought of setting up a "fake" sshd, which would make intruders "think" that they had gotten in, only to get a "MOTD" which said something like: Thank you for participating in the NSAs cyber-hacker registration program. We have noted your information and entered it into our target database. Retaliation will be performed at a random time, under the authority of the US Patriot Act. Have a great day! and then they would be disconnected. I think that this could be done with iptables and a small bit of programming. -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc -- "Convenience causes blindness. Think about it." Steve Holton [EMAIL PROTECTED] -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
