> > a "netstat -an | grep LISTEN" will show you "evilthings(tm)" ;)
>
> Not necessarily. Some rootkits have nobbled the "netstat", "ps" and other
> system binaries, so that they don't show up suspicious processes/listening
> ports/logged in users.
Agreed thoroughly. But remember, this is assuming you have made the
executive decision and considered your box compromised.
Every admin should also have a statically compiled set of tools on CD
btw. Not only can binaires be trojaned, but so can libraries.
> If anyone has managed to get access illegally, you _MUST_ assume that they have
> root access. There is no way you can assume that they got in as a normal user,
> and managed to find a way to access privileged information.
I agree with you. However it really depends on your motives and your
course of action. This discussion is academic.
> > It could be anything.. either way - you know that something has
> > happened. Make an executive decision to decide if it has (I think it
> > has) and pull the box from production, rebuild it, secure it, patch it,
> > then change all user passwords (if any).
>
> If possible it would be good to pull the box out, and compare the system to the
> distribution RPMS - you can compare the RPMS and see if anything has changed.
> That way, you can send information to AusCERT and CERT.
Bollocks. Before even *thinking* of doing analysis, dump the filesystems
with dd onto tape, make two copies and impound the compromised
box. Start a log in a notebook (paper) and note exactly what you do and
who has which tapes to preserve the "chain of custody". Then take one tape
as your analysis copy and remount those filesystems on loopback (ro) on
another box. Then and only then should you analyze.
Remember boys and girls, the instant you do a cat /etc/shadow or anything
- you are destroying evidence. You are modifying the atime records on the
inodes at the very least. There is no chance in hell you will prosecute
after this.
Maintaining integrity of forensic data is an art form (especially if you
wish to prosecute - well your CIO will want to anyway).
> Then you rebuild from distribution media. I wouldn't rely on backups, as you
> don't know exactly when they managed to hack into your machine.
I agree with Rebecca here in regards to not trusting backups. But this
brings me to another point.. well argued with many people.. why backup
whole filesystems at all? Especially in a secure/firewalled
environment.. I tend to believe in backing up config files only - no
binaries.. as you may see, there are pros and cons of doing this.. but it
depends on your environment and requirements.
> And you expect them to give you any clues? You should assume that they broke
> in, and removed most traces of the hack. A casual inspection would most likely
> not show anything to be amiss.
They have already left many clues. /etc/inetd.conf is a big one. ;)
> However, if you have Tripwire or something similar, you can determine which
> files have been changed.
You'd have better luck with Veracity.
> Another thing to consider is to use IP Chains or IP Tables or something to
> provide some form of defense against portscans and stuff. It's not going to
> stop them cold, but it can help slow them down.
Portscans are fine. Everybody gets portscanned everyday. The important
thing is to not have any vulnerable services or a vulnerable kernel. Use
ipchains etc to only accept packets destined to services which you intend
to provide. Don't forget your outbound acl's on your border router!
Also - don't forget to protect your routers.. and also use them to protect
you.
Perhaps we should have another SLUG meeting on security with a QA session
or a BOF session (or even a BOFH session ;)
//umar.
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
