[ale] rootkit strike

J.M. Taylor jtaylor at onlinea.com
Wed May 21 10:54:16 EDT 2003


*** warning: VERY LONG locking-down-a-new-linux-box email ****

Bob,

I'm sure you'll get some good advice from the list, there are some great
security folks on here.  I don't have much experience with rootkits, and
I'm sure others could help you more with forensics to determine point of
entry, find out what has been compromised, ensure that the stuff you're
moving to the new, locked down server isn't still compromised, etc.

What I do know a lot about is locking down linux boxen that are publicly
available.  I have a checklist that I always go down when I set up a new
box.  Bastille is excellent and I run it on all my servers, but make sure
you read point by point what it's doing and understand what it's doing, or
you could wind up with really wierd behaviour that takes awhile to track
down.  Umask for the root user has bitten me before. :)

What I usually do is install the new OS very carefully, selecting the
packages to install by hand.  That's the key thing with a new install, to
know from the outset what is on your machine.  I go with the absolute
minimum install, I don't use their packaged web servers, FTP servers, or
anything that's going to be listening, because it's guaranteed that it
will be old.  What you want is bare minimum, no X windows, no services, no
daemons, no printer capability unless you *really* need to print from this
box. Absolutely no rpc or NIS services, and for a web server I'd say no
NFS either.  Two gotchas that linux distros usually do to the unwary -
they run sendmail as a daemon by default (which you do *not* want,
sendmail will mail off the box without listening for incoming mail) and
they sneak printer services (lpr, lprng) in there which for a server you
probably don't need.

Once you've installed and rebooted, and BEFORE you plug in the network
cable, do netstat -nl to see what's listening. If you show nothing at all,
most wonderful.  If netstat lists anything in the topmost grouping (Active
Internet connections), track them down and make sure you know *exactly*
what they're doing.

Then start pruning your users -- cat /etc/passwd to see the users that are
there by default.  Use common sense when getting rid of them, but I
guarantee you if you limit your services you won't need a user named
'gopher','news','mailuser','games' etc.  There's a lot of dross in that
file.  I usually use userdel to get rid of the users and their shadow
passwords in one fell swoop.  Then do the same to /etc/groups.  Finally,
the users you're not comfortable deleting but you know aren't actively
logging in, make sure that their shell is /bin/nologin, or /bin/false, or
some other thing that prevents login.

At this point I usually get the latest *source* versions of whatever
software I'm going to install, and start compiling and installing. I
compile and install from source because it gives me paranoid control over
*what* is being installed, *where*, so I know intimately what is going on
with this machine. I'm sure the package management folks have many flames
at the ready - I don't want to hear it, you use package mgt if you want to
and I'll compile from source.  I do the apache/php/mysql platform so
that's what I'm most familiar with. If you run PHP, I've got a howto for
locking it down at  http://galinux.com/howtos/phpconfig.html.  Apache has
some good security information at their site, but in my experience your
worries come from CGI of any time (perl/php). That's the big front door to
your web server, which nothing but code auditing and, again, knowing
what's on your box is going to mitigate.

Key software here - logsentry (logwatch, logcheck, it's gone by many
different names but was originally from Psionic).  Run once per hour, it
emails you any anomalies in your logs and is a great way to keep track of
what's happening on your servers.  Bastille will help you tweak your
syslog conf for optimum logging, and if this is a server that runs
headless I usually add the following *after* Bastille has done it's thing:
-----
# Log additional data to the Alt-F7 and Alt-F8 screens (Pseudo TTY 7 and 8)
*.info;mail.none;authpriv.none  /var/log/fortty7
authpriv.*      /var/log/fortty7
*.warn;*.err    /var/log/fortty7
kern.*  /var/log/fortty7
mail.*  /var/log/fortty8

*.*     /var/log/fortty12
-----
Which ensures that anything that would normally echo to the console gets
written to a log file too.  You'd be surprised how vaulable that is. :)

After the software is installed, as root (and usually I do this in root's
home directory), find all the files with setuid and setgid. I have the
exact syntax of the find cmd to do this at home, sorry, I can mail it if
you're interested. It finds all files with setuid and setgid, cats them
into a file. I then remove the ones that *should* be setuid (like su) from
the list, add 'chmod -s ' to the beginning of every line, make it a bash
script and run it.  Then I run the find cmd again and verify that only the
programs that *should* be suid/sgid are. I keep this file somewhere safe,
usually burnt to a non-rewritable CD.

The last thing I do is install a homemade tripwire. It's not infallible by
any means, but it's just one more thing.  Get the MD5sums of key binaries
-- I usually do most of your basic commands - ls, ps, grep, su, lsof --
plus anything that strikes me as important to know if it's been changed
since I installed.  Obviously if you change the binary, you're going to
have to change your base checksums.  :)

Burn the original checksums to CD. Write a script that: runs md5sum on the
same binaries and stores the file in /tmp or someplace safe.  Diff the
/tmp/md5sums with the ones you've got on CD. If there's a difference,
there's a problem, and I get email about it. :) I also burn this script to
the same CD, and leave the CD in the machine. Cron it to run every 5
mintues, and you've got a homemade tripwire.  CDs are cheap enough to use
this way even if you change email addresses or update binaries frequently.
 On the same CD I usually keep a forensics toolkit of known good binaries
(statically compiled) like ls, ps, and lsof, so that if I susupect a break
in, I can use the binaries off the CD to help determine what's going on.

After you plug in the network cable, run nmap and/or nessus against the
new machine to make sure, from the outside, that it's presenting the open
ports you expect and no others. It's a good idea to do this frequently,
and even script it from a box or boxes you trust.

And that's pretty much what I do to lock down a linux machine. It's not
enough for the truly paranoid, but it does make most kiddies move on, and
the steps really don't take more than a couple of hours at the initial
setup of the box, even if you've never done them before. 
http://www.galinux.com/acm/ is a sort of quick presentation I gave to some
CS students here, so it's kind of less techincal, but it's a quick read if
you want to know where I got most of this stuff.

Good luck, and if you have any questions as you set up your new box or try
to do forensics on the old please feel free to email me.  I'm not an
expert like Bob Toxen or Jonathan Rickman but I have been managing public
linux boxen for several years and am always happy to help, verbosely, with
more information than you ever wanted. :)

Best,
jenn




_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale





More information about the Ale mailing list