OT: Linux tip

[Fairlight]

When asked his whereabouts on Thu, Oct 18, 2007 at 02:29:04PM -0700,
Bill Campbell took the fifth, drank it, and then slurred:
> IMHO, the keys to keeping *nix systems secured are:
> 
>   1.  Security must be an ingrained policy, supported from the highest
>       levels of a company, not a tacked-on afterthought.

No disagreement.  However, the highest levels of the company -usually-
aren't technically savvy enough to actually be able to implement the
policy, or sometimes even know they need to consult with someone regarding
such policies.  That's an automatic failure right there.  :(

Usually it's delegated downwards--often to late hires, in which case you
end up with that afterthought model.

>   2.  Intrusion detection software that keeps track of all the critical
>       attributes of critical files on the system including mode, ownership,
>       and md5 and sha1 digests of the files.

Agreed.

>   3.  Log watching routines such as swatch or fail2ban that notify of
>       intrusion attempts,

I don't dispute that these are a good idea.  The idea is to prevent as much
from hitting those logs as possible.  Lock down sshd to only those hosts
that need it, etc.

>   4.  Allow remote access only via secure shell with authorized keys, never
>       with password authentication.

I think that's a good idea.  OTOH, it also makes remote recovery harder.
One time someone was leaving their company and changed all the passwords on
-everything- in advance--out of malice.  I was able to get in and reset all
the linux systems on the cluster within minutes precisely because I had ssh
keys installed that he (the employee) didn't know about.  They had control
back very, very quickly--while I was on the phone with them, actually.

Had the employee known about keys, he could have removed mine at the same
time he was inserting his own.  Things would have required a boot disk at
that point.

The other key thing is to make sure the system owners know you have keys
installed into their system, and on which accounts--so that they can shut
you out if necessary.  I never want to be accused of having installed a
"secret" back door access entry point.

>   5.  Use tcp_wrappers with RBL support to protect all services allowed.

That gets back to what I was saying in #3's reply.  Sorry, answered inline.
I agree wholeheartedly.

I still think strong passwords are necessary, even if you're key-only on
ssh.  You don't want weak passwords on corporate email accessible with
pop3, for instance.  And insider attacks are more common these days than
ever.

mark->