Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!thetimes.pixel.kodak.com!news.kodak.com!news-pen-16.sprintlink.net!news.nysernet.net!193.140.62.200!janus.is.ku.edu.tr!news-pen-14.sprintlink.net!news-pull.sprintlink.net!news-in-east.sprintlink.net!206.229.87.25!news-peer.sprintlink.net!news.sprintlink.net!Sprint!howland.erols.net!infeed1.internetmci.com!newsfeed.internetmci.com!newsfeed.randomc.com!wittsend!iss.net!cklaus
From: [email protected] (Christopher Klaus)
Newsgroups: comp.security,alt.security,comp.security.misc,comp.security.unix,comp.unix.admin,comp.answers,alt.answers,news.answers,comp.sys.sun.admin,comp.sys.sgi.admin,comp.security.firewalls
Subject: computer-security/compromise FAQ
Supersedes: <[email protected]>
Followup-To: poster
Date: 28 Jul 1997 19:22:38 GMT
Organization: ISS, Inc.
Lines: 328
Approved: [email protected]
Distribution: world
Message-ID: <[email protected]>
Reply-To: [email protected]
NNTP-Posting-Host: ocean.iss.net
Keywords: security compromise intruder
Originator: [email protected]
Xref: senator-bedfellow.mit.edu alt.security:44977 comp.security.misc:41779 comp.security.unix:40377 comp.unix.admin:67050 comp.answers:27285 alt.answers:27867 news.answers:108339 comp.sys.sun.admin:100900 comp.sys.sgi.admin:53448 comp.security.firewalls:9380

Archive-name: computer-security/compromise-faq
Posting-frequency: monthly
Last-Modified: 1995/4/05
Version: 2.0

Compromise FAQ

Version: 2.0
----------------------------------------------------------------------------
This Security FAQ is a resource provided by:

    Internet Security Systems, Inc.
    Suite 660, 41 Perimeter Center East          Tel: (770) 395-0150
    Atlanta, Georgia 30346                       Fax: (770) 395-1972

----------------------------------------------------------------------------
To get the newest updates of Security files check the following services:

    http://www.iss.net/
    ftp ftp.iss.net /pub/

----------------------------------------------------------------------------

What if your Machines are Compromised by an Intruder.

