Insanely Securing Your Unix or Linux Systems

Hey again,

Since this week has been all over the map, I thought we'd spend today going back and dipping into the over-the-top-security well ;) You may recall a post from last year that we did on making generic user accounts su-only and, maybe even more so, a post we just recently did on using mkfifo and script to keep tabs on user account usage. Both of these were aimed at providing relatively decent security for the Unix or Linux admin, while allowing the user the freedom to do his or her job without too much of a hassle. Both of these posts assumed a box that had consistent user activity, but needed to be secured from those "ooops" moments that end up burning up your night-time hours and, possibly, creating a financial problem as well (most places I've worked have at least one box that is fairly lax, security-wise, but hemorrhages cash the instant it gets taken offline. The logic of maintaining the status quo in that situation baffles me. But I'm not rich and I don't own the company. I may be missing something ;)

With that in mind, and a grin in our heart, let's look at some other ways you have to secure yourself (and your machines) against misuse and/or abuse by users (and, of course, the innocent mistake made by someone with too much access). We'll assume that you've cranked up the user-account security to the relatively-user-friendly levels we set out in those previous security posts. Everything from here on out is above and beyond. Don't take too much of this literally (of course) unless you have to. Especially if you're walking into a situation where you'll be taking away freedoms users' have become accustomed to. You'll make bitter enemies and they will probably steal your sack lunch ;) This, I repeat, is all in good jest :)

Here are a few more suggestions to ratchet up the security level. We'll start out with the stuff that will be the least offensive to the end user.

1. Remove the additional line that allowed for additional profile sourcing that you added to each user's .profile/.bashrc, etc and don't allow them to set any environment variables through their root-owned and root-writable login profile. Now your users will have a .profile/.bashrc that they can only execute and read, but cannot write to. The final line that allowed them to create a separate file to set their own environment variables has been removed. You're control is slightly more defined now, but the user can still set all that stuff manually or just create a script and run it separately every time they log in. It won't take anyone long to develop a habit, or create an alias to make it even easier. If you want to avoid this nasty side effect, be sure to make the variables you set in the users' .profile/.bashrc "read only", so instead of:

PATH=/usr/bin

use

readonly PATH=/usr/bin

Results and methods will vary from shell to shell.

2. Take the idea of making generic accounts su-only one step further and start restricting access to the su binary as much as possible. If you can get away with it, ensure that your /usr/bin/su file is chowned to root:special and chmod'ed to 4750. Now only root and users who belong to the "special" group can even use su to do anything. Everyone else will get an error just for trying to run it. This has the potential to get some folks angry. And they may have a good point; especially if you've already made it so that they have to log in as themselves in order to su to a generic account that they need to work under.

At this point, I can see why the user base is fuming. You've made their lives impossible! You can get around this easily, though (on those machines where you have generic su-only accounts) by making use of file access control lists (or facl's as they're often cleverly referred to ;). We've only really touched on this once before on this blog, in our post on securing programs using FACL's, which may be a good reason to do a post on them in the near future. For now you should be able to get along by working with the facl on /usr/bin/su and allowing for another group to have write and execute permissions. The actual syntax varies between Linux flavours and Unix flavours, and the man page is always your best friend on this one, but you should be able to add an additional group (with read and execute privilege) to /usr/bin/su by executing the following command (or a variation thereof):

host # setfacl -m g:aGroupName:r-x /usr/bin/su

Be sure to check the permissions of /usr/bin/su after you've verified the new privileges using "getfacl." Sometimes, modifying a setuid root binary will unset the setuid bit and you'll need to just re-chmod it with:

host # chmod 4750 /usr/bin/su

3. Well, by this point you've managed to alienate almost everybody in your organization, but at least you have workable solutions that people will get used to over time. Now it's time to amp it up a few notches and become a walking target ;)

a. Implement s/key-opie type of one time password systems. If your setup isn't sophisticated enough to do that, set your default password length to the max it can be and require everyone to have to pick a new password every other day. Make sure you keep a password history for each user that goes back about 10 or 20 "unique" iterations.

b. Use chroot, or otherwise jail, everyone who logs in. If they need to login as a generic account, provide a separate su binary in their system root with access open only to them and root (using facl's).

c. Disallow all forms of network communication to and from the box except on port 22, if possible.

d. Read the post mentioned above and use extended facl's to lock down /dev/tcp and /dev/udp. Do it in chrooted environments individually, if possible.

e. Intermittently shut down the system (having setup syslog.conf to dump everything to /dev/null) and keep a backup stash of syslog, messages, etc, files that prove that the machine has been up since the beginning of time.

And, oh yeah, be sure to treat the guy who authorizes your paychecks very very kindly :)

Cheers,

, Mike