High Profile

Posted Nov 18, 2004 3:20 UTC (Thu) by ringerc (subscriber, #3071) [Link]

Another really important one is to deny users the option to use passwords as their only form of authentication for a service. If you must have a password on their account (instead of an invalid hash, so login is impossible), do not permit it to be used for shell logins and don't let anything that takes the password be accessed except by the local hot. Run _everything_ over ssh, and require users to supply an ssh public key during account setup.

If the sshd is trojaned by a local attacker who got in with a password stolen from a less secure system (Apache/SourceForge compromise), they can't steal logins to attack other hosts. Remember, many people use the same usernames/passwords for many sites, and there's little you can do to prevent this. This improves your users' security. It's also considerably harder to steal an ssh key than a password, so it helps your security too.

Next, if at all possible deny local logins. Use ssh to set up port forwards or run automatic commands (like '/usr/bin/cvs server'), but never give users a shell. Unfortunately, this may require the users to manage multiple keys. If you absolutely must give them a shell, if at all possible give them a very restricted shell that can only run a couple of commands. I'm talking not even `ls'. If at all possible, chroot it.

A similar approach can be configured for things like authenticated https. Generate client certificates for the user, and require them before authentication is attempted. This makes brute-force attacks very hard, and means that a stolen password is no good without the attacker also successfully stealing the client certificate from the same person. Passwords compromised as a result of someone using the same username/password with an insecure protocol do the attacker no good at all.

There's also some obvious stuff - run as few services as root as possible, use chroot like there's no tomorrow, run as few services _at_ _all_ as possible, etc.

Just because your server is a public host doesn't mean it shouldn't have a firewall. Lock it down.

SELinux may be a right pain, but perhaps it's less painful in the long run than a compromise? (Frankly, I'm not convinced. It's _really_ painful.)

Finally: Be utterly, foaming paranoid. If you're running a public service, there's no such thing as a trustworthy user. Work as if all of them are actively trying to get you cracked.

I don't know what happened to fd.o or if any of these steps would help them. Sometimes there's just nothing you can do, such as when a major hole is discovered in a daemon you have no choice but to run as root and it's exploited before it becomes public. Still, these steps may well help.