02 What if your Unix Machines are Compromised by an Intruder p2
Description
This article is from the Unix compromise FAQ, by Christopher Klaus cklaus@iss.net with numerous contributions by others.
02 What if your Unix Machines are Compromised by an Intruder p2
3. Check the binaries with the originals. Especially check the following
binaries because they are commonly replaced backdoors for regaining
access:
1. /bin/login
2. all the /usr/etc/in.* files (ie. in.telnetd)
3. and /lib/libc.so.* (on Suns).
4. anything called from inetd
Other commonly replaced backdoor binaries:
1. netstat - allows hiding connections
2. ps - allows hiding processes (ie Crack)
3. ls - allows hiding directories
4. ifconfig - hides the fact that promiscuity mode is on the ethernet
5. sum - fools the checksum for binaries, not necessarily replaced
anymore because its possible to change the checksum of the
binaries to the correct value without modifying sum. *EMPHASIZE*
Do NOT Rely on sum.
Use 'ls -lac' to find the real modification time of files. Check
/etc/wtmp (if you still have one) for any system time adjustments.
Check the files with the distribution media (CD or tape) or calculate
MD5 checksums and compare them with the originals kept offline (you did
calculate them sometime ago, didn't you?) Suggestion: cmp the files
with copies that are known to be good.
Another popular backdoor is suid'ing a common command (ie. /bin/time)
to allow root access with regular accounts.
To find all suid programs you may use:
find / -type f -perm -4000 -ls
To be thorough you may need to re-load the entire OS to make sure there
are no backdoors. Tripwire helps prevent modifying binaries and system
files (ie. inetd.conf) on the system, without the administrator
knowing.
4. Implement some password scheme for your users to verify that they
change their passwords often. Install anlpasswd, npasswd, or passwd+ in
place of passwd (or yppasswd) so that your users are forced to set
reasonable passwords. Then run Crack, which is available on
ftp://ftp.cert.org/pub/tools/ to make sure that your users aren't
bypassing the password check. Crack ensures that users are picking
difficult passwords. With the network, clear text passwords are a
problem. Other possible choices: smart hubs (stops ethernet sniffing of
the whole LAN) and one-time password technology.
5. Check all the users' .rhosts and .forward files to make sure none of
them are weird or out of the ordinary. If .rhosts file contains '+ +',
the account can be accessed anywhere by anyone without a password. COPS
has a scripts for checking .rhosts.
find / -name .rhosts -ls -o -name .forward -ls
Look also for all the files created/modified in the time you are
suspecting the break-in has taken place, eg:
find / -ctime -2 -ctime +1 -ls
To find all the files modified not less than one day ago, but not more
than 2.
All .login, .logout, .profile, .cshrc files are also worth looking at
(at least for the modification date/time). Make sure there are no
'.rhosts' for the locked or special accounts (like 'news', 'sundiag',
'sync', etc.) The shell for such accounts should be something like
'/bin/false' anyway (and not '/bin/sh') to make them more secure. Also
search for directories that have like ". ", ".. " as names. They are
usually found in /tmp , /var/tmp, /usr/spool/* and any other publicly
writeable directory.
6. Check to make sure your NFS exports are not world writable to everyone.
NFSwatch available on ftp://harbor.ecn.purdue.edu/pub/ , a program by
David Curry, will log any NFS transactions that are taking place. Try
'showmount -e' to see whether system agrees with your opinion of what
are you exporting and where. There are bugs in some nfsd
implementations which ignore the access lists when they exceed some
limit (256 bytes). Check also what are you IMPORTING!!! Use 'nosuid'
flag whenever possible. You do not want to be cracked by a sysadm from
another host (or a cracker there) running suid programs mounted via
NFS, do you?
7. Make sure you have implemented the newest sendmail daemon. Old sendmail
daemons allowed remote execution of commands on any Unix machine. See
the computer-security/security-patch FAQ.
8. Try to install all the security patches available from the vendor on
your machine. See the computer-security/security-patch FAQ.
Continue to:
My Books
