Child pages
  • 1997 CERT Tech Tip: UNIX Configuration Guidelines

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Note

Original publication date: October 2, 1997

HTML
<HR SIZE=2 NOSHADE ALIGN=LEFT>

<P>
<A HREF="#intro">Introduction</A>
<P>
A. <A HREF="#A">Commonly Exploited Configuration Problems</A>
<P>
<OL TYPE="1">
 <LI><A HREF="#A.1.i">Weak Passwords</A></LI>
 <LI><A HREF="#A.1.ii">Accounts with default passwords</A></LI>
 <LI><A HREF="#A.1.iii">Reusable passwords</A></LI>
 <LI><A HREF="#A4">Use of TFTP (Trivial File Transfer Protocol) to obtain password files</A></LI>
 <LI><A HREF="#A5">Vulnerabilities in sendmail</A></LI>
 <LI><A HREF="#A6">Misconfigured anonymous FTP</A></LI>
 <LI><A HREF="#A7">Inapropriate network configuration file entries</A></LI>
 <LI><A HREF="#A8">Inappropriate 'secure' settings in /etc/ttys and /etc/ttytab</A></LI>
 <LI><A HREF="#A9">Inappropriate entries in /etc/aliases (or /usr/lib/aliases)</A></LI>
 <LI><A HREF="#A10">Inappropriate file and directory protections</A></LI>
 <LI><A HREF="#A11">Old versions of system software</A></LI>
 <LI><A HREF="#A12">Use of setuid shell scripts</A></LI>
 <LI><A HREF="#A13">Inappropriate export settings</A></LI>
 <LI><A HREF="#A14">Vulnerable protocols and services</A></LI>
</OL>
B. <A HREF="#B">Other Suggestions</A>
<p>
<A HREF="#history">Revision History</A>
<P>
<HR SIZE=2 NOSHADE ALIGN=LEFT>
<P>
<A NAME="intro"></a>
This document describes commonly exploited UNIX system configuration
problems and recommends practices that can be used to help deter
several types of break-ins. We encourage system administrators to
review all sections of this document and modify their systems to fix
potential weaknesses.
<P>
In addition to the information in this document, we provide three
companion documents that may help you.
<P>
<UL>
    <LI><A HREF="http://www.cert.org/tech_tips/intruder_detection_checklist.html">
        http://www.cert.org/tech_tips/intruder_detection_checklist.html</A><BR>
        contains suggestions for determining if your system may have
	been compromised</LI>
    <LI><A HREF="http://www.cert.org/tech_tips/win-UNIX-system_compromise.html">
	http://www.cert.org/tech_tips/win-UNIX-system_compromise.html</A><BR>
	contains suggested steps for recovering from a root compromise on
	a UNIX and Windows NT systems</LI>
   
</UL>
<P>
Also, please see our CERT advisory page, our CERT incident notes page,
and our CERT vulnerability notes page which contain brief descriptions
of all past CERT advisories, incident notes, and vulnerability
notes. These files are available from
<P>
<UL>
    <LI><A HREF="http://www.cert.org/advisories/">
        http://www.cert.org/advisories/</A></LI>
    <LI><A HREF="http://www.cert.org/incident_notes/">
        http://www.cert.org/incident_notes/</A></LI>
    <LI><A HREF="http://www.cert.org/vul_notes/">
        http://www.cert.org/vul_notes/</A></LI>
