------------------------------------------------------------------------------UNIX Computer Security Checklist  (Version 1.0)         Last Update 5-Mar-1995------------------------------------------------------------------------------The Australian Computer Emergency Response Team has developed a checklist which covers common and known security holes under the UNIX OperatingSystem.  It is based around recently discovered security vulnerabilitiesand other checklists which are readily available. (see references in AppendixC).  This document can be retrieved via anonymous ftp from the location    ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist_1.0It is AUSCERT's intention to continue to update this checklist.  Anycomments should be directed via email to auscert@auscert.org.au. This document, once written is now a static article.  Security issues are considerably more fluid and change all the time.  New versions of thischecklist will be placed in the same area on the ftp server and should be checked for periodically. In order to make effective use of this checklist, readers will need to have a good grasp of basic UNIX system administration concepts.  Refer to C.6 and C.7 in Appendix C for books on UNIX system administration.Follow the checklist closely and amend any problems that you encounter.  We recommend that you use the checklist on a regular basis as well as afteryou install any patches or new versions of the operating system. Where applicable, references will be made to points under discussion thatrelate to a specific vendor's operating system, such as SunOS.In general, code examples have been written with SunOS 4.1.x in mind.  Full directory paths and program options may vary for different varieties of UNIX.If in doubt consult your vendor documentation. For ease of use, the checklist has been split into separate, logicallycohesive sections.  All sections are important.  An abbreviated version ofthis checklist can be found in Appendix D. CHECKLIST INDEX:	1.0  Patches			2.0  Network security			3.0  ftpd and anonymous ftp			4.0  Password and account security			5.0  File system security			6.0  SunOS specific security			7.0  IRIX specific security			8.0  X windows securityAPPENDICES:      Appendix A  Other AUSCERT information sources		 Appendix B  Useful security tools		 Appendix C  References		 Appendix D  Checklist - abbreviated version		 Appendix E  Shell Scripts------------------------------------------------------------------------------1.0  Patches ------------------------------------------------------------------------------   *	Retrieve the latest patch list from your vendor and install any 	patches not yet installed that are recommended for your system.            Some patches may re-enable default configurations.  For this             reason it is important to go through this checklist AFTER            installing ANY new packages.	NOTE: Be certain to verify the checksum information to confirm              that you have retrieved a valid copy.  This is important 	      in any anonymous ftp transaction.  If checksums are provided	      - use them!  That said, it should be noted that checksums 	      produced by /bin/sum should not be considered secure.  Other	      more cryptographically strong methods such as md5 should be 	      used.  Refer to B.10 for md5 access information.------------------------------------------------------------------------------2.0  Network security------------------------------------------------------------------------------	The following is a list of UNIX features that can be used to help	prevent	attacks from external sources. 2.1  Filtering   *	CHECK whether the following are required outside your domain.  If 	they are not required, then filter them out at the router.	    NAME     PORT  PROTOCOL     NAME    PORT  PROTOCOL	    systat   11    TCP		login   513   TCP	    netstat  15    TCP		shell   514   TCP	    bootp    67    UDP		printer 515   TCP	    tftp     69    UDP		biff    512   UDP	    link     87    TCP		who     513   UDP	    supdup   95    TCP		syslog  514   UDP	    sunrpc   111   TCP/UDP	uucp    540   TCP	    NeWS     144   TCP		route   520   UDP	    snmp     161   UDP		openwin 2000  TCP	    xdmcp    177   UDP		NFS     2049  UDP/TCP	    exec     512   TCP          X11     6000-6020 TCP	(Refer to C.6 Firewalls and Internet Security)	(Refer to the CERT advisory CA-95.01 (see C.7)) 2.2  "r" commands	   *    DO disable all "r" commands (rlogin, rsh etc.) unless specifically 	required.            This may increase your risk of password exposure in network            sniffer attacks, but "r" commands have been a regular source of            insecurities and attacks.  Disabling them is by far the lesser            of the two evils.	    Refer to section 2.8 for details on how to do this.   *    DO filter ports 512,513 and 514 (TCP) at the router if you do use any	of the "r" commands.            This will stop people outside your domain from exploiting them	    but will not stop people inside your domain from exploiting them.	    To do this you will need to disable them (see above). 2.3  /etc/hosts.equiv	   *	CHECK that this file does not exist.   	    It allows other hosts to be trusted by your system.  Programs	    such as rlogin can then be used to log on to the same account	    name on a trusted machine without supplying a password.         If you must have such a file:   *    ENSURE that you keep only a small number of TRUSTED hosts listed.    *    DO use netgroups for easier management if you run NIS(also known 	as YP).   *    DO only trust hosts within your domain or under your management.   *    CHECK that you use fully qualified hostnames, 	    i.e. hostname.domainname.au   *    ENSURE that you do NOT have a '+' entry by itself anywhere in the	file.   *    ENSURE that the first character of the file is not '-'.  	    (Refer to the CERT advisory CA-91:12 (see C.7)).   *    ENSURE that the permissions are set to 600.   *    ENSURE that the owner is set to root.   *    CHECK it again after each patch or operating system installation. 2.4  $HOME/.rhosts   *	CHECK that no user has a .rhosts file in their home directory.            They pose a greater security risk than /etc/hosts.equiv, as one            can be created by each user.  There are some genuine needs for            these files, so hear each one on a case-by-case basis; eg.            running backups over a network unattended.   *	DO use cron to periodically check for, report the contents of 	and delete $HOME/.rhosts files.  Users should be made aware that you	regularly perform this type of audit.        If you must have such a file   *    ENSURE the first character of the file is not '-'.  	    (Refer to the CERT advisory CA-91:12 (see C.7)).   *    ENSURE that the permissions are set to 600.   *    ENSURE that the owner is the same person who owns the account.   *    ENSURE that the file does NOT contain the symbol "+" on any line. 2.5  NFS   *    DO disable NFS if you do not need it.	    Check your vendor supplied documentation for details on how to	    do this.   *    DO apply all available patches.	    NFS has had a number of security vulnerabilities.   *    DO filter NFS traffic at the router.            Filter TCP/UDP on port 111 		   TCP/UDP on port 2049             This will prevent machines not on your subnet from accessing            file systems exported by your machines.   *    DO enable NFS port monitoring.            Calls to mount a file system will then only be accepted from 	    port < 1024(root access).  You should check your vendor's	    documentation to see if this is an option for your version of 	    UNIX.  Under SunOS, to enable NFS port monitoring add the 	    following commands to /etc/rc.local	      /bin/echo "nfs_portmon/W1" | /bin/adb -w /vmunix /dev/kmem > /dev/null 2>&1	      rpc.mountd 	       *    DO use /etc/exports to ONLY export file systems you need to export. 	    If you aren't certain that it needs to be exported, then it            probably doesn't.   *    DO run fsirand for all your file systems.            Firstly, check that you have installed any patches for fsirand.            Then ensure the file system is unmounted and run fsirand.             Predictable root handles assist crackers in abusing NFS.    *    CHECK that you never export file systems to the world.  	    Use a -access=host.domainname.au option in /etc/exports.    *    DO export file systems read-only (option ro) whenever possible. 	    See the man page for "exports".   *    DO use the secure option if it is available.   *    DO use showmount -e to see what you currently have exported.   *    REMEMBER that changes in /etc/exports will only take effect after	you run /usr/etc/exportfs.    *    CHECK that the permissions of /etc/exports are set to 644.   *    CHECK that /etc/exports is owned by root.      2.6  /etc/hosts.lpd   *    ENSURE that the first character of the file is not '-'.  	    (Refer to the CERT advisory CA-91:12 (see C.7)).   *    ENSURE that the permissions on this file are set to 600.   *    ENSURE that the owner is set to root. 2.7  /etc/ttytab  (BSD UNIX systems)   *    CHECK that the secure option is removed from all entries that 	don't need root login capabilities.             ie. all entries with the possible exception of console. It            should also be removed from console if you do not want users            to be able to reboot in single user mode.   *    CHECK that this file is owned by root.   *    CHECK that the permissions on this file are 644. 2.8  /etc/inetd.conf	     *    ENSURE that the permissions on this file are set to 644.   *    ENSURE that the owner is root.   *	DO disable any services which you do not require.             - To do this we suggest that you comment out ALL services by 	      placing a "#" at the beginning of each line.  Then enable 	      the ones you NEED by removing the "#" from the beginning 	      of the line.  In particular, it is best to avoid "r" commands 	      and tftp, as they have been major sources of insecurities.  	    - For changes to take effect, you need to restart the inetd 	      process.  Do this by issuing the following commands.	        # /bin/ps -aux | /usr/bin/grep inetd | /usr/bin/grep -v grep	        # /bin/kill -HUP <inetd-PID> 2.9  Trivial ftp (tftp)	   *    Read the AUSCERT Advisory SA-93:05 (see A.1) and follow the 	recommendations.   *	If tftp is not needed, comment it out from the file 	    /etc/inetd.conf and restart the inetd process (as above).  2.10  /etc/services      *    ENSURE that the permissions on this file are set to 644.   *    ENSURE that the owner is root. 2.11  tcp_wrapper (also known as log_tcp)   *    ENSURE that you are running this program.	    - Refer to section A.5 on how to obtain tcp_wrapper.	    - Customise and install it for your system.	    - Deny all hosts by putting "all:all" in /etc/hosts.deny and	      explicitly list trusted hosts who are allowed access to your	      machine in /etc/hosts.allow.   *    DO wrap all TCP services that you have enabled. 2.12  /etc/aliases   *	Comment out the "decode" alias by placing a "#" at the beginning	of the line.  For this change to take effect you will need to run	/usr/bin/newaliases.	        # /usr/bin/newaliases            If you run NIS (YP), you will then need to rebuild your maps:	        # (cd /var/yp; /usr/bin/make aliases)   *    ENSURE that all programs executable by an alias are owned by root,        have permissions 755 and are stored in a systems directory 	eg. /usr/local/bin. 2.13  /etc/sendmail.cf           *    ENSURE the line starting with "OW" only has a "*" next to it.   *    DO use Eric Allmans's sendmail v8.6.10 (or greater), as it         currently contains no KNOWN vulnerabilities.              This is available via anonymous FTP from:                ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu			/ucb/sendmail/sendmail.8.6.10.*	            Note:  If you don't already run Eric Allman's sendmail.8.6.*,            then it may take you some time to build, install, and configure            the system to your needs.  Other sendmail(8) configuration files 	    may not be compatible with sendmail(8) 8.6.10.   *    CHECK that you have installed the latest patches.	    This is VERY important as sendmail(8) has been a source of a 	    number of security vulnerabilities.	    (Refer to AUSCERT Advisory SA-93:10 (see A.1) 	          and CERT Advisories CA-94:12 and CA-95:05 (see C.7))   *    TRY the following tests:	        % telnet hostname 25	        wiz	        debug	        kill	        quit	        %            You should see the response "500 Command unrecognized" after            each of the commands 'wiz', 'debug' and 'kill'.  If not, your            version of sendmail is vulnerable and should be updated.   *    DO increase sendmail(8) logging to a minimum log level of 9.             This will help detect attempted exploitation of the sendmail(8)            vulnerabilities.  To do this, include the following line in the 	    options part of the general configuration information section of	    the sendmail configuration file:	        # log level		OL9      *    DO increase the level of logging provided by syslog.            Enable a minimum level of "info" for mail messages to be            logged to the console and/or the syslog file.  For example, 	    include the following lines in the syslog.conf file: 		mail.info                       /dev/console		mail.info                       /var/adm/messages 	    syslog will then need to be instructed to reread the configuration	    file.  This can be done by issuing the command		# /bin/kill -HUP `/bin/cat /etc/syslog.pid`            Sample error messages to look for include mail to or from a            single pipe ("|"), or mail to or from an obviously invalid user