[ale] rootkit strike

[hbbs at attbi.com]

<wild applause>

Thanks for the rundown, Jenn!

- Jeff
> *** 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

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