|
|
 |
|
|
|
register |
bbs |
search |
rss |
faq |
about
|
|
|
meet up |
add to del.icio.us |
digg it
|
|
|
|
Recovering from a UNIX Root Compromise
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.
Steps for Recovering from a UNIX Root Compromise
This document sets out suggested steps for responding to a root compromise.
Your response should be carried out in several stages:
A. Look For the Extent of the Intrusion.
1. Look for modifications made to system software and configuration files.
2. Look for tools installed by the intruder.
3. Similarly check other local systems.
4. Check for systems at remote sites that may be involved or affected.
B. Recover from the Intrusion.
1. Regain control.
- Disconnect from the network if necessary. Copy log files.
- Review log files, check binaries & config files.
2. Undo intruder modifications and install a clean system.
3. Contact the sites identified in A.4.
C. Secure Your Systems.
1. Install all system security patches.
2. Consult CERT advisories, summaries, and vendor-initiated bulletins.
3. Install security tools.
4. Enable logging.
5. Configure firewalls to defend networks.
6. Review security using our UNIX configuration guidelines.
7. Change all passwords.
8. Reconnect to the Internet.
9. Complete a CERT incident reporting form.
In addition to the information in this document, we provide three other
companion documents that may help you:
ftp://info.cert.org/pub/tech_tips/UNIX_configuration_guidelines
- contains suggestions for avoiding common UNIX system
configuration problems that have been exploited
ftp://info.cert.org/pub/tech_tips/intruder_detection_checklist
- contains suggestions for determining if your system may have
been compromised
ftp://info.cert.org/pub/tech_tips/security_tools
- contains descriptions of tools that can be used to help secure a
system and deter break-ins
- -------------------------------------------------------------------------------
A. Look For the Extent of the Intrusion.
Note that all action taken during the course of an investigation should be
in accordance with your organization's policies and procedures.
1. Look for modifications made to system software and configuration files.
Verify all system files such as binaries and configuration files.
We urge you to thoroughly check all your system binaries against
distribution media and the latest available patches for Trojan horse
programs. Additionally, verify your configuration files against
copies that you know to be unchanged. We have seen an extensive range
of Trojan horse binaries installed by intruders, including login, su,
telnet, in.telnetd, ftp, ls, ps, netstat, ifconfig, find, du, df,
libc, sync, inetd, and syslogd. Also check any binaries referenced in
/etc/inetd.conf, and other critical network and system programs and
shared object libraries.
Because some Trojan horse programs could have the same timestamps as
the original binaries and give the correct sum(1) values, we
recommend you use cmp(1) to make a direct comparison of the binaries
and the original distribution media.
Alternatively, you can check the MD5 results on suspect binaries
against a list of MD5 checksums from known good binaries. Ask your
vendor if they make MD5 checksums available for their distribution
binaries.
In addition, tools such as Tripwire can archive MD5 checksums of
known good binaries when used immediately after a system
installation. If you use Tripwire, you should regularly maintain the
checksums on removable or read-only media. For more details on
Tripwire and MD5, see
ftp://info.cert.org/pub/tech_tips/security_tools
2. Look for tools installed by the intruder.
When intruders compromise a system, there is always the potential for
them to install custom-made tools for continued monitoring or
continued access to the compromised system through Trojan horses and
packet sniffers. We encourage you to search thoroughly for such
tools.
In particular, when a root compromise occurs, there is the potential
for intruders to install a network monitoring program, commonly
called a sniffer (or packet sniffer), to capture user account and
password information. In addition to the file checking we suggest in
step A.1., we encourage you to review CERT advisory CA-94:01,
available from
ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks
The advisory includes a description of sniffer activity and suggested
approaches for addressing this problem. There is more information about
packet sniffers and other sites in step B.3.
3. Similarly check other local systems.
We encourage you to check all of your systems, not just those that
you know to be compromised. Include in your check any systems
associated with the compromised system through shared network-based
services (such as NIS and NFS) or through any method of trust (such
as systems in hosts.equiv or .rhosts files, or a Kerberos server).
4. Check for systems at remote sites that may be involved or affected.
We encourage you examine log files, intruder output files, and any
files modified or created during and since the time of the intrusion.
Look for information that leads you to suspect that another site may
be linked with the compromise. We often find that other sites linked
to a compromise (whether upstream or downstream of the compromise)
have often themselves been victims of a compromise. It is therefore
important that any other potential victim sites are identified and
notified as soon as possible. More details about contacting sites are
in step B.3.
B. Recover from the Intrusion.
Note that when following the steps below, you should also keep in mind the
steps you will take in Section C, "Secure Your Systems."
1. Regain control.
To regain control of your system, you may need to disconnect it from
the network or operate in single-user mode temporarily. These steps
keep users and intruders from accessing the system.
With your system disconnected from the network, you can now
thoroughly review log files and configuration files for intruder
modifications, signs of intrusion, and configuration weaknesses.
We recommend that you make copies of all files identified as being of
interest from steps A.1., A.2. and A.3. Retain these copies for
future reference.
(If any files might be needed later for a legal investigation, make a
"level 0" dump of the file system; label, sign, and date the dump;
and keep the dump in a secure location to maintain and preserve the
integrity of the evidence while it is in your custody.)
We can help you recover from this intrusion by offering technical
advice when possible and helping you coordinate with other sites.
2. Undo intruder modifications and install a clean system.
We encourage you to restore your system using known, clean binaries.
If restoring from a backup, ensure that the backup itself is from an
uncompromised machine. (Keep in mind that you could re-introduce a
vulnerability that would allow an intruder to gain unauthorized
access.) If you have any doubts, re-install the operating system
using the original distribution media.
Try to identify and remove (or patch) any vulnerability used to gain
access. Ensure that all relevant security patches are applied to the
restored system, and install all applicable security tools (see
sections C.1. and C.3. below).
Configure your system to offer only the network services that the
system is intended to offer, and no others. Check to ensure that
there are no weaknesses in the configuration files for those
services, and that those services are available only to the intended
set of other systems.
Take an MD5 checksum snapshot of the newly restored system using a
tool such as Tripwire.
3. Contact the sites identified in A.4.
* What to tell sites:
If you find any evidence of compromise or intruder activity at any
other sites during the activities described in step A.4., contact
those sites. Tell them what you have found, explain that this may
be a sign of compromise or intruder activity at their site, and
suggest that they may wish to take steps to determine if/how the
compromise occurred and prevent a recurrence.
We would appreciate a Cc to [email protected] on any correspondence. If
you like, you can let the site know that you are working with us on
on this incident (please include the assigned CERT tracking number
in the subject line of your messages). Also let them know that we
can offer assistance on how to recover from the compromise.
* How to get contact information:
If you need contact information for a particular site, we encourage
you to use the InterNIC's whois database. For help in doing so, you
may want to consult
ftp://info.cert.org/pub/whois_how_to
You may also want to check the contacts list of the Forum of
Incident Response and Security Teams (FIRST), available in
ftp://info.cert.org/pub/FIRST/first-contacts
http://www.first.org/team-info/team-contact
If you are still unsure of a site or contact details, please get in
touch with us.
* How to mail password files:
If you include a password file in a mail message, ensure that you
do not further propagate passwords traversing the Internet in
cleartext. You can do this by stripping the passwords from the
original files using the following script:
% awk -F: '{ print $1":(deleted):"$3":"$4":"$5":"$6":"$7 }' \
$file > $file.stripped
If you need any assistance in identifying the site to which a
password file belongs, please contact us.
* What to do about packet sniffers:
If you find that a packet sniffer has been installed on your
systems, we strongly urge you to examine the output file from the
sniffer to determine what other machines are at risk. Machines at
risk are those that appear in the destination field of a captured
packet. You can quickly obtain a list of these machines by
executing the following command:
% grep PATH: $sniffer_log_file | awk '{print $4}' | \
awk -F\( '{print $1}'| sort -u
Note that the above command works with many packet sniffers that we
have seen. It is based on the assumption that first two lines for
each logged packet appear in the packet sniffer output log as:
-- TCP/IP LOG -- TM: Tue Nov 15 15:12:29 --
PATH: not_at_risk.foo.edu(1567) => at_risk.foo.edu(telnet)
You may need to adjust the command for your particular case.
You should be aware that there may be other machines at risk in
addition to the ones that appear in the sniffer log. This may be
because the intruder has obtained previous sniffer logs from your
systems, or through other attack methods.
Please send us a list of all hosts you know to be affected; this
helps us determine the scope of the problem.
C. Secure Your Systems.
1. Install all system security patches.
We strongly encourage you to ensure that each of your systems has the
full set of security patches. This is a major step in defending your
systems from attack, and its importance cannot be overstated. We
recommend that you contact your vendor for a list of the latest
available security patches and instructions for obtaining them.
2. Consult CERT advisories, summaries, and vendor-initiated bulletins.
We encourage you to consult past CERT advisories, summaries, and
vendor-initiated bulletins, and follow the instructions that are
relevant to your particular configuration. Be sure that you have
installed all applicable patches or workarounds described in the CERT
publications, including the broadly applicable advisories on services
such as rdist, tftp, ftpd, httpd (World Wide Web), anonymous FTP, NFS,
and sendmail.
Remember to check the advisories periodically to ensure that
you have the most current information.
Past CERT advisories are available from
ftp://info.cert.org/pub/cert_advisories/
An index of all advisories is in the 01-README file in that
directory.
Past CERT summaries are available from
ftp://info.cert.org/pub/cert_summaries/
Vendor-initiated bulletins are available from
ftp://info.cert.org/pub/cert_bulletins/
An index of all the vendor-initiated bulletins is in the 01-README
file in that directory.
3. Install security tools.
Consider using some of the software security tools that are available,
such as Tripwire, COPS, and the TCP wrapper package. See
ftp://info.cert.org/pub/tools/
ftp://info.cert.org/pub/tech_tips/security_tools
Please browse through the other information in our FTP archive
(ftp://info.cert.org/pub/) for other tools and information.
4. Enable logging.
Make sure that logging/auditing/accounting programs are enabled (for
example, process accounting) and that they are set to an appropriate
level (for example, sendmail logging should be level 9 or higher).
Backup your logs, and/or consider writing your logs to a different
machine or a secure logging host.
5. Configure firewalls to defend networks.
Consider filtering certain TCP/IP services at your firewall or
router. For some suggestions, please refer to "Packet Filtering for
Firewall Systems," available from
ftp://info.cert.org/pub/tech_tips/packet_filtering
6. Review security using our UNIX configuration guidelines.
To help you assess the security of your system(s), please refer to our
UNIX configuration guidelines and our security tools document, which
may be useful to you in checking your system for vulnerabilities that
are often exploited by intruders. The guidelines are available from
ftp://info.cert.org/pub/tech_tips/UNIX_configuration_guidelines
and the list of security tools is available from
ftp://info.cert.org/pub/tech_tips/security_tools
7. Change all passwords.
After all security holes or configuration problems have been patched
or corrected, we suggest that you change the passwords of ALL
accounts on the affected system(s). Ensure that passwords for all
accounts are not easy to guess. You may want to consider using
vendor-supplied or third-party tools to enforce your password
policies.
8. Reconnect to the Internet.
If you disconnected from the Internet, the best time to reconnect is
after you have completed all the steps listed above.
9. Complete a CERT incident reporting form.
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.
|
|
|
To the best of our knowledge, the text on this page may be freely reproduced and distributed.
If you have any questions about this, please check out our Copyright Policy.
totse.com certificate signatures
|
|
|
About | Advertise | Bad Ideas | Community | Contact Us | Copyright Policy | Drugs | Ego | Erotica
FAQ | Fringe | Link to totse.com | Search | Society | Submissions | Technology
|
|
|
|
|
|
