tools for locking down linux boxes
 

It would be nice to have a list of software that could be of help locking down a linux box ... small scripts that help checking things also - like checking chroot installations are also welcome!

Let's start with a topic that is dealt of alot today but still a lot of "handwork" ... chrooting. Any useful tools / scripts for this ?

//Moderator note: ppl, this (sticky) thread will be used to collect all your tools, procedures, tips, scripts, linkage and whatnot so we can compile it into a good doc.
So cummon and post!

Here is something stupid that I did based on some info from various security and general Linux HOWTOs, etc...

Take the "local" devices that normally can't be used by anyone besides root, things like:
/dev/dsp for sound
/dev/fd0
/dev/cdrom
and even stuff like FAT or NTFS partitions such as on my box:
/dev/hda1 vfat
/dev/scd1 NTFS

Make a group with a name like lusers (for "Local USERS", pun intended)
chown all these to root:lusers
chmod these to either 770 or 660 depending on needs
(or gid and umask them in fstab)
Add anyone who needs access to these to the lusers group.
You basically get something similar to adding everyone to an audio group for sound but a little more powerful/versatile. and it's easier than making seperate disk and sound and whatever groups for local users.

----------------------------
Also, when setting up Samba with security=domain or security=user and adding accounts for an admin group or machine accounts for NT/2K/XP Pro boxes you can passwd -l the corresponding unix accounts which prevents someone from ever hacking into your system using say the machine name of an NT box on your LAN as a login. Passwd -l makes an entry in /etc/shadow that will never decipher into a useable password and basically prevents the unix account from ever working while keeping the corresponding Samba account useable in Samba.
As an example I have an NT box on my Samba PDC domain, machine name velma; The velma machine can log into the Samba domain but nobody can ever log into Linux using the username velma.

I hope these aren't too blatently obvious or common knowledge already.

Obviously the box should have a firewall, ideally with INPUT and OUTPUT filtering :-)

first tool to be coded
 

Something for helping making hand made chroots. What you need for that frequently is copying neccessary libraries ... well unspawn wrote a code snippet:


I think ideally it should keep the path name just stripping the leading "/" ... so /usr/lib/xyz.lib becomes usr/lib/xyz.lib or ./usr/lib/xyz.lib


So for command line parameters:
1. executable (example: /bin/bash)
2. destination path start (example: /server/http/)
3. -c / -v where -c means actually copy and -v just lists libraries dependecies (then command line parameter 2 is not required)


Anything else needed in that case ?

Yeah, right. This a bit out of context of what you mailed me. Didn't know it'd end up here. Come to think of it, when I use "jail" (Jail Chroot Project, gsyc.inf.uc3m.es) these dependancies are handled for me already. I spose a quick crude script could look like:
#!/bin/sh
doLdd() { ldd ${1} | awk '{print $3}'; }
case ${1} in
-c|--copy) doLdd ${2} | while read i; do cp -a ${i} ${3}; done;;
-s|--show) doLdd ${2};; esac
exit 0

No checking for args, existance destdir, etc, etc tho.

Pt.1 or pre-everything else...
 

I'm thinking maybe we should handle it phase by phase.
I'll start off with the post-install pre-everything else phase.
Please add your (no OT stuff please) questions, comments, idea's tips and tools, it will be appreciated. Then we'll move on to the next phase? What y'all think? (Anyone out there?)

Ok. I think we have got to make sure the basis is sane by first making a "baseline" fingerprint of the installed SW, (remove packages we don't need, clean out services and configs, then move on and set up (preliminary) restrictions (incl. SW) for the system and it's users, and finish off with narrowing down local and remote access and install monitoring SW).

Well, actually the first thing you should do is gather the system stats/info, like what it's gonna be used for, disk parameters etc etc which should start of the log for the box (example disk info: /sbin/dumpe2fs -f -x /dev/<partition> > text, fdisk -l -u >> text, tune2fs -l /dev/<partition> >> text, "dd" the bootsector, just in case: dd if=/dev/<boot partition> of=booth.dat bs=512 count=1). All major changes to the system should be added. After realizing a fuckup this *may* come in handy.

For the fingerprinting I like to use Aide. It's no deal defining different configs to be run at different times. This allows you to spread load while still having a calculated risk when it comes to checking. What I mean is when system binary and config dirs are chattr'd, the risk of someone dumping objects there will be less compared to say /tmp, /dev, /var or /usr. Not that you want separate configs on the first runs tho: divvy it up later on.
About the only thing Aide lacks compared to tripwire is it won't verify it's own databases, so it's vital to ship 'em off the box stat. Samhain implements a signature server, so for checking you can get the db from a safe location. Btw, there's nothing against renaming binaries. Even tho this can be categorized as "security tru obscurity" about the only way to find out would be to grep crontab for a line with known variables/locations, look at the contents of the log/spool dirs or run strings on every binary for a match...
To recap for some ppl: Aide good, RPM (or any pkg mgmnt db's) bad. Not bad to use, but worthless for checking integrity cuz it won't show files not in it's db...

Next up: your comments etc etc, then removing stuff, cleaning up services and config stuff.

I agree with your steps. I also like to do disk dumps, etc. As a monitoring software I suggest something like Monit. It's pretty flexible in it's configuration ...


If you want to do something like centralized monitoring there are other things like Nagios (former known as NetSaint). Nagios' configuration is a bit more difficult but itself it's pretty more powerful. I also like the Avability reports ... I like it itself but currently never investigated the time it would need to configure, etc. A online demo of it can be found at http://www.nagios.org/demo.php


About removing services, etc. It's a good idea to remove those things even before installing (as good as possible) of course ... what a lot of people think of as risky is a compiler on a production server. What about the idea of creating a server that has the same distribution (version and updates) on it ?

I have to admit I like the Securing Debian Manual

OT
 

// As a personal and OT comment I find it fsckin' amazing we're the only ones doing this thread...

Perhaps you're the only ones posting so far but it looks as if a lot of users are interested - judging by the 'views'.

I'm waiting to see more myself as I've been toying with tripware for a new server install. Now I find I need to have a closer look at Aide.

This is good stuff.

How about locking system accounts that are not in use?
I use www.demarc.com for monitoring.

If you are using chroot'd services have a look at www.grsecurity.com . They have kernel patches to prevent breaking out of a chroot'd env.

As well as making sure your pam.d or pam.conf files have the correct ie: other required pam_deny.so entries in them.

Their are some common things as well, like knowing what process run normally on your box. Maybe write a script to check once or twice a day and have the output mailed to you.

Remove a users ability to use the getent tool, to view the passwd,shadow databases.

These are just a few off the top of my head.

Nothing and nobody can prevent that you can break out of a chrooted env. They just make it more difficult ... :-)

Installing snort should be an option also ...

Since I suck, here's my .5 cents:
Use root only when necessary and NEVER browse the web/connect to other boxes as root if possible.
For most things not needing actual root, look into sudo. Use the multi user ability of linux as it should be used; be a user.

Damn I'm worthless when it comes to security ;)

Cool

MasterC, would you be so kind and not rate yourself as somebody "worthless" when it comes to security? A moderator surely isn't "worthless" ... so stop claiming to be it :-P


And I love browsing websites as root BTW ... it's always nice ... okay I'm behind 2 firewall layers ... maybe that's why :-P

;) I'm no mod though, and I really don't have any good pointers for security other than non-root browsing for the "un-aware" ;)

I've got one more for the newb who doesn't want to learn iptables right now:
firestarter - a graphical front end for iptables

:)

Cool