Recovering from an intrusion
The following documents give some suggestions on how to go about
analysing your system to see if it has been compromised:
- Checking Microsoft Windows Systems for Signs of Compromise
- Checking Unix Systems for Signs of Compromise
Detection Checklist from CERT/CC and AusCERT
- Recovering from an incident guidance from CERT/CC
- "Root Kits" and hiding files/directories/processes after a break-in by Dave Dittrich
If you believe one of your systems has been compromised:
- Immediately disconnect the system(s) from the network. This helps to protect the integrity your data, and means that your computer cannot be used to attack anyone else.
- Report the incident to the UCL Computer Security Team. Even if you decide to handle the matter yourself, it's useful for us to receive notification of security incidents, so that we can track trends across the College as a whole.
- Backup the system(s) to preserve a snapshot of the state prior to re-installation - useful in case you forget to copy something you later need, and for evidential purposes.
- Determine the extent of the compromise (see footnote). Are there trust relationships with other systems, which may lead to these other machines also being compromised? Do you have other machines with the same configuration? Do users have the same passwords on several systems? Has the attacker gathered information about other systems by installing network monitoring tools ('sniffers')?
- If possible, determine how the compromise occurred. Clearly there's not much point in rebuilding the system(s) exactly as they were before, as they will be compromised again.
- Do a fresh installation and immediately apply the latest security patches. Most standard installations leave a number of holes, so applying the patches is vital BEFORE reconnecting a machine to the network.
- If you have preserved any file systems (containing user home directories, for example), check that these do not contain malicious or trojan code. Be especially vigilant in regard to code that root may execute - ideally re-compile any binaries that have been carried over.
- Turn off unnecessary services. For example, don't leave mail and ftp servers running if they're not essential. By default many services are installed which are not required - and together these can make a machine vulnerable to a significantly greater range of threats.
- Make sure the services you do need are configured properly and securely. Particular care should be taken with the web server. If you're using Apache, look at the Apache security tips here.
- Use 3rd party tools to enhance baseline security. 'TCP wrappers' limit access to services you do need to run; SSH can replace telnet to provide to encrypt logon sessions and prevent your passwords being sent across the network for all to see; integrity checkers can take snapshots of your critical files and then regularly verify them to ensure they have not been subverted.
- Change all passwords and explain to your users why this has been done. (You don't want them to change them back again, and if they've used them elsewhere they should change those also.)
- Ensure a routine exists for maintaining the machine(s). Make sure security patches are regularly applied as they are released by the manufacturer.
These steps will address only some of the issues you will encounter. The best approach is to make contingency plans before you have a problem - it's much easier to come up with a coherent and sensible strategy if you're not trying to firefight at the same time!
Further references to good practice can be found here.
For checking the integrity of Solaris system binaries, the
Solaris fingerprint database is very valuable. Red Hat Linux
users may perform similar checks using the verify features of rpm. For example,
[/root]# rpm -qf /bin/login util-linux-2.10f-7
to see which package contains the binary, followed by
[/root]# rpm -V util-linux-2.10f-7 S.5....T c /etc/pam.d/login
[/root]# rpm -V -a
to check all installed packages against the locally stored RPM database. However, since this may itself have been subject to tampering, comparison against a trusted source is safer:
rpm -Vvp ftp://mirror.ac.uk/sites/ftp.redhat.com/pub/redhat/redhat-6.2/i386/RedHat/RPMS/util-linux-2.10f-7.i386.rpm
The following list of standard Windows tasklist items may be helpful in identifying rogue processes: