home *** CD-ROM | disk | FTP | other *** search
/ linuxmafia.com 2016 / linuxmafia.com.tar / linuxmafia.com / pub / linux / security / intruder-detection-checklist < prev    next >
PGP Signed Message  |  2000-02-28  |  10KB  |  207 lines
  1. -----BEGIN PGP SIGNED MESSAGE-----
  2. Hash: SHA1
  3.  
  4.  
  5. October 3, 1997    
  6.  
  7. Version 1.2
  8. ftp://info.cert.org/pub/tech_tips/intruder_detection_checklist
  9.  
  10.  
  11.                          CERT(*) Coordination Center
  12.                          Intruder Detection Checklist
  13.  
  14. This document outlines suggested steps for determining if your system has
  15. been compromised. System administrators can use this information to look
  16. for several types of break-ins. We encourage you to review all sections of
  17. this document and modify your systems to close potential weaknesses.
  18.  
  19. In addition to the information in this document, we provide three companion
  20. documents that may help you:
  21.  
  22.         ftp://info.cert.org/pub/tech_tips/UNIX_configuration_guidelines
  23.         - contains suggestions for avoiding common UNIX system
  24.           configuration problems that have been exploited
  25.  
  26.         ftp://info.cert.org/pub/tech_tips/root_compromise
  27.         - contains suggested steps for recovering from a root compromise on
  28.           a UNIX system
  29.  
  30.         ftp://info.cert.org/pub/tech_tips/security_tools
  31.         - contains descriptions of tools that can be used to help secure a
  32.           system and deter break-ins
  33.  
  34. We also encourage you to check with your vendor(s) regularly for any
  35. updates or new patches that relate to your systems.
  36.  
  37. - ------------------------------------------------------------------------------
  38.  
  39. A. Look For Signs That Your System May Have Been Compromised
  40.  
  41. Note that all action taken during the course of an investigation should be
  42. in accordance with your organization's policies and procedures.
  43.  
  44.    1. Examine log files for connections from unusual locations or other
  45.       unusual activity. For example, look at your 'last' log, process
  46.       accounting, all logs created by syslog, and other security logs.
  47.       If your firewall or router writes logs to a different location than the
  48.       compromised system, remember to check these logs also. Note that this is
  49.       not foolproof unless you log to append-only media; many intruders edit
  50.       log files in an attempt to hide their activity.
  51.  
  52.    2. Look for setuid and setgid files (especially setuid root files)
  53.       everywhere on your system. Intruders often leave setuid copies of
  54.       /bin/sh or /bin/time around to allow them root access at a later
  55.       time. The UNIX find(1) program can be used to hunt for setuid and/or
  56.       setgid files. For example, you can use the following commands to find
  57.       setuid root files and setgid kmem files on the entire file system:
  58.  
  59.         find / -user root -perm -4000 -print
  60.         find / -group kmem -perm -2000 -print
  61.  
  62.       Note that the above examples search the entire directory tree,
  63.       including NFS/AFS mounted file systems. Some find(1) commands
  64.       support an "-xdev" option to avoid searching those hierarchies.
  65.       For example:
  66.  
  67.         find / -user root -perm -4000 -print -xdev
  68.  
  69.       Another way to search for setuid files is to use the ncheck(8)
  70.       command on each disk partition. For example, use the following command
  71.       to search for setuid files and special devices on the disk partition
  72.       /dev/rsd0g:
  73.  
  74.         ncheck -s /dev/rsd0g
  75.  
  76.    3. Check your system binaries to make sure that they haven't been
  77.       altered. We've seen intruders change programs on UNIX systems such as
  78.       login, su, telnet, netstat, ifconfig, ls, find, du, df, libc, sync,
  79.       any binaries referenced in /etc/inetd.conf, and other critical
  80.       network and system programs and shared object libraries. Compare the
  81.       versions on your systems with known good copies, such as those from
  82.       your initial installation media. Be careful of trusting backups; your
  83.       backups could also contain Trojan horses.
  84.  
  85.       Trojan horse programs may produce the same standard checksum and
  86.       timestamp as the legitimate version. Because of this, the standard
  87.       UNIX sum(1) command and the timestamps associated with the programs
  88.       are not sufficient to determine whether the programs have been
  89.       replaced. The use of cmp(1), MD5, Tripwire, and other cryptographic
  90.       checksum tools is sufficient to detect these Trojan horse programs,
  91.       provided the checksum tools themselves are kept secure and are not
  92.       available for modification by the intruder. Additionally, you may
  93.       want to consider using a tool (PGP, for example) to "sign" the output
  94.       generated by MD5 or Tripwire, for future reference.
  95.  
  96.    4. Check your systems for unauthorized use of a network monitoring
  97.       program, commonly called a sniffer or packet sniffer. Intruders may
  98.       use a sniffer to capture user account and password information. For
  99.       related information, see CERT advisory CA-94:01 available in
  100.  
  101.     ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks
  102.  
  103.    5. Examine all the files that are run by 'cron' and 'at.' We've seen
  104.       intruders leave back doors in files run from 'cron' or submitted to
  105.       'at.' These techniques can let an intruder back on the system (even
  106.       after you believe you had addressed the original compromise). Also,
  107.       verify that all files/programs referenced (directly or indirectly) by
  108.       the 'cron' and 'at' jobs, and the job files themselves, are not
  109.       world-writable.
  110.  
  111.    6. Check for unauthorized services. Inspect /etc/inetd.conf for
  112.       unauthorized additions or changes. In particular, search for entries
  113.       that execute a shell program (for example, /bin/sh or /bin/csh) and
  114.       check all programs that are specified in /etc/inetd.conf to verify
  115.       that they are correct and haven't been replaced by Trojan horse
  116.       programs.
  117.  
  118.       Also check for legitimate services that you have commented out in
  119.       your /etc/inetd.conf. Intruders may turn on a service that you
  120.       previously thought you had turned off, or replace the inetd program
  121.       with a Trojan horse program.
  122.  
  123.    7. Examine the /etc/passwd file on the system and check for modifications
  124.       to that file. In particular, look for the unauthorized creation of new
  125.       accounts, accounts with no passwords, or UID changes (especially UID 0)
  126.       to existing accounts.
  127.  
  128.    8. Check your system and network configuration files for unauthorized
  129.       entries. In particular, look for '+' (plus sign) entries and
  130.       inappropriate non-local host names in /etc/hosts.equiv, /etc/hosts.lpd,
  131.       and in all .rhosts files (especially root, uucp, ftp, and other system
  132.       accounts) on the system. These files should not be world-writable.
  133.       Furthermore, confirm that these files existed prior to any intrusion and
  134.       were not created by the intruder.
  135.  
  136.    9. Look everywhere on the system for unusual or hidden files (files that
  137.       start with a period and are normally not shown by 'ls'), as these can
  138.       be used to hide tools and information (password cracking programs,
  139.       password files from other systems, etc.). A common technique on UNIX
  140.       systems is to put a hidden directory in a user's account with an unusual
  141.       name, something like '...' or '.. ' (dot dot space) or '..^G' (dot dot
  142.       control-G). Again, the find(1) program can be used to look for hidden
  143.       files, for example:
  144.  
  145.         find / -name ".. " -print -xdev
  146.  
  147.         find / -name ".*" -print -xdev | cat -v
  148.  
  149.       Also, files with names such as '.xx' and '.mail' have been used
  150.       (that is, files that might appear to be normal).
  151.  
  152.   10. Examine all machines on the local network when searching for signs of
  153.       intrusion. Most of the time, if one host has been compromised, others
  154.       on the network have been, too. This is especially true for networks
  155.       where NIS is running or where hosts trust each other through the use
  156.       of .rhosts files and/or /etc/hosts.equiv files. Also, check hosts for
  157.       which your users share .rhosts access.
  158.  
  159.  
  160. B. Review Other CERT Documents
  161.  
  162.    1. For further information about the types of attack that have recently
  163.       been reported to the CERT Coordination Center and for a list of new
  164.       or updated files that are available for anonymous FTP, see our past
  165.       CERT Summaries, available in the directory
  166.  
  167.         ftp://info.cert.org/pub/cert_summaries/
  168.  
  169.    2. If you suspect that your system has been compromised, please review the
  170.       suggested steps in "Steps for Recovering from a UNIX Root Compromise,"
  171.       available from
  172.  
  173.         ftp://info.cert.org/pub/tech_tips/root_compromise
  174.  
  175.       Also review other appropriate files in our tech_tips directory.
  176.  
  177.    3. To report a computer security incident to the CERT Coordination
  178.       Center, please complete and return a copy of our Incident Reporting Form,
  179.       available from
  180.  
  181.         ftp://info.cert.org/pub/incident_reporting_form
  182.  
  183.       The information on the form helps us provide the best assistance, as
  184.       it enables us to understand the scope of the incident, to determine
  185.       if your incident may be related to any other incidents that have been
  186.       reported to us, and to identify trends in intruder activities.
  187.  
  188. - ------------------------------------------------------------------------------
  189.  
  190. Copyright 1996 Carnegie Mellon University. Conditions for use, disclaimers,
  191. and sponsorship information can be found in
  192. http://www.cert.org/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff .
  193. If you do not have FTP or web access, send mail to cert@cert.org with
  194. "copyright" in the subject line.
  195.  
  196. CERT is registered in the U.S. Patent and Trademark Office.
  197.  
  198.  
  199. -----BEGIN PGP SIGNATURE-----
  200. Version: PGP for Personal Privacy 5.0
  201. Charset: noconv
  202.  
  203. iQA/AwUBOBTCfVr9kb5qlZHQEQKHvACg/fxd0TYo7B0VvhArj43i4Vjn2rsAoLEl
  204. Deh4I647J99e0M7GwWvAXTW1
  205. =WQ1m
  206. -----END PGP SIGNATURE-----
  207.