</UL>
<P>
We encourage you to review the documents that pertain to your
system(s), and to consider taking the suggested steps to protect your
system(s) from attack. We also encourage you to check with your
vendor(s) regularly for any software updates or new software patches
that relate to your systems.
<P>
<HR SIZE=2 NOSHADE ALIGN=LEFT>
<P>
<H3>A. <A NAME="A"></a>Commonly Exploited Configuration Problems</H3>
<P>
<OL TYPE="1">
 <B><LI><A NAME="A.1"></a>Poor Password Security</B>
  <P>
  The basic form of authentication used to control access to a UNIX
  host is a username and password combination. Intruders have
  established mechanisms and tools to compromise password information
  by leveraging a variety of common problems.
  <P>
  <OL TYPE="i">
   <B><LI><A NAME="A.1.i"></a>Weak passwords</B>
    <P>
    Encourage your users to choose passwords that are difficult to guess
    (for example, words that are not in any dictionary of any language;
    no proper nouns, including names of "famous" real or fictitious
    characters; no acronyms that are commonly used by computer
    professionals; no simple variations of first or last names.)
    Furthermore, inform your users not to leave any cleartext
    username/password information in files on any system.
    <P>
    A good heuristic for choosing a password is to choose an
    easy-to-remember phrase, such as "By The Dawn's Early Light", and
    use the first letters to form a password. Add some punctuation or
    mix case letters as well. For the phrase above, one example password
    might be: bt}DeL{. (DO NOT use this sample phrase for your
    password.)
    <P>
    If intruders can get a password file, they usually move or copy it
    to another machine and run password-guessing programs on it. These
    programs involve large dictionary searches, and they run quickly
    even on slow machines. Most systems that do not put any controls of
    the type of passwords used probably have at least one password that
    can be easily guessed. CERT Incident Note IN-98.03 describes
    intruder activity that is based on a stolen password file.
    <P>
    <DL>
     <DD><A HREF="http://www.cert.org/incident_notes/IN-98.03.html">
         http://www.cert.org/incident_notes/IN-98.03.html</A></DD>
    </DL>
    <P>
    If you believe that your password file may have been taken, change
    all the passwords on the system. At the very least, you should
    change all system passwords because an intruder may concentrate on
    those and may be able to guess even a reasonably "good"
    password. Intruders often use compromised accounts to attempt to
    gain privelaged access on vulnerable systems, so we encourage you to
    follow the steps in
    <P>
    <UL>
     <LI><A HREF="http://www.cert.org/tech_tips/intruder_detection_checklist.html">
         http://www.cert.org/tech_tips/intruder_detection_checklist.html</A></LI>
     <LI><A HREF="http://www.cert.org/tech_tips/win-UNIX-system_compromise.html">
         http://www.cert.org/tech_tips/win-UNIX-system_compromise.html</A></LI>
    </UL>
    <P>
    For further information about protecting your system from 
    password-based attacks, see
    <P>
    <UL>
     <LI><A HREF="http://www.cert.org/tech_tips/passwd_file_protection.html">
         http://www.cert.org/tech_tips/passwd_file_protection.html</A></LI>
    </UL>
    <P>
   </LI>
   <B><LI><A NAME="A.1.ii"></a>Accounts with default passwords</B>
    <P>
    Intruders exploit system default passwords that have not been
    changed since installation, including accounts with vendor-supplied
    default passwords. In some cases, accounts do not have a password
    assigned by default. CERT Incident Note IN-98.01 describes intruder
    activity that is based on exploitations of accounts without
    passwords.
    <P>
    <DL>
     <DD><A HREF="http://www.cert.org/incident_notes/IN-98.01.irix.html">
         http://www.cert.org/incident_notes/IN-98.01.irix.html</A></DD>
    </DL>
    <P>
    Be sure to change all default passwords on computer systems and
    networking equipment prior to deployment. Also, be aware that
    product upgrades can quietly change account passowrds to a new
    default. It is best to change the passwords of default accounts
    after applying updates.
    <P>
    Scan your password file for extra UID 0 accounts, accounts with no
    password, or new entries in the password file. Do not allow any
    accounts without passwords. Remove entries for unused accounts from
    the password file. To disable an account, change the password field
    in the /etc/passwd file to an asterisk '*' and change the login
    shell to /bin/false to ensure that an intruder cannot login to the
    account from a trusted system on the network.
    <P>
   </LI>
   <B><LI><A NAME="A.1.iii"></a>Reusable and shared passwords</B>
    <P>
    Even excellent passwords are not safe. They can be captured by
    programs such as packet sniffers if the passwords are sent across
    networks in cleartext (whether on a subnet, a local network, or
    the Internet). It is common for intruders to use packet sniffers
    on compromised systems to harvest passwords.
    <P> 
    CERT Incident Note IN-99-06 describes widespread intruder activity
    involving distributed sniffers used to harvest username and
    password information from a network.
    <P>
    <DL>
     <DD><A HREF="http://www.cert.org/incident_notes/IN-99-06.html">
         http://www.cert.org/incident_notes/IN-99-06.html</A></DD>
    </DL>
    <P>
    At the very least, a single password should not be used to protect
    multiple accounts. If an intruder is able to compromise a shared
    password just once, all of the accounts sharing the password are
    compromised. Each account, or resource, protected by a password
    should have it's own unique password.
    <P>
    To overcome the threat posed by packet sniffers, we recommend
    using one-time passwords, especially for authenticated access from
    external networks and for access to sensitive resources like name
    servers and routers. For more information, see Appendix B of the
    following advisory:
    <P>
    <DL>
     <DD><A HREF="http://www.cert.org/advisories/CA-94.01.ongoing.network.monitoring.attacks.html">
         http://www.cert.org/advisories/CA-94.01.ongoing.network.monitoring.attacks.html</A></DD>
    </DL>
    <P>
    Another approach is to use a strong authentication mechanisms such
    as secure shell, SSL, or kerberos. Secure shell, or ssh, is widely
    available for many different platforms. For more information about
    secure shell, see
    <P>
    <UL>
     <LI><A HREF="http://www.ssh.com/index.html">http://www.ssh.com/index.html</A></LI>
     <LI><A HREF="http://www.openssh.com/">http://www.openssh.com/</A></LI>
    </UL>
    <P>
   </LI>
  </OL>  

<!-- TODO -->

          <LI><A NAME="A4"></a>Use of TFTP (Trivial File Transfer Protocol) to obtain password files
                <P>
                To test your system for this vulnerability, connect to your 
                system using tftp and try
<PRE>
	 get /etc/motd
</PRE>
                If you can do this, anyone else on the network can probably get 
                your password file. To avoid the problem, disable tftpd. If you
                must have tftpd, ensure that it is configured with restricted 
                access. For further information, see
		<P>
		<DL>
		<DD><A HREF="http://www.cert.org/advisories/CA-91.18.Active.Internet.tftp.Attacks.html">
                    http://www.cert.org/advisories/CA-91.18.Active.Internet.tftp.Attacks.html</A></DD>
		</DL><P>
                As mentioned in Section 1 above, if you believe your password 
                file may have been taken, the safest course is to change all 
                passwords in the system.<P>
            </LI>
            <LI><A NAME="A5"></a>Vulnerabilities in sendmail
                <P>
                There have been a number of vulnerabilities identified over 
                the years in sendmail(8). To the best of our knowledge, the 
                current version of sendmail addresses those known 
                vulnerabilities.
                </P>

                To determine which version of sendmail is running, use telnet 
                to connect to the SMTP port (25) on your system:
<PRE>
	 telnet <your hostname> 25
</PRE>
                We encourage you to keep up to date with the latest version of 
                sendmail from your vendor, and ensure that it is up to date 
                with security patches or workarounds detailed in CERT advisories
                advisories and bulletins. 

                In addition, we encourage you to use the following tools, both 
                of which are distributed with the latest versions of sendmail:
                <OL TYPE="a">
                    <LI>smrsh, the sendmail restricted shell, controls the way o
                        that incoming mail messages can interact with your 
                        operating system. For instance, when configured
                        correctly, smrsh can prevent an intruder from using 
                        pipes to execute arbitrary commands on your system.
                    </LI>
                    <LI>mail.local can be used to control the way in which the
                        /bin/mail program is used on your system. This tool is 
                        described in CERT advisory CA-95:02.
                        <BLOCKQUOTE>
                            <A HREF="http://www.cert.org/advisories/CA-1995-02.html">
http://www.cert.org/advisories/CA-1995-02.html</A>
                        </BLOCKQUOTE>
                    </LI>
                </OL>
            <LI><A NAME="A6"></a>Misconfigured anonymous FTP
                <P>
                In addition to making sure that you are running the most 
                recent version of ftpd, check your anonymous FTP 
                configuration. It is important to follow the instructions 
                provided with the operating system to properly configure 
                the files and directories available through anonymous FTP 
                (for example, file and directory permissions, ownership and
                group). Note that you should not use your system's standard
                password file or group file as the password file or group 
                file for FTP. The anonymous FTP root directory and its two 
                subdirectories, etc and bin, should not be owned by ftp. 
                For more information about configuring anonymous FTP, see
                <BLOCKQUOTE>
                    <A HREF="http://www.cert.org/tech_tips/anonymous_ftp_config.html">
                    http://www.cert.org/tech_tips/anonymous_ftp_config.html</A>
                </BLOCKQUOTE>
            </LI>
            <LI><A NAME="A7"></a>Inappropriate network configuration file entries
                <P>
                Several vendors supply /etc/hosts.equiv files with a '+'
                (plus sign) entry. The '+' entry should be removed from 
                this file because it means that your system will trust all 
                other systems. Other files that should not contain a '+' 
                entry include all .rhosts files on the system. These files 
                should not be world-writable.
                </P>

                <P>
                If your /usr/lib/X11/xdm/Xsession file includes an 'xhost' 
                command with a '+' entry, such as
<PRE>
	 /usr/bin/X11/xhost +
</PRE>
                remove that line. (Note that the 'xhost' command may be in 
                a different directory tree on your system.) If such a line 
                remains intact, anyone on the network can talk to the X 
                server and potentially insert commands into windows or read
                console keystrokes.
                </P>
            </LI>
            <LI><A NAME="A8"></a>Inappropriate 'secure' settings in /etc/ttys and /etc/ttytab
                <P>
                Check the file /etc/ttys or /etc/ttytab (depending on the 
                release of UNIX being used). The ONLY terminal that should 
                be set to 'secure' should be the console.
                </P>
           </LI>
           <LI><A NAME="A9"></a>Inappropriate entries in /etc/aliases (or /usr/lib/aliases)
               <P>
               Examine the /etc/aliases (or /usr/lib/aliases) mail alias 
               file for inappropriate entries. Some alias files include an
               alias named 'uudecode' or just 'decode.' If this alias 
               exists on your system and you are not explicitly using it, 
               then you should remove it.
               </P>
           </LI>
           <LI><A NAME="A10"></a>Inappropriate file and directory protections
               <P>
               Check your system documentation to establish the correct 
               file and directory protections and ownership for system 
               files and directories.  In particular, check the '/' (root)
               and '/etc' directories, and all system and network 
               configuration files. Examine file and directory protections
               before and after installing software or running verification
               utilities. These procedures can cause file and directory 
               protections to change.
               </P>
          <LI><A NAME="A11"></a>Old versions of system software
               <P>
               Older versions of operating systems often have security 
               vulnerabilities that are well known to intruders. To 
               minimize your vulnerability to attacks, keep the version of
               your operating system up to date and apply security patches
               appropriate to your system(s) as soon as they become 
               available.
               </P>

            </LI>
            <LI><A NAME="A12"></a>Use of setuid shell scripts
                <P>
                Setuid shell scripts (especially setuid root) can pose 
                potential security problems, a fact that has been well 
                documented in many UNIX system administration texts. Do not
                create or allow setuid shell scripts, especially setuid 
                root.
                </P>
            </LI>
            <LI><A NAME="A13"></a>Inappropriate export settings
                <P>
                Use the showmount(8) utility to check that the 
                configuration of the /etc/exports files on your hosts 
                are correct.
                <UL>
                    <LI>Wherever possible, file systems should be exported 
                        read-only.
                    <LI>Do not self-reference an NFS server in its own 
                        exports file. That is, the exports file should not 
                        export an NFS server to itself nor to any netgroups 
                        that include the NFS server.
                    <LI>Do not allow the exports file to contain a 
                        "localhost" entry.
                    <LI>Export file systems only to hosts that require them.
                    <LI>Export only to fully qualified hostnames.
                    <LI>Ensure that export lists do not exceed 256 
                        characters (after the aliases have been expanded) 
                        or that all security patches relating to this 
                        problem have been applied.
                 </UL>
                The CERT Coordination Center is aware that intruders are 
                using tools that exploit a number of NFS vulnerabilities. 
                This can result in a root compromise, depending on the 
                vulnerability being exploited. We encourage you to limit
                your exposure to these attacks by implementing the security
                measures outlined in CERT advisory CA-94:15. For this and 
                other information about the NFS vulnerability, see
                <BLOCKQUOTE>
                    <A HREF="http://www.cert.org/advisories/CA-1994-15.html">
                    http://www.cert.org/advisories/CA-1994-15.html</A>
                </BLOCKQUOTE>
            </LI>
            <LI><A NAME="A14"></a>Vulnerable protocols and services
                <P>
                You may want to consider filtering certain TCP/IP services 
                at your firewall or router. For some related suggestions, 
                please refer to "Packet Filtering For Firewall Systems,"
                available from
                <BLOCKQUOTE>
                    <A HREF="http://www.cert.org/tech_tips/packet_filtering.html">
                    http://www.cert.org/tech_tips/packet_filtering.html</A>
                </BLOCKQUOTE>
            </LI>
        </OL>
        </P>
    </LI>

        For a list of some recommended books and articles on computer 
        security topics, see the CERT(sm) Coordination Center FAQ, 
        available from
        <P>
        <UL>
           <LI><A HREF="http://www.cert.org/faq/cert_faq.html">
               http://www.cert.org/faq/cert_faq.html</A></LI>
       </UL>
       </P>
    </LI>
</UL>

<p><!--#include virtual="/include/footer_nocopyright.html" --> </p>

<p>Copyright 1997 Carnegie Mellon University.</p>


<HR SIZE=2 NOSHADE ALIGN=LEFT>

<TABLE>
<A NAME="history"></a>

<TR>
<TD>
<FONT SIZE=3 FACE="Helvetica, Geneva, Arial">
Revision History
</TD>
</TR>

<TR>
<TD VALIGN=TOP WIDTH=30%>
<FONT SIZE=2 FACE="Helvetica, Geneva, Arial">
Oct 02, 1997<BR>
Feb 12, 1999<BR>
Jun 04, 2003<BR>
Apr 24, 2006<BR>
</TD>
<TD VALIGN=TOP WIDTH=70%>
<FONT SIZE=2 FACE="Helvetica, Geneva, Arial">
Initial Release<BR>
Converted to new web format<BR>
Updated broken links<BR>
</TD>
</TR>
</SMALL>
</TABLE>