Network & Academic Computing Services
Security

If you have experienced a break-in on a system at UCI, please follow the steps below.

Step One

First, please consider contacting someone in NACS, with e-mail to security@hydra.acs.uci.edu. You could also call x42222. We try to keep a record of all breakins on campus. We won't charge you anything for this!

Please don't just ignore the problem. If someone has broken into your machine, that makes it easier for that person to break into other machines on campus. You may not care about your data, but other people care about their data.

Step Two

Next, decide whether you want to catch the cracker, or just patch things up and get back to your usual work.

If you want to catch the cracker:

• Leave the system alone for now.
• Check your logs for signs of strange activity.
• Set up another computer on the same subnet to do snoop or tcpdump or ethereal or whatever your favorite sniffer is.
• Consider a throw-away script that'll page someone when the cracker accesses your system.

If and when you choose to start patching things up:

First, decide if you want to do a full reinstall with the latest release of OS from your vendor or OS provider. A full reinstall is much more thorough, especially if you haven't used stamp or tripwire long ago.
• If you don't do a full reinstall (this may actually be more work!):
  • /etc/inetd.conf Especially check for strange entries that just start up a shell (/bin/sh, /bin/csh, /bin/bash, whatever)
  • /etc/hosts.equiv You probably want this file to be empty, actually.
  • /etc/passwd Look for accounts that shouldn't be there, or accounts that have had their uid changed (especially, changed to 0, which gives root priviledge)
  • /etc/group Look for normal accounts that suddenly have an extra group, especially a system group. Some system groups can be used
  • Check /etc/exports or /etc/dfs/dfstab to see if any of your filesystems are now exported to strange hosts. This will sometimes be used to create a .rhosts file later.
  • Check all the at and cron jobs on the system.
  • dfmounts, showmount and/or exportfs (if your system has any of these commands), to check for filesystems that are mounted on or exported to other machines. This complements checking /etc/exports and /etc/dfs/dfstab
  • Check system executables for modifications. This is really only feasible if you ran tripwire or stamp in advance. This is one big reason why a full reinstall makes sense for many people.
  • Check /var/spool/calendar for unusual files (if you have a /var/spool/calendar).
• Always do these (whether you do a full reinstall or not):
  • Look for and install all relevant security patches from your vendor or distribution provider
  • Check everybody's ~/.rhosts, including system accounts, especially ~root/.rhosts
  • Check everybody's ~/.forward files. These can be used to regain access.
  • Check everybody's ~/.procmailrc files. These can be used to regain access.
  • Look for strange setuid and setgid executables. One reasonable command for doing this is find / -fstype nfs -prune -o \( -perm -4000 -o -perm -2000 \) -print (Note: this doesn't work on Irix). Run it as root
  • You'll probably need to run crack. This is one of the first things some crackers do, after breaking into a machine - so you want to do it yourself, and get all the poorer passwords changed fast. You might even want to lock accounts with weak passwords. If the machine's accounts are not shadowed, you need to run crack. If root was broken, you need to run crack whether your accounts are shadowed or not. If you're pretty sure root was not broken, and all of your accounts are shadowed, you can skip running crack. You might want to install our yppasswd (the program that maintains NIS-based password files), so your passwords don't get weak again.
  • Consider setting up tcp wrappers if you haven't already. These can be used to drop connections from, EG, specific machines, or all off-campus machines, or even from everything but a small list of trusted machines. If you use linux, tru64 or irix (and probably some others too), you could also implement a similar restriction on your rpcbind/portmap facility. We've found that the version of rpcbind for solaris that does this causes NFS locking problems sometimes.
  • Get in the habit of using ssh or stel (instead of rlogin, telnet or rsh), and sslftp, scp, sftp or SafeTP (instead of regular ftp). These should help prevent crackers from sniffing your passwords on your network.
  • If you're running a web server, make sure that it doesn't run as root (the "top level" one can run as root, but not its children). And scrutinize your CGI scripts. And make sure you're running a current version of the daemon.
  • Finally, please either subscribe to the CERT mailing list (and perhaps BugTraq as well) and keep up to date on security fixes, or harden your machine (possibly by just running toaster), or bring your machine on support so we can do preventative security maintenance for you. Here's a URL about how to apply patches yourself.

References

dcs@uci.edu

Network & Academic Computing Services > Support > Security

Updated: August 6, 2003

University of California, Irvine