On Wed, Mar 08, 2006 at 01:58:18PM -0700, Bob Beck wrote:
> * Joachim Schipper <[EMAIL PROTECTED]> [2006-03-08 12:13]:
>
> > 1. Use sudo exclusively - set an empty or nonsense root password
>
> Stupid <...>
> > 2. Use public key authentication only for sshd(8), and restrict
> > which users can log in.
>
> So they can expose their key on a bazillion remote systems
> instead of the password on this system ? :) This is a tradeoff,
> universal statements like this are frequently shit. allowing
> public keys means you're now accepting the security of
> every machine an idiot ssh's from as good enough. My "most secure"
> machines do not permit public keys. They also use pf.os to
> encourage people not to ssh to them from less secure choices of
> operating system.
So what do you use? Personally, I have one main workstation which has
the private key to get into everything; one secondary workstation which
can get into the primary; and no access between the rest.
For logins from untrusted machines, S/KEY will have to do. It's much
better than password authentication, as keyloggers are all too common.
And yes, I am aware of the failings of S/KEY, especially when in an
untrusted environment - it will not stop someone who has taken care to
crack it. It will, however, defeat general-purpose loggers and passive
network taps.
Yes, disallowing access from Windows or even Linux makes some sense, but
it is not always feasible.
Besides, stupid users are, to some extent, neither a technical problem
nor solvable by technical means. And since we were originally talking
about a firewall, it seems reasonable that the users can be trusted to
be somewhat responsible.
> > 2a. If you really need something password-like, use S/KEY.
> > 2b. If neither is feasible, audit the passwords (use John the
> > Ripper for existing passwords; some schemes exist to act when setting
> > new passwords)
>
> Don't audit using John, users just cycle between shitty ones.
> check them. (see passwordcheck in login.conf(5))
A very good idea, but one that falls under the latter category - i.e.,
it doesn't help for existing accounts.
> > 3. Restrict the use of ports, and research into the security of
> > a program before installing. mail/postfix is unlikely to open too many
> > holes; www/php5 is best left alone, if security is the goal [1].
> > 4. Audit suid/sgid executables - quite a few are not needed on a
> > minimalist system, but again - breaking stuff will lead to other stuff
> > breaking. (Where 'audit' will typically mean 'remove any that are not
> > needed' - the other end, a full source audit, is very, very
> > time-consuming and difficult.)
> > 5. Monitor the appropriate lists (did you know about the pf DoS
> > problems in 3.8-rel? They are not in the patches, and very unlikely to
> > cause trouble, but it's good to know what not to do).
> >
> > Actually, regarding 1 - I find myself wondering whether logging in as
> > root, where no suspicious stuff in my own account can reach me, is not
> > preferable to using sudo (which is trivially subverted with a single
> > line in .profile). Does anyone have a good opinion on this? (Yes, I know
> > that root is not to be used for trivial matters, and yes, I know when to
> > log out.)
>
> My "most secure" machines do not use sudo - there is only
> root. (on most of my machines however, I do use sudo). I use
> sudo to make a machine a measured amount less secure (by allowing
> more people high level access) than more secure.
Yes, you are right about this.
Joachim
