home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / hacking / network / 66.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  6.6 KB  |  134 lines
  1.  
  2. ********************************************************************** 
  3. DDN MGT Bulletin 66              DCA DDN Defense Communications System   
  4. 16 Aug 89                        Published by: DDN Network Info Center
  5.                                     (NIC@NIC.DDN.MIL)   (800) 235-3155
  6.  
  7.  
  8.                         DEFENSE  DATA  NETWORK
  9.  
  10.                          MANAGEMENT  BULLETIN
  11.  
  12. The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
  13. Information Center under DCA contract as a means of communicating
  14. official policy, procedures and other information of concern to
  15. management personnel at DDN facilities.  Back issues may be read
  16. through the TACNEWS server ("@n" command at the TAC) or may be
  17. obtained by FTP (or Kermit) from the NIC.DDN.MIL host [26.0.0.73 or
  18. 10.0.0.51] using login="anonymous" and password="guest".  The pathname
  19. for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
  20. bulletin number).
  21. **********************************************************************
  22.  
  23.                  CONFIGURATION MANAGEMENT GUIDELINES
  24.  
  25.  
  26. This bulletin contains guidelines formulated by the Computer Emergency
  27. Response Team (CERT) regarding how to detect whether a UNIX host has
  28. been compromised in a particular manner and how to improve the
  29. security posture of UNIX hosts.  These guidelines were written in
  30. response to specific breakin attempts recently experienced on the
  31. Internet.  A description of the general method used is given below.
  32. There were a few MILNET hosts targetted for breakin attempts.  The
  33. MILNET Host Administrators at these two locations were notified and
  34. have taken corrective action.
  35.  
  36. We ask Host Administrators of gateways between MILNET and local area
  37. networks to promulgate this information to the system administrators
  38. of hosts connected to these local area networks.
  39.  
  40. If you have questions regarding these procedures, please contact your 
  41. vendor or the CERT:
  42.  
  43. Computer Emergency Response Team
  44. CERT@SEI.CMU.EDU
  45. 1-412-268-7090  (24 hour hotline)
  46.  
  47.  
  48. GUIDELINES:
  49.  
  50. Many computers connected to the Internet have recently experienced
  51. unauthorized system activity.  Investigation shows that the activity
  52. has occurred for several months and is spreading.  Several UNIX
  53. computers have had their "telnet" programs illicitly replaced with
  54. versions of "telnet" which log outgoing login sessions (including
  55. usernames and passwords to remote systems).  It appears that access
  56. has been gained to many of the machines which have appeared in some of
  57. these session logs.  (As a first step, frequent telnet users should
  58. change their passwords immediately.)  While there is no cause for
  59. panic, there are a number of things that system administrators can do
  60. to detect whether the security on their machines has been compromised
  61. using this approach and to tighten security on their systems where
  62. necessary.  At a minimum, all UNIX site administrators should do the
  63. following:
  64.  
  65. o Test telnet for unauthorized changes by using the UNIX "strings"
  66.   command to search for path/filenames of possible log files.  Affected
  67.   sites have noticed that their telnet programs were logging information
  68.   in user accounts under directory names such as "..." and ".mail".
  69.  
  70. In general, we suggest that site administrators be attentive to
  71. configuration management issues.  These include the following:
  72.  
  73.  
  74. o Test authenticity of critical programs - Any program with access to
  75.   the network (e.g., the TCP/IP suite) or with access to usernames and
  76.   passwords should be periodically tested for unauthorized changes.
  77.   Such a test can be done by comparing checksums of on-line copies of
  78.   these programs to checksums of original copies.  (Checksums can be
  79.   calculated with the UNIX "sum" command.)  Alternatively, these
  80.   programs can be periodically reloaded from original tapes.
  81.  
  82. o Privileged programs - Programs that grant privileges to users (e.g.,
  83.   setuid root programs/shells in UNIX) can be exploited to gain
  84.   unrestricted access to systems.  System administrators should watch
  85.   for such programs being placed in places such as /tmp and /usr/tmp (on
  86.   UNIX systems).  A common malicious practice is to place a setuid shell
  87.   (sh or csh) in the /tmp directory, thus creating a "back door" whereby
  88.   any user can gain privileged system access.
  89.  
  90. o Monitor system logs - System access logs should be periodically
  91.   scanned (e.g., via UNIX "last" command) for suspicious or unlikely
  92.   system activity.
  93.  
  94. o Terminal servers - Terminal servers with unrestricted network access
  95.   (that is, terminal servers which allow users to connect to and from
  96.   any system on the Internet) are frequently used to camouflage network
  97.   connections, making it difficult to track unauthorized activity.
  98.   Most popular terminal servers can be configured to restrict network
  99.   access to and from local hosts.
  100.  
  101. o Passwords - Guest accounts and accounts with trivial passwords
  102.   (e.g., username=password, password=none) are common targets.  System
  103.   administrators should make sure that all accounts are password
  104.   protected and encourage users to use acceptable passwords as well as
  105.   to change their passwords periodically, as a general practice.  For
  106.   more information on passwords, see Federal Information Processing
  107.   Standard Publication (FIPS PUB) 112, available from the National
  108.   Technical Information Service, U.S. Department of Commerce,
  109.   Springfield, VA 22161.
  110.  
  111. o Anonymous file transfer - Unrestricted file transfer access to a
  112.   system can be exploited to obtain sensitive files such as the UNIX
  113.   /etc/passwd file.  If used, TFTP (Trivial File Transfer Protocol -
  114.   which requires no username/password authentication) should always be
  115.   configured to run as a non-privileged user and "chroot" to a file
  116.   structure where the remote user cannot transfer the system /etc/passwd
  117.   file.  Anonymous FTP, too, should not allow the remote user to access
  118.   this file, or any other critical system file.  Configuring these
  119.   facilities to "chroot" limits file access to a localized directory
  120.   structure.
  121.  
  122. o Apply fixes - Many of the old "holes" in UNIX have been closed.
  123.   Check with your vendor and install all of the latest fixes.
  124.  
  125. If MILNET system administrators do discover any unauthorized system
  126. activity, they are urged to contact the DDN Network Security Officer
  127. or the Computer Emergency Response Team (CERT).  The DDN Network
  128. Security Officer can be contacted by phone through the MILNET Trouble
  129. Desk at 1-800-451-7413 (24 hour hotline) or through e-mail at
  130. DCAB615@DDN1.DCA.MIL.  The CERT can be reached at CERT@SEI.CMU.EDU or by
  131. phone at 1-412-268-7090 (24 hour Hotline).
  132.  
  133.  
  134.