|
Signs That Your System Might Have Been Compromised
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
Look For Signs That Your System May Have Been Compromised
Note that all action taken during the course of an investigation
should be in accordance with your organization's policies and
procedures.
1.Examine log files for connections from unusual locations or other
unusual activity. For example, look at your 'last' log, process
accounting, all logs created by syslog, and other security logs. If
your firewall or router writes logs to a different location than the
compromised system, remember to check these logs also. Note that
this is not foolproof unless you log to append-only media; many
intruders edit log files in an attempt to hide their activity.
2.Look for setuid and setgid files (especially setuid root files)
everywhere on your system. Intruders often leave setuid copies of
/bin/sh or /bin/time around to allow them root access at a later time.
The UNIX find(1) program can be used to hunt for setuid and/or
setgid files. For example, you can use the following commands to
find setuid root files and setgid kmem files on the entire file
system:
find / -user root -perm -4000 -print
find / -group kmem -perm -2000 -print
Note that the above examples search the entire directory tree,
including NFS/AFS mounted file systems. Some find(1) commands
support an "-xdev" option to avoid searching those hierarchies. For
example:
find / -user root -perm -4000 -print -xdev
Another way to search for setuid files is to use the ncheck(8)
command on each disk partition. For example, use the following
command to search for setuid files and special devices on the disk
partition /dev/rsd0g:
ncheck -s /dev/rsd0g
3.Check your system binaries to make sure that they haven't been
altered. We've seen intruders change programs on UNIX systems
such as login, su, telnet, netstat, ifconfig, ls, find, du, df, libc, sync,
any binaries referenced in /etc/inetd.conf, and other critical
network and system programs and shared object libraries. Compare
the versions on your systems with known good copies, such as
those from your initial installation media. Be careful of trusting
backups; your backups could also contain Trojan horses.
Trojan horse programs may produce the same standard checksum
and timestamp as the legitimate version. Because of this, the
standard UNIX sum(1) command and the timestamps associated
with the programs are not sufficient to determine whether the
programs have been replaced. The use of cmp(1), MD5, Tripwire,
and other cryptographic checksum tools is sufficient to detect these
Trojan horse programs, provided the checksum tools themselves are
kept secure and are not available for modification by the intruder.
Additionally, you may want to consider using a tool (PGP, for
example) to "sign" the output generated by MD5 or Tripwire, for
future reference.
4.Check your systems for unauthorized use of a network
monitoring program, commonly called a sniffer or packet sniffer.
Intruders may use a sniffer to capture user account and password
information. For related information, see CERT advisory CA-94:01
available in
ftp://info.cert.org/pub/cert_advisories/CA-
94:01.network.monitoring.attacks
5.Examine all the files that are run by 'cron' and 'at.' We've seen
intruders leave back doors in files run from 'cron' or submitted to
'at.' These techniques can let an intruder back on the system (even
after you believe you had addressed the original compromise).
Also, verify that all files/programs referenced (directly or
indirectly) by the 'cron' and 'at' jobs, and the job files themselves,
are not world-writable.
6.Check for unauthorized services. Inspect /etc/inetd.conf for
unauthorized additions or changes. In particular, search for entries
that execute a shell program (for example, /bin/sh or /bin/csh) and
check all programs that are specified in /etc/inetd.conf to verify that
they are correct and haven't been replaced by Trojan horse
programs.
Also check for legitimate services that you have commented out in
your /etc/inetd.conf. Intruders may turn on a service that you
previously thought you had turned off, or replace the inetd program
with a Trojan horse program.
7.Examine the /etc/passwd file on the system and check for
modifications to that file. In particular, look for the unauthorized
creation of new accounts, accounts with no passwords, or UID
changes (especially UID 0) to existing accounts.
8.Check your system and network configuration files for
unauthorized entries. In particular, look for '+' (plus sign) entries
and inappropriate non-local host names in /etc/hosts.equiv,
/etc/hosts.lpd, and in all .rhosts files (especially root, uucp, ftp, and
other system accounts) on the system. These files should not be
world-writable. Furthermore, confirm that these files existed prior
to any intrusion and were not created by the intruder.
9.Look everywhere on the system for unusual or hidden files (files
that start with a period and are normally not shown by 'ls'), as these
can be used to hide tools and information (password cracking
programs, password files from other systems, etc.). A common
technique on UNIX systems is to put a hidden directory in a user's
account with an unusual name, something like '...' or '.. ' (dot dot
space) or '..^G' (dot dot control-G). Again, the find(1) program can
be used to look for hidden files, for example:
find / -name ".. " -print -xdev
find / -name ".*" -print -xdev | cat -v
Also, files with names such as '.xx' and '.mail' have been used (that
is, files that might appear to be normal).
10.Examine all machines on the local network when searching for
signs of intrusion. Most of the time, if one host has been
compromised, others on the network have been, too. This is
especially true for networks where NIS is running or where hosts
trust each other through the use of .rhosts files and/or
/etc/hosts.equiv files. Also, check hosts for which your users share
.rhosts access.
Review Other CERT Documents
1.For further information about the types of attack that have
recently been reported to the CERT Coordination Center and for a
list of new or updated files that are available for anonymous FTP,
see our past CERT Summaries, available in the directory
ftp://info.cert.org/pub/cert_summaries/
2.If you suspect that your system has been compromised, please
review the suggested steps in "Steps for Recovering from a UNIX
Root Compromise," available from
ftp://info.cert.org/pub/tech_tips/root_compromise
Also review other appropriate files in our tech_tips directory.
3.To report a computer security incident to the CERT Coordination
Center, please complete and return a copy of our Incident
Reporting Form, available from
ftp://info.cert.org/pub/incident_reporting_form
The information on the form helps us provide the best assistance, as
it enables us to understand the scope of the incident, to determine
if your incident may be related to any other incidents that have been
reported to us, and to identify trends in intruder activities.
------------------------------------------------------------------------
Copyright 1996 Carnegie Mellon University
This material may be reproduced and distributed without
permission provided it is used for noncommercial purposes and the
copyright statement is included.
CERT is a service mark of Carnegie Mellon University.
The CERT Coordination Center is sponsored by the Defense
Advanced Research Projects Agency (DARPA). The Software
Engineering Institute is sponsored by the U.S. Department of
Defense.
|
|
