Version: 4.0

To get the newest updates of Security files check the following services:

mail info@iss.net with "send index" in message
http://www.iss.net/
ftp iss.net /pub/

This FAQ contains suggestions for securing your UNIX machine after it has been compromised. Even if your machines have not been compromised, there are many helpful tips on securing a machine in this FAQ.

1.

Try to trace/follow the intruder back to his/her origin by looking at:

• who
• w
• last
• lastcomm
• netstat
• snmpnetstat
• router information.
• /var/adm/messages (Many crackers send e-mail to their "home" accounts.)
• syslog (Sends logs to other hosts as well.)
• wrapper logs
• Do a finger to all local users(and check where they last logged in from).
• history files from shells, such as .history, .rchist, and similar files.

Note: who, w, last, and lastcomm are commands that rely on /var/adm/pacct, /usr/adm/wtmp, and /etc/utmp to report the information to you. Some intrusion techniques will keep the intruder from being shown in these logs. With applications that are available on the Internet, it is trivial to remove any detection in these logs.

Suggestion: Install xinetd or tcp_wrapper, which can log all TCP connections to your machine, as defined by the administrator, that will allow the administrator to detect potential intrusions. Forward syslogs to another machine so intruder will not easily detect the logs and modify. Other available applications: netlog from net.tamu.edu:/pub/security.

It might be wise to monitor the intruder via an Ethernet sniffer (hardware or software implementation) to observe and review the execution of the exploit before taking corrective measures.

2.

Close the machine from outside access. Remove it from network to stop further access by the intruder. If the intruder finds out that the administrator is privy to his presence, he may perform an rm -rf / in an attempt to destroy any evidence of his presence or as an act of vengeance.

3.

Check the binaries against the originals. Especially check the following binaries as they can be replaced and subsequently gain access or regain access:

• /bin/login
• all the /usr/etc/in.* files (such as in.telnetd)
• /lib/libc.so.* (on Suns).
• anything called from inetd

Other potentials for being replaced:

• netstat - can allow connections not to be detected
• ps - can allow select processes to run undetected
• ls - can allow files or file structures to be undetected
• ifconfig - is able to mask indications that the Ethernet interface is in promiscuous mode
• sum - fools the checksum for binaries. It is not necessarily replaced anymore because one can change the checksum of the binaries to the correct value without modifying sum. Do NOT Rely on sum. Use ls -lac to determine the correct 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: compare (diff) the files with copies hat are known to be good.
• Another popular intrusion method is adjusting the SUID of a common command (such as /bin/time) to allow root access with regular accounts. To find all suid programs you may use: find / -type f -perm -4000 -ls
  

4.

To be thorough you may need to reload the entire operating system to restore the machine into a known or trusted configuration. Tripwire helps prevent someone from modifying binaries and system files (such as inetd.conf) on the system, without the administrator knowing.

5.

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.cert.org:/pub/tools/crack which will ensure that the users choose non-trivial passwords. On any given network, clear text passwords can be a problem. Hence, a solution could be one-time password technology or point-to-point session encryption.

6.

Check all file structures for .rhosts and .forward and inspect their contents. If .rhosts file contains '+ +', the account can be accessed anywhere by anyone without a password. The .forward file, when possible, can be installed into root's directory in an effort to modify critical files that could be used to gain access. COPS has a scripts for checking .rhosts. Use: find / -name .rhosts -ls -o -name .forward -ls

7.

Look also for all the files created/modified in the timeframe you suspect the break-in took place. For example, use: find / -ctime -2 -ctime +1 -ls to find all the files modified not less than one day ago, but not more than 2 as the magnitude of information can become confusing and unwieldy.

8.

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 values like ". ", ".. " as names. They are usually found in /tmp, /var/tmp, /usr/spool/* and any other publicly writeable directory.

9.

Check to make sure your NFS exports are not world writable to everyone. NFSwatch available on harbor.ecn.purdue.edu:/pub/davy, 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 (such as 256 bytes). Check also what are you IMPORTING!!! Use the 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.

10.

Make sure you have implemented the newest sendmail. Old sendmail daemons allowed remote execution of commands on any Unix machine. See the computer-security/security-patch FAQ.

11.

Try to install all the security patches available from the vendor on your machine. See the computer-security/security-patch FAQ.

12.

Here is a check list of common ways that a machine is vulnerable:

• Do an rpcinfo -p on your machine to make sure it is not running any processes that are not needed. (such as rexd).
  
• Check for '+' in /etc/hosts.equiv.
  
• Check whether tftp is disabled on your system. If not, disable it; or at least use the -s flag to chroot it to some safe area if you really can't live without it. (It is mostly used for booting up Xterminals, but sometimes can be avoided by NFS-mounting appropriate disks). Under no circumstances should you run it as root. Change the line describing it in /etc/inetd.conf to something like:
  tftp dgram udp wait nobody /usr/etc/in.tftpd in.tftpd -s /tftpboot
  
  Or better yet, use the tcpd wrapper program to protect it from addresses that should not get access to tftp and to log all other connections:
  tftp dgram udp wait nobody /usr/etc/tcpd in.tftpd -s /tftpboot
  
  And edit appropriately /etc/hosts.allow to restrict access to in.tftpd to only those addresses that really need it.
  
• Check crontabs and at-jobs. Make sure there are no delayed bombs which will explode after you think you have got rid of all the nasty things left by a intruder.
  
• Check /etc/rc.boot /etc/rc.local (SYSV: /etc/rc?.d/*) and other files crucial for the system startup. (The best would be if you could compare them with the copies kept offline). Check all other files containing system configuration (sendmail.cf, sendmail.fc, hosts.allow, at.allow, at.deny, cron.allow, hosts, hosts.lpd, etc.) In aliases look for aliases expanding to some unusual programs (uudecode is but one example).
  
• Check your inetd.conf and /etc/services files to find if there are any additional services set up by an intruder.
  
• Copy all the log files you still have (pacct, wtmp, lastlog, sulog, syslog, authlog, and any additional logs you have set up earlier) to some safe place (offline) so you may examine them later. Otherwise, do not be surprised if they disappear the next day when the cracker realizes he forgot to remove one of them. Use your own imagination to find what other traces he could have left in your system (What about /tmp/* files? Check them BEFORE you reboot).
  
• Make a backup copy of /etc/passwd (best offline) then change all root passwords (after verifying that su and passwd are not the Trojan versions left by an intruder). It may sound like a horrible thing to do (especially if you have something like 2000 users) but do lock them all by putting '*' in the password field. If the intruder has a copy of your passwords file, he/she may possibly sooner or later guess all the passwords contained there. (It is all the matter of proper dictionaries). In fact the intruder could have inserted a few passwords that only he/she knows for some users who have not logged in for a long time.

On the NIS servers check not only the real /etc/passwd, /etc/groups, etc files, but also those used for building NIS maps (if they are different).

• Verify that your anonymous FTP (and other services) are configured properly. See the computer-security/anonymous-ftp FAQ.
  
• If you want to make your life easier next time (or if you still cannot get rid of an intruder) consider installing the ident daemon. Together with tcpd on a set of hosts, it can be used to find what accounts the intruder is using.
  
• Make sure the only 'secure' terminal is console (if at all). This way you prevent root logins just from the Internet. Maybe it is not significant if somebody knows the root password; he/she may already know other peoples' passwords too, but maybe not.
  
• Check hosts.equiv, .rhosts, and hosts.lpd for having # as comments within those files. If an intruder changes his hostname to #, it will be considered a trusted host and allow him to access your machines.

Remember, there are so many ways that somebody could have modified your system, that you really have to have your eyes and ears wide open for a long time. Above, are the pointers just to the most obvious things to check.

13.

Mail all the sites that you were able to find out that the intruder was going through and warn them. Also, CC: cert@cert.org. Check all the sites in your domain, institution, etc. It's usually trivial for a hacker to get to another system by a simple rlogin if the two systems have a common subset of users (and using .rhosts to make the access easier).

14.

A preventive measure for stopping many intruders from even trying your network is to install a firewall.

Side effects: Firewalls may be expensive; filtering may slow down the network. If you use a firewall, consider blocking nfs (port 2049/udp) and portmap(111/udp) on your router. The authentication and access controls of these protocols is often minimal. Also you should consider blocking all udp ports except DNS and NTP ports, killing all source routing packets, and killing all IP-forwarding packets.

Acknowledgements

Thanks to the following people for adding and shaping this FAQ:

Tomasz Surmacz <tsurmacz@asic.ict.pwr.wroc.pl>
Wes Morgan (morgan@engr.uky.edu)
Alan Hannan (alan@noc1.mid.net)
Peter Van Epp <vanepp@sfu.ca>
Richard Jones <electron@suburbia.apana.org.au>
Wieste Venema <wietse@wzv.win.tue.nl>
Adrian Rodriguez <adrian@caip.rutgers.edu>
Jill Bowyer <jbowyer@selma.hq.af.mil>
Andy Mell <amell@cup.cam.ac.uk>

Copyright

This paper is Copyright (c) 1994, 1995, 1996
by Christopher Klaus of Internet Security Systems, Inc.

Permission is hereby granted to give away free copies electronically. Electronic dissemination of this information is permitted. All use of the information contained within this document must be referenced. This copyright notice must be maintained in any copy made. If you wish to reprint the whole or any part of this paper in any other medium excluding electronic medium, please ask the author for permission.

Disclaimer

The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk.

Address of Author

Please send suggestions, updates, and comments to:

Christopher Klaus <cklaus@iss.net> of Internet Security Systems, Inc. <iss@iss.net>