[TriLUG] Port Knocking Alternatives?

[Brian Henning]

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

sholton at mindspring.com 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.
> 
>