I'll see your two cents, and raise you two more!
My personal reasoning is that this sort of scheme is not intended to add any "security" whatsoever. I trust the solidity of the few usernames that are actually allowed SSH access.. My only desire is to ward off the popular dictionary attacks that I routinely see cluttering my logs when I leave SSH wide open (side note: I tried to call a particular dial-up provider to inquire what their dial-up IP range covered... They hung up on me).
The bottom line, of course, is that the only truly "secure" computer is turned off on a shelf somewhere. As soon as there's an entryway, no matter how secure its mechanisms may be, it is vulnerable in some form or another. Sometimes all it takes is a well-placed social engineering telephone call to an inadequately trained user.
Cheers, ~Brian
[EMAIL PROTECTED] wrote:
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.
-- 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