This FAQ deals with some suggestions for securing your Unix machine after it
has already been compromised. Even if your machines have not been
compromised, there are many helpful tips on securing a machine in this
paper.

 1. Try to trace/follow the intruder back to his origin via looking at

      1. who
      2. w
      3. last
      4. lastcomm
      5. netstat
      6. snmpnetstat
      7. router information.
      8. /var/adm/messages (many crackers send e-mail to their "home"
         accounts)
      9. syslog (sends logs to other hosts as well)
     10. wrapper logs
     11. do a 'finger' to all local users(and check where they last logged
         in from)
     12. history files from shells, such as .history, .rchist, and similiar
         files.

    Footnote: 'who', 'w', 'last', and 'lastcomm' are commands that rely on
    /var/adm/pacct, /usr/adm/wtmp, and /etc/utmp to report the information
    to you. Most backdoors will keep the intruder from being shown in these
    logs. Even if the intruder has not installed any backdoors yet, it is
    trivial to remove any detection in these logs. But they may just forget
    about one or two of them. Especially if you have some additional,
    non-standard ones.

    Suggestion: Install xinetd or tcp_wrapper that will log all connections
    to your machine to see if someone is knocking on its doors. Forward
    syslogs to another machine so intruder will not easily detect the logs
    and modify. Other possibilities: netlog from
    net.tamu.edu:/pub/security.

    It might be wise to monitor the intruder via some ethernet sniffer to
    see how he is exploiting his systems before taking corrective measures.

 2. Close the machine from outside access. Remove from network to stop
    further access via intruder. If the intruder finds out that the
    administrator is unto him, he may try to hide his tracks by rm -rf /.

 3. Check the binaries with the originals. Especially check the following
    binaries because they are commonly replaced backdoors for regaining
    access:

      1. /bin/login
      2. all the /usr/etc/in.* files (ie. in.telnetd)
      3. and /lib/libc.so.* (on Suns).
      4. anything called from inetd

    Other commonly replaced backdoor binaries:

      1. netstat - allows hiding connections
      2. ps - allows hiding processes (ie Crack)
      3. ls - allows hiding directories
      4. ifconfig - hides the fact that promiscuity mode is on the ethernet
      5. sum - fools the checksum for binaries, not necessarily replaced
         anymore because its possible to change the checksum of the
         binaries to the correct value without modifying sum. *EMPHASIZE*
         Do NOT Rely on sum.

    Use 'ls -lac' to find the real modification time of files. Check
    /etc/wtmp (if you still have one) for any system time adjustments.
    Check the files with the distribution media (CD or tape) or calculate
    MD5 checksums and compare them with the originals kept offline (you did
    calculate them sometime ago, didn't you?) Suggestion: cmp the files
    with copies that are known to be good.

    Another popular backdoor is suid'ing a common command (ie. /bin/time)
    to allow root access with regular accounts.

    To find all suid programs you may use:

         find / -type f -perm -4000 -ls

    To be thorough you may need to re-load the entire OS to make sure there
    are no backdoors. Tripwire helps prevent modifying binaries and system
    files (ie. inetd.conf) on the system, without the administrator
    knowing.

 4. Implement some password scheme for your users to verify that they
    change their passwords often. Install anlpasswd, npasswd, or passwd+ in
    place of passwd (or yppasswd) so that your users are forced to set
    reasonable passwords. Then run Crack, which is available on
    ftp.cert.org:/pub/tools/crack to make sure that your users aren't
    bypassing the password check. Crack ensures that users are picking
    difficult passwords. With the network, clear text passwords are a
    problem. Other possible choices: smart hubs (stops ethernet sniffing of
    the whole LAN) and one-time password technology.

 5. Check all the users' .rhosts and .forward files to make sure none of
    them are weird or out of the ordinary. If .rhosts file contains '+ +',
    the account can be accessed anywhere by anyone without a password. COPS
    has a scripts for checking .rhosts.

         find / -name .rhosts -ls -o -name .forward -ls

    Look also for all the files created/modified in the time you are
    suspecting the break-in has taken place, eg:

         find / -ctime -2 -ctime +1 -ls

    To find all the files modified not less than one day ago, but not more
    than 2.

    All .login, .logout, .profile, .cshrc files are also worth looking at
    (at least for the modification date/time). Make sure there are no
    '.rhosts' for the locked or special accounts (like 'news', 'sundiag',
    'sync', etc.) The shell for such accounts should be something like
    '/bin/false' anyway (and not '/bin/sh') to make them more secure. Also
    search for directories that have like ". ", ".. " as names. They are
    usually found in /tmp , /var/tmp, /usr/spool/* and any other publicly
    writeable directory.

 6. Check to make sure your NFS exports are not world writable to everyone.
    NFSwatch available on harbor.ecn.purdue.edu:/pub/davy , a program by
    David Curry, will log any NFS transactions that are taking place. Try
    'showmount -e' to see whether system agrees with your opinion of what
    are you exporting and where. There are bugs in some nfsd
    implementations which ignore the access lists when they exceed some
    limit (256 bytes). Check also what are you IMPORTING!!! Use 'nosuid'
    flag whenever possible. You do not want to be cracked by a sysadm from
    another host (or a cracker there) running suid programs mounted via
    NFS, do you?

 7. Make sure you have implemented the newest sendmail daemon. Old sendmail
    daemons allowed remote execution of commands on any Unix machine. See
    the computer-security/security-patch FAQ.

 8. Try to install all the security patches available from the vendor on
    your machine. See the computer-security/security-patch FAQ.

 9. Here is a check list of common ways that a machine is vulnerable:

      1. Do an rpcinfo -p on your machine to make sure it is not running
         any processes that are not needed. (ie. rexd).

      2. Check for '+' in /etc/hosts.equiv.

      3. Check whether tftp is disabled on your system. If not - disable
         it, or at least use '-s' flag to chroot it to some safe area, if
         you really can't live without it (it is mostly used for booting up
         Xterminals, but sometimes can be avoided by NFS-mounting
         appropriate disks). Under no circumstances you should run it as
         root. Change the line describing it in /etc/inetd.conf to
         something like:

              tftp dgram udp wait nobody /usr/etc/in.tftpd in.tftpd -s
              /tftpboot

         or better yet, use tcpd wrapper program to protect it from
         addresses which should not get access to tftp and log all other
         connections:

              tftp dgram udp wait nobody /usr/etc/tcpd in.tftpd -s
              /tftpboot

         and edit appropriately /etc/hosts.allow to restrict access to
         in.tftpd to only those addresses that really need it.

      4. Check crontabs and at-jobs. Make sure there are no delayed bombs
         which will explode after you think you have got rid of all the
         nasty things left by a intruder.

      5. Check /etc/rc.boot /etc/rc.local (SYSV: /etc/rc?.d/* ) and other
         files cruicial for the system startup. (The best would be if you
         could compare them with the copies kept off-line). Check all other
         files containing system configuration (sendmail.cf, sendmail.fc,
         hosts.allow, at.allow, at.deny, cron.allow, hosts, hosts.lpd,
         etc.) In 'aliases' look for aliases expanding to some unusual
         programs (uudecode is one but example).

      6. Check your inetd.conf and /etc/services files to find if there are
         no additional services set up by an intruder.

      7. Copy all the log files you still have (pacct, wtmp, lastlog,
         sulog, syslog, authlog, any additional logs you have set up
         earlier) to some safe place (offline) so you may examine them
         later. Otherwise, do not be surprised if they disappear the next
         day when the cracker realises he forgot to remove one of them. Use
         your own imagination to find what other traces he could have left
         in your system (What about /tmp/* files? Check them BEFORE you
         reboot).

      8. Make backup copy of /etc/passwd (best offline) then change all
         root passwords (after verifying that 'su' and 'passwd' are not the
         trojan versions left by an intruder). It may sound like a horrible
         thing to do (especially if you have something like 2000 users) but
         *do* lock them all by putting '*' in the password field. If the
         intruder has a copy of your passwords file he may possibly sooner
         or later guess all the passwords contained there (It is all the
         matter of proper dictionaries). In fact he could have inserted few
         passwords that he only knows for some users who for example have
         not logged in for a long time.

         On the NIS servers check not only the real /etc/passwd /etc/groups
         etc files but also those used for building NIS maps (if they are
         different).

      9. Check if your anonymous ftp (and other services) are configured
         properly (if you have any of course) See the
         computer-security/anonymous-ftp FAQ.

     10. If you want to make your life easier next time (or if you still
         cannot get rid of an intruder) consider installing 'ident' daemon.
         Together with tcpd on a set of hosts it can be used to find what
         accounts the intruder is using.

     11. Make sure the only 'secure' terminal is console (if at all). This
         way you prevent root logins just from the net. Maybe it is not a
         big deal as if somebody knows the root password he may already
         know other peoples' passwords too, but maybe not?

     12. Check hosts.equiv, .rhosts, and hosts.lpd for having # as comments
         within those files. If an intruder changes his hostname to #, it
         will be considered a trusted host and allow him to access your
         machines.

     13. And remember... There are so many ways that somebody could have
         modified your system, that you really have to have your eyes and
         ears wide open for a loooooong long time. Above, are the pointers
         just to the most obvious things to check.

10. Mail all the sites that you were able to find out that the intruder was
    going through and warn them. Also, CC: [email protected]. Check all the
    sites in your near-by, ie. in your domain/institution/whatever. It's
    usually trivial for a hacker to get to another system by a simple
    'rlogin' if the two systems have a common subset of users (and using
    .rhosts to make the access easier).

11. A preventive from stopping many intruders from even trying your network
    is to install a firewall.

    Side-effects: Firewalls may be expensive; filtering may slow down the
    network. Consider blocking nfs (port 2049/udp) and portmap(111/udp) on
    your router. The authentication and access controls of these protocols
    is often minimal. Suggestion: Block all udp ports except DNS and NTP
    ports. Kill all source routing packets. Kill all ip-forwarding packets.

Acknowledgements

Thanks to the following people for adding and shaping this FAQ:

Tomasz Surmacz <[email protected]>
Wes Morgan ([email protected])
Alan Hannan ([email protected])
Peter Van Epp <[email protected]>
Richard Jones <[email protected]>
Wieste Venema <[email protected]>
Adrian Rodriguez <[email protected]>
Jill Bowyer <[email protected]>
Andy Mell <[email protected]>

----------------------------------------------------------------------------

Copyright

This paper is Copyright (c) 1994, 1995, 1996
  by Christopher Klaus of Internet Security Systems, Inc.

Permission is hereby granted to give away free copies electronically. You
may distribute, transfer, or spread this paper electronically. You may not
pretend that you wrote it. This copyright notice must be maintained in any
copy made. If you wish to reprint the whole or any part of this paper in any
other medium excluding electronic medium, please ask the author for
permission.

Disclaimer

The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There are
NO warranties with regard to this information. In no event shall the author
be liable for any damages whatsoever arising out of or in connection with
the use or spread of this information. Any use of this information is at the
user's own risk.

Address of Author

Please send suggestions, updates, and comments to:
Christopher Klaus <[email protected]> of Internet Security Systems, Inc.
<[email protected]>

Internet Security Systems, Inc.

ISS is the leader in network security tools and technology through
innovative audit, correction, and monitoring software. The Atlanta-based
company's flagship product, Internet Scanner, is the leading commercial
attack simulation and security audit tool. The Internet Scanner SAFEsuite is
based upon ISS' award-winning Internet Scanner and was specifically designed
with expanded capabilities to assess a variety of network security issues
confronting web sites, firewalls, servers and workstations. The Internet
Scanner SAFEsuite is the most comprehensive security assessment tool
available. For more information about ISS or its products, contact the
company at (770) 395-0150 or e-mail at [email protected]. ISS maintains a Home
Page on the World Wide Web at http://www.iss.net
--
Christopher William Klaus            Voice: (770)395-0150. Fax: (770)395-1972
Internet Security Systems, Inc.              "Internet Scanner SAFEsuite finds
Ste. 660,41 Perimeter Center East,Atlanta,GA 30346 your network security holes
Web: http://www.iss.net/  Email: [email protected]        before the hackers do."

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.