home *** CD-ROM | disk | FTP | other *** search
/ linuxmafia.com 2013 / 2013.06.linuxmafia.com / linuxmafia.com / pub / linux / security / unix-configuration-guidelines < prev    next >
PGP Signed Message  |  2000-02-29  |  15KB  |  328 lines
  1. -----BEGIN PGP SIGNED MESSAGE-----
  2. Hash: SHA1
  3.  
  4.  
  5. October 2, 1997
  6. Version 1.2
  7. ftp://info.cert.org/pub/tech_tips/UNIX_configuration_guidelines
  8.  
  9.  
  10.                        CERT(*) Coordination Center
  11.                        UNIX Configuration Guidelines
  12.  
  13.  This document describes common UNIX system configuration problems that have
  14.  been exploited by intruders and recommends practices that can be used to
  15.  help deter several types of break-ins. We encourage system administrators
  16.  to review all sections of this document and modify their systems to fix
  17.  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/intruder_detection_checklist
  23.      - contains suggestions for determining if your system may have
  24.        been compromised
  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.  Also, please see our CERT advisory 01-README file and CERT vendor-initiated
  35.  bulletin 01-README file, which contain brief descriptions of all past CERT
  36.  advisories and vendor-initiated bulletins. These files are available from
  37.  
  38.      ftp://info.cert.org/pub/cert_advisories/01-README
  39.      ftp://info.cert.org/pub/cert_bulletins/01-README
  40.  
  41.  We encourage you to get all advisories that pertain to your system(s),
  42.  and to install the patches or workarounds described in the advisories.
  43.  We also encourage you to check with your vendor(s) regularly for any
  44.  updates or new patches that relate to your systems.
  45.  
  46.  -------------------------------------------------------------------------------
  47.  
  48.  Common UNIX System Configuration Problems That Are Exploited
  49.  
  50.     1. Weak passwords
  51.  
  52.        Intruders often use finger or ruser to discover account names and
  53.        then try to guess passwords. Encourage your users to choose passwords
  54.        that are difficult to guess (for example, words that are not in any
  55.        dictionary of any language; no proper nouns, including names of "famous"
  56.        real or fictitious characters; no acronyms that are commonly used by
  57.        computer professionals; no simple variations of first or last names.)
  58.        Furthermore, inform your users not to leave any cleartext
  59.        username/password information in files on any system.
  60.  
  61.        A good heuristic for choosing a password is to choose an
  62.        easy-to-remember phrase, such as "By The Dawn's Early Light", and use
  63.        the first letters to form a password. Add some punctuation or mix
  64.        case letters as well. For the phrase above, one example password
  65.        might be: bt}DeL{. (DO NOT use this sample phrase for your password.)
  66.  
  67.        If intruders can get a password file, they usually move or copy it to
  68.        another machine and run password-guessing programs on it. These programs
  69.        involve large dictionary searches, and they run quickly even on slow
  70.        machines. Most systems that do not put any controls on the type of
  71.        passwords used probably have at least one password that can be easily
  72.        guessed.
  73.  
  74.        If you believe that your password file may have been taken, change
  75.        all the passwords on the system. At the very least, you should change
  76.        all system passwords because an intruder may concentrate on those and
  77.        may be able to guess even a reasonably "good" password. Intruders
  78.        often use compromised accounts to attempt to gain privileged access
  79.        on vulnerable systems, so we encourage you to follow the steps in
  80.  
  81.      ftp://info.cert.org/pub/tech_tips/intruder_detection_checklist
  82.      ftp://info.cert.org/pub/tech_tips/root_compromise
  83.  
  84.        For further information about protecting your system from password-
  85.        based attacks, see
  86.  
  87.      ftp://info.cert.org/pub/tech_tips/passwd_file_protection
  88.  
  89.     2. Accounts without passwords or default passwords
  90.  
  91.        Intruders exploit system default passwords that have not been changed
  92.        since installation, including accounts with vendor-supplied default
  93.        passwords. Be sure to change all default passwords when the software
  94.        is installed. Also, be aware that product upgrades can quietly change
  95.        account passwords to a new default. It is best to change the passwords
  96.        of default accounts after applying updates.
  97.  
  98.        Scan your password file for extra UID 0 accounts, accounts with no
  99.        password, or new entries in the password file. Do not allow any
  100.        accounts without passwords. Remove entries for unused accounts from
  101.        the password file. To disable an account, change the password field
  102.        in the /etc/passwd file to an asterisk '*' and change the login shell
  103.        to /bin/false to ensure that an intruder cannot login to the account
  104.        from a trusted system on the network.
  105.  
  106.     3. Reusable passwords
  107.  
  108.        Even excellent passwords are not safe. They can be captured by programs
  109.        such as packet sniffers if the passwords are sent across networks in
  110.        cleartext (whether on a subnet, a local network, or the Internet).
  111.        We recommend using one-time passwords, especially for authenticated
  112.        access from external networks and for access to sensitive resources
  113.        like name servers and routers. For more information, see Appendix B of
  114.        the following advisory:
  115.  
  116.      ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks
  117.  
  118.     4. Use of TFTP (Trivial File Transfer Protocol) to obtain password files
  119.  
  120.        To test your system for this vulnerability, connect to your system
  121.        using tftp and try
  122.  
  123.      get /etc/motd
  124.  
  125.        If you can do this, anyone else on the network can probably get your
  126.        password file. To avoid the problem, disable tftpd. If you must have
  127.        tftpd, ensure that it is configured with restricted access. For further
  128.        information, see
  129.  
  130.    ftp://info.cert.org/pub/cert_advisories/CA-91:18.Active.Internet.tftp.Attacks
  131.  
  132.        As mentioned in Section 1 above, if you believe your password file
  133.        may have been taken, the safest course is to change all passwords in
  134.        the system.
  135.  
  136.     5. Vulnerabilities in sendmail
  137.  
  138.        There have been a number of vulnerabilities identified over the years
  139.        in sendmail(8). To the best of our knowledge, the current version of
  140.        sendmail addresses those known vulnerabilities.
  141.  
  142.        To determine which version of sendmail is running, use telnet to connect
  143.        to the SMTP port (25) on your system:
  144.  
  145.      telnet <your hostname> 25
  146.  
  147.        We encourage you to keep up to date with the latest version of sendmail
  148.        from your vendor, and ensure that it is up to date with security patches
  149.        or workarounds detailed in CERT advisories and bulletins. For
  150.        information about the latest version of sendmail, see
  151.  
  152.      ftp://info.cert.org/pub/latest_sw_versions/sendmail
  153.  
  154.        In addition, we encourage you to use the following tools, both of which
  155.        are distributed with the latest versions of sendmail:
  156.  
  157.        (a) smrsh, the sendmail restricted shell, controls the way that
  158.        incoming mail messages can interact with your operating system.
  159.        For instance, when configured correctly, smrsh can prevent an
  160.        intruder from using pipes to execute arbitrary commands on your
  161.        system.
  162.  
  163.        (b) mail.local can be used to control the way in which the /bin/mail
  164.        program is used on your system. This tool is described in CERT
  165.        advisory CA-95:02.
  166.  
  167.     ftp://info.cert.org/pub/cert_advisories/CA-95:02.binmail.vulnerabilities
  168.  
  169.        If you are not running a recent version of sendmail, the above tools
  170.        may also be obtained individually from a number of sources, including
  171.  
  172.      ftp://info.cert.org/pub/tools/mail.local/
  173.      ftp://info.cert.org/pub/tools/smrsh/
  174.  
  175.        Warning: If you are running such an old version of sendmail that you
  176.         must install these tools separately, intruders will continue to
  177.         be able to exploit vulnerabilities that were fixed in later
  178.         versions of sendmail. We urge you to upgrade to the current
  179.         version of sendmail mail and then run the tools, which are
  180.         included with the distribution.
  181.  
  182.     6. Misconfigured anonymous FTP
  183.  
  184.        In addition to making sure that you are running the most recent
  185.        version of ftpd, check your anonymous FTP configuration. It is
  186.        important to follow the instructions provided with the operating
  187.        system to properly configure the files and directories available
  188.        through anonymous FTP (for example, file and directory permissions,
  189.        ownership and group). Note that you should not use your system's
  190.        standard password file or group file as the password file or group
  191.        file for FTP. The anonymous FTP root directory and its two
  192.        subdirectories, etc and bin, should not be owned by ftp. For more
  193.        information about configuring anonymous FTP, see
  194.  
  195.      ftp://info.cert.org/pub/tech_tips/anonymous_ftp_config
  196.  
  197.     7. Inappropriate network configuration file entries
  198.  
  199.        Several vendors supply /etc/hosts.equiv files with a '+' (plus sign)
  200.        entry. The '+' entry should be removed from this file because it
  201.        means that your system will trust all other systems. Other files that
  202.        should not contain a '+' entry include all .rhosts files on the
  203.        system. These files should not be world-writable.
  204.  
  205.        If your /usr/lib/X11/xdm/Xsession file includes an 'xhost' command
  206.        with a '+' entry, such as
  207.  
  208.      /usr/bin/X11/xhost +
  209.  
  210.        remove that line. (Note that the 'xhost' command may be in a
  211.        different directory tree on your system.) If such a line remains
  212.        intact, anyone on the network can talk to the X server and
  213.        potentially insert commands into windows or read console keystrokes.
  214.  
  215.     8. Inappropriate 'secure' settings in /etc/ttys and /etc/ttytab
  216.  
  217.        Check the file /etc/ttys or /etc/ttytab (depending on the release of
  218.        UNIX being used). The ONLY terminal that should be set to 'secure'
  219.        should be the console.
  220.  
  221.     9. Inappropriate entries in /etc/aliases (or /usr/lib/aliases)
  222.  
  223.        Examine the /etc/aliases (or /usr/lib/aliases) mail alias file for
  224.        inappropriate entries. Some alias files include an alias named
  225.        'uudecode' or just 'decode.' If this alias exists on your system and
  226.        you are not explicitly using it, then you should remove it.
  227.  
  228.    10. Inappropriate file and directory protections
  229.  
  230.        Check your system documentation to establish the correct file and
  231.        directory protections and ownership for system files and directories.
  232.        In particular, check the '/' (root) and '/etc' directories, and all
  233.        system and network configuration files. Examine file and directory
  234.        protections before and after installing software or running
  235.        verification utilities. These procedures can cause file and directory
  236.        protections to change.
  237.  
  238.    11. Old versions of system software
  239.  
  240.        Older versions of operating systems often have security vulnerabilities
  241.        that are well known to intruders. To minimize your vulnerability to
  242.        attacks, keep the version of your operating system up to date and apply
  243.        security patches appropriate to your system(s) as soon as they become
  244.        available.
  245.  
  246.        For information about software upgrades that fix security problems,
  247.        their sources, and their MD5 checksums, see
  248.  
  249.      ftp://info.cert.org/pub/latest_sw_versions/
  250.  
  251.    12. Use of setuid shell scripts
  252.  
  253.        Setuid shell scripts (especially setuid root) can pose potential
  254.        security problems, a fact that has been well documented in many UNIX
  255.        system administration texts. Do not create or allow setuid shell
  256.        scripts, especially setuid root.
  257.  
  258.    13. Inappropriate export settings
  259.  
  260.        Use the showmount(8) utility to check that the configuration of the
  261.        /etc/exports files on your hosts are correct.
  262.  
  263.        - Wherever possible, file systems should be exported read-only.
  264.        - Do not self-reference an NFS server in its own exports file. That is,
  265.      the exports file should not export an NFS server to itself nor to
  266.      any netgroups that include the NFS server.
  267.        - Do not allow the exports file to contain a "localhost" entry.
  268.        - Export file systems only to hosts that require them.
  269.        - Export only to fully qualified hostnames.
  270.        - Ensure that export lists do not exceed 256 characters (after the
  271.      aliases have been expanded) or that all security patches relating
  272.      to this problem have been applied.
  273.  
  274.        The CERT Coordination Center is aware that intruders are using tools
  275.        that exploit a number of NFS vulnerabilities. This can result in a
  276.        root compromise, depending on the vulnerability being exploited. We
  277.        encourage you to limit your exposure to these attacks by implementing
  278.        the security measures outlined in CERT advisory CA-94:15. For this and
  279.        other information about the NFS vulnerability, see
  280.  
  281.      ftp://info.cert.org/pub/cert_advisories/CA-94:15.NFS.Vulnerabilities
  282.  
  283.    14. Vulnerable protocols and services
  284.  
  285.        You may want to consider filtering certain TCP/IP services at your
  286.        firewall or router. For some related suggestions, please refer to
  287.        "Packet Filtering For Firewall Systems," available from
  288.  
  289.      ftp://info.cert.org/pub/tech_tips/packet_filtering
  290.  
  291.  
  292.  Other Suggestions
  293.  
  294.     For a list of additional suggestions on removing common and known
  295.     security vulnerabilities under the UNIX Operating System, see the "UNIX
  296.     Computer Security Checklist" developed by the Australian Computer
  297.     Emergency Response Team (AUSCERT). A copy of the AUSCERT checklist can
  298.     be found in
  299.  
  300.      ftp://info.cert.org/pub/tech_tips/AUSCERT_checklist1.1
  301.  
  302.     For a list of some recommended books and articles on computer security
  303.     topics, see the CERT(sm) Coordination Center FAQ, available from
  304.  
  305.      http://www.cert.org/cert.faqintro.html
  306.      ftp://info.cert.org/pub/cert_faq
  307.  
  308. - ------------------------------------------------------------------------------
  309.  
  310. Copyright 1996 Carnegie Mellon University. Conditions for use, disclaimers,
  311. and sponsorship information can be found in
  312. http://www.cert.org/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff .
  313. If you do not have FTP or web access, send mail to cert@cert.org with
  314. "copyright" in the subject line.
  315.  
  316. CERT is registered in the U.S. Patent and Trademark Office.
  317.  
  318.  
  319.  
  320. -----BEGIN PGP SIGNATURE-----
  321. Version: PGP for Personal Privacy 5.0
  322. Charset: noconv
  323.  
  324. iQA/AwUBOBTCdlr9kb5qlZHQEQJKgACeMA+YXXiZzkWbYSzDNGIf+gv5Z6gAoO9x
  325. DVixzNxCqUXn1y8b7PxSoJ7P
  326. =iRAO
  327. -----END PGP SIGNATURE-----
  328.