UNIX Computer Security Checklist.0

------------------------------------------------------------------------------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 OperatingSystem.  It is based around recently discovered security vulnerabilitiesand other checklists which are readily available. (see references in AppendixC).  This document can be retrieved via anonymous ftp from the location    ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist_1.0It is AUSCERT's intention to continue to update this checklist.  Anycomments 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 thischecklist 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 afteryou install any patches or new versions of the operating system. Where applicable, references will be made to points under discussion thatrelate 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, logicallycohesive sections.  All sections are important.  An abbreviated version ofthis 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 securityAPPENDICES:      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            (for example, bounce or blah).     *    REMEMBER that if you are running a frozen configuration file - 	sendmail.fc, you will need to rebuild it and restart sendmail(8) 	before any changes will take effect.  To rebuild the frozen 	configuration file, the	command is:		# /usr/lib/sendmail -bz        To restart sendmail(8) you should kill *all* existing sendmail(8) 	processes by sending them a TERM signal using kill.  Then startup	sendmail(8).  Sample commands are:		# /usr/bin/ps -auxw | /bin/grep sendmail | /bin/grep -v grep	        # /bin/kill <pid>     #pid of every running sendmail process	        # /usr/lib/sendmail -bd -q1h	 2.14  majordomo   *    Check that your version is greater than 1.91.            See AUSCERT Advisory SA-94.03 (see A.1) for more details. 2.15  fingerd	   *    If your version of fingerd is older than than 5 November 1988,	replace it with a newer version. 2.16  UUCP	   *    DO disable the uucp account, including the shell that it executes 	for logging in, if it is not used at your site.            uucp may be shipped in a dangerous state.      *    REMOVE any .rhosts file at the uucp home directory.   *    CHECK that the file L.cmds is owned by root.   *    ENSURE that no uucp owned files are world writable.   *    CHECK that you have assigned a different uucp login for each site        that needs uucp access to your machine.     *    CHECK that you have limited the number of commands that each uucp 	login can execute to a bare minimum. ------------------------------------------------------------------------------3.0  ftpd and Anonymous ftp------------------------------------------------------------------------------ 3.1  Versions   *    ENSURE you are using the most recent version of the ftp daemon 	that you use.   *    DO consider installing the Washington University ftpd if you don't 	already have it.            This can log all events and provide users with a login banner.             Do not install any versions prior to wu-ftp 2.4.  	    (Refer to the CERT advisory CA-94:07 (see C.7)).  	    It is available via anonymous ftp from	      ftp://ftp.auscert.org.au/pub/mirrors/wuarchive.wustl.edu			/packages/wuarchive-ftpd/*            [Warning: versions of wu-ftp prior to 2.4 are extremely insecure	              and in some cases have been trojaned.]   *    For BSDI systems, patch 005 should be applied to version 1.1 of the        BSD/386 software.  It is available via anonymous ftp from:	      ftp://ftp.bsdi.com/bsdi/patches/README	      ftp://ftp.bsdi.com/bsdi/patches/?U110-005                  (? will be B or S for the Binary or Source version) 3.2  SITE EXEC   *    CHECK to make sure your ftp server does not have the SITE EXEC command             Do this by telneting to port 21 and typing SITE EXEC. If your            ftp daemon has SITE EXEC make sure you have the most recent 	    version of the daemon (eg, wu-ftp 2.4).  In older versions of ftpd	    SITE EXEC allows anyone to gain shell via port 21.        *    CHECK that any commands from ~ftp/bin, ~ftp/usr/bin, ~ftp/sbin or        similar directory configurations that can be executed by SITE EXEC        DO NOT contain system commands or include a shell            (eg., ~ftp/bin -> /bin)  If they do contain system commands	    it is possible for local users to gain root access.  	    (See AUSCERT advisory SA-94.01 (see A.1)) 3.3  Configuration of your ftp server   *    CHECK all default configuration options on your ftp server.            Not all versions of ftp are configurable.  If you have a 	    configurable version of ftp (eg. wu-ftp) then make sure that 	    all delete, overwrite, rename, chmod and umask options (there 	    may be others) are NOT allowed for guests and anonymous users.  	    In general, anonymous users should not have any unnecessary 	    privileges.     *    CHECK that you have set up a file /etc/ftpusers which specifies        those users that are NOT allowed to connect to your ftpd.              This should include, as a MINIMUM, the entries: root, bin,            uucp, ingres, daemon, news, nobody and ALL vendor supplied             accounts.   *    CHECK that you use an invalid password and user shell for the ftp        entry in the system passwd file. It should look something like:            ftp:*:400:400:Anonymous FTP:/home/ftp:/bin/rubbish        where /home/ftp is the anonymous ftp area.   *    CHECK that you DO NOT have a copy of your real /etc/passwd file        as ~ftp/etc/passwd.              Create one from scratch with permissions 444, owned by root.  It 	    should not contain the names of any accounts in your real 	    password file.  It should contain only root and ftp.  These 	    should be dummy entries with disabled passwords eg:               root:*:0:0:Ftp maintainer::     	       ftp:*:400:400:Anonymous ftp::   *    Similarly, CHECK that you DO NOT have a copy of your real        /etc/group file as ~ftp/etc/group.             Create one from scratch with permissions 444, owned by root.     *    ENSURE the files ~ftp/.rhosts and ~ftp/.forward are zero        length, have permissions 600 and are owned by root. 3.4  Permissions   *    ENSURE NO files or directories are owned by the ftp account or have	the same group as the ftp account.             If they are, it may be possible for an intruder to replace them 	    with a trojan version.   *    ENSURE that the anonymous ftp user cannot create files or directories	in ANY directory.     *    ENSURE that the ftp user can only read information in public areas.   *    ENSURE that the permissions of the ftp home directory (~ftp/) are set        to 555 (read nowrite execute), owner set to root (NOT ftp).   *    ENSURE that the system subdirectories ~ftp/etc and ~ftp/bin         have the permissions 111 only, owner set to root.   *    ENSURE that the permissions of files in ~ftp/bin/* have the        permissions 111 only, owner set to root.   *    ENSURE that the permissions of files in ~ftp/etc/* are set to        444, owner set to root.   *    ENSURE /usr/spool/mail/ftp is owned by root with permissions 400.            If you need email for the ftp admin (eg. for problem reporting)            use an alias. 3.5  Writable directories   *    CHECK that you don't have any writable directories.    	    It is safest not to have any writable directories. If you do    	    have any, we recommend that you limit the number to one.       *	CHECK that writable directories are not also readable.   	    Directories that are both writable and readable may be used by    	    unauthorised persons to trade pirated software.    *    CHECK that any writable directories are owned by root and have    	permissions 1733.     *	DO put writable directories on a separate partition if possible.    	    This will help to prevent denial of service attacks.    *    DO read the CERT document which addresses the many problems    	associated with writable anonymous ftp  directories.  It can be    	obtained via anonymous ftp from:   	    ftp://ftp.auscert.org.au/pub/cert/tech_tips/anonymous_ftp 3.6  Disk mounting   *    NEVER mount disks from other machines to the ~ftp hierarchy         unless they are read-only.  ------------------------------------------------------------------------------4.0  Password and account security------------------------------------------------------------------------------	This section of the checklist can be incorporated as part of a 	password and account usage policy. 4.1  Policy   *	CHECK that you have a password policy for your site.             See the AUSCERT Advisory SA-93.04 (see A.1).   *    ENSURE you have a User Registration Form for each user on each 	system.  Make sure that this form includes a section that the 	intending applicant signs, stating that they have read your account	usage policy and what the consequences are if they misuse their 	account. 4.2  Proactive Checking   *	DO use npasswd or passwd+ to proactively screen passwords as they are 	entered.            These programs run a series of checks on passwords when they are            set and can help to screen out poor passwords.  They were not	    designed to work with shadow password systems.  	    (Refer to section B.3 for how to obtain these.)   *    DO check passwords periodically with Crack.             (Refer to section B.4 for how to obtain Crack.)   *    DO apply password aging (if possible). 4.3  Root Password   *    DO restrict the number of people who know the root password.            These should be the same users registered with groupid 0	    (eg. wheel group on SunOS).  Typically this is limited to at most	    3 or 4 people.   4.4  NIS and /etc/passwd entries   *    DO NOT run NIS if you don't really need it.   *    CHECK that the only machines that have a '+' entry in the /etc/passwd	files are NIS (YP) clients; i.e. NOT the NIS master server!            There appears to be conflicting documentation and            implementations regarding the '+' entry format and so a            generic solution is not available here.  It would be best to            consult your vendor's documentation.            Some of the available documentation suggests placing a '*' in            the password field, which is NOT consistent across all            implementations of NIS.  We recommend testing your systems on a            case-by-case basis to see if they correctly implement the '*'            in the password field.            To do this, follow the steps below:	    . Try using NIS with the '*' in the password field for example; 		   +:*:0:0:::		      If NIS users cannot log in to that machine, remove the '*' and 	      try the next test.	    . With the '*' removed, try logging in again.  If NIS users can	      log in AND you can also log in unauthenticated as the user '+',	      you have a problem!  Your vendor needs to change their version	      of NIS.  If NIS users can log in AND you cannot log in as the	      user '+', your implementation should not be vulnerable to this 	      problem.   *    CHECK that /etc/rc.local is set up to start ypbind with the -s        option.            This may not be applicable on all systems.  Check your 	    documentation. 4.5  Password shadowing and C2 security   *   DO implement C2 security if possible.	    Consult your vendor documentation for details.   *   DO implement vendor supplied password shadowing or a third party        product if you cannot run full C2 security.            Password shadowing restricts access to users' encrypted passwords.   *   DO periodically audit your password and shadow password files        for unauthorised additions or inconsistencies. 4.6  Administration   *    ENSURE that you regularly audit your system for dormant accounts        and disable any that have not been used for a specified period,        say 3 months.  Send out account renewal notices and delete any        accounts of users that do not reply.   *	CHECK that all accounts have passwords.   *    ENSURE that any user area is adequately backed up and archived.   *    DO regularly monitor logs for successful and unsuccessful su 	attempts.   *    DO regularly check for repeated login failures.   *    DO regularly check for LOGIN REFUSED messages.   *	Consider quotas on user accounts if you do not have them. 4.7  Special accounts   *	CHECK that there are no shared accounts other than root;             i.e. more than one person should not know the password to an            account.   *    Disable guest accounts.              Better yet, do not create guest accounts!   *    DO use special groups (such as the "wheel" group under SunOS) to	restrict which users have access to root.   *    DISABLE ALL default vendor accounts shipped with the Operating System.              This should be checked after each upgrade or installation.   *	Disable accounts that have no password which execute a command, for	example	"sync".  	    Preferably, remove these accounts entirely.  Check that they do	    not own any files before you do so. 4.8  Root account   *	Make sure root does not have a ~/.rhosts file.   *	Make sure "." is not in root's search path.   *    Make sure root's login files do not source any other files not        owned by root or which are group or world writable.   *    Make sure root cron job files do not source any other files not	owned by root or which are group or world writable.   *    DO use absolute path names when root.             i.e. /bin/su, /bin/find, /bin/passwd.  This is to stop the            possibility of root accidentally executing a trojan horse.  To            execute commands in the current directory, root should prefix            the command with "./", eg. ./command.------------------------------------------------------------------------------5.0  File system security------------------------------------------------------------------------------ 5.1  General   *	CHECK that there are no .exrc files on your system that have	no legitimate purpose.            These may inadvertently perform commands that may compromise            the security of your system if you happen to start either vi or            ex in a directory which contains such a file.  To find .exrc files:	           # /bin/find / \( -fstype 4.2 -o -prune \) -name '.exrc' \	              -exec /bin/cat {} \; -print   *	CHECK that any .forward files in user home directories do not 	execute a command or run a program.	    The mailer may be fooled into allowing a normal user privileged 	    access.  The following command will locate and print .forward 	    files:	           # /bin/find / \( -fstype 4.2 -o -prune \) \	              -name '.forward' -exec /bin/cat {} \; -print            (Refer to AUSCERT Advisory SA-93.10 (see A.1))  5.2  /etc/rc.local      *    CHECK /etc/rc.local does not chmod 666 motd.              This allows users to change system message for the day.   *    ENSURE that the line "rm -f /tmp/t1" (or similar) exists in 	/etc/rc.local to clean up the temporary file used to create /etc/motd. 	This should occur BEFORE the code to startup the local daemons. 5.3  /usr/lib/expreserve   *	DO replace versions of /usr/lib/expreserve prior to July 1993    	with a recommended patch from your vendor.              If this is not possible, then remove execute permission on            /usr/lib/expreserve:  	        # /bin/chmod 400 /usr/lib/expreserve            This will mean that users who edit their files with either vi            or ex and have their sessions interrupted, will not be able to            recover their lost work.  If you implement the above            workaround, please advise your users to regularly save their            editing sessions.            Refer to the CERT advisory CA-93:09 for advice on fixing this            problem for the SunOS and Solaris environments. 5.4  External file systems/devices   *    DO mount file systems non-setuid and read-only where practical.	    (Refer to section 2.5 NFS) 5.5  File Permissions    *    CHECK that the permissions of /etc/utmp are set to 644.   *    CHECK that the permissions of /etc/sm and /etc/sm.bak are set to 2755.   *    CHECK that the permissions of /etc/state are set to 644.   *    CHECK that the permissions of /etc/motd and /etc/mtab are set to 644.   *    CHECK that the permissions of /etc/syslog.pid are set to 644.   *    REMOVE setgid priveleges on /usr/kvm/crash.	    A group of kmem allows users to read the virtual memory of a 	    running system.	        # /bin/chmod g-s /usr/kvm/crash   *    DO consider removing read access to files that users do not need to 	access.   *    ENSURE that the kernel (eg. /vmunix) is owned by root, has group set 	to 0 (wheel on SunOS) and permissions set to 644.   *    ENSURE that /etc, /bin, /usr/etc, /usr/bin and /tmp are owned by        root and that the sticky-bit is set on /tmp. 	    ie. permissions on /tmp should be:  drwxrwxrwt.	    You should implement COPS or Tiger to check for this.             Refer to section B.2 for information where to obtain these.   *    ENSURE that there are no unexpected world writable files or 	directories on your system.  The following commands find world	writeable files and directories.	       # /bin/find / -type f -perm -22 -exec ls -l {} \;	       # /bin/find / -type d -perm -22 -exec ls -ld {} \;   *    CHECK that files which have the SUID or SGID bit enabled, should have	it enabled:	       # /bin/find / -type f \( -perm -004000 -o -perm -002000 \) \	              -exec ls -l {} \;   *    CHECK the umask value for each user and ensure it is set to	something sensible like 027 or 077.  Refer to section E.1 for a 	shell script to check this. 5.6  Files run by root	AUSCERT recommends that anything run by root should be owned by        root, should not be world or group writable and should be located 	in a directory where every directory in the path is owned by root 	and is not group or world writable.   *    CHECK the contents of the following files for the root account.            Any programs or scripts referenced in these files should meet            the above requirements:            -  ~/.login, ~/.profile and similar login initialisation files            -  ~/.exrc and similar program initialisation files            -  ~/.logout and similar session cleanup files            -  crontab and at entries            -  /etc/rc* and similar system startup files   *    If any programs or scripts referenced in these files source further 	programs or scripts they also need to be verified. 5.7  Bin ownership        Many systems ship files and directories owned by bin.  This varies        from system to system and may have serious security implications.   *    CHANGE all non-setuid files and all non-setgid files and directories 	that are world readable but not world or group writable and that are 	owned by bin to ownership of root, with group id 0 (wheel group under 	SunOS).            Anything else should be verified with the vendor. 5.8  Tiger/COPS   *    Do run one or both of these.            Many of the checks in this section can be automated by using            these programs.  For information on where to get these programs            see B.2.------------------------------------------------------------------------------6.0  SunOS specific security------------------------------------------------------------------------------        The following is a list of security issues that relate specifically        to SunOS 4.1.x.  This is not necessarily a complete list. 6.1  IP forwarding   *    CHECK that IP forwarding is disabled.            You will need the following line in the kernel configuration            file: 		options "IPFORWARDING=-1" 	    For information on how to customise a kernel, see the file: 		/usr/sys/`arch`/conf/README 6.2  Framebuffers  /dev/fb 		If somebody can log in to your Sun workstation from        a remote source, they can read the contents of your Framebuffer,        which is /dev/fb. Sun provides a mechanism which allows the user        logging in to have exclusive access to the Framebuffer, by using 	the file /etc/fbtab.  A sample /etc/fbtab file:	#	# File:		/etc/fbtab	# Purpose:      Specifies that upon login  to  /dev/console,  the	#               owner,  group  and permissions of all supported 	#               devices, including the framebuffer, will be set to 	#		the user's username, the user's group and 0600.	# Comments:	SunOS specific.	# Note:		You cannot use \ to continue a line.	#	# Format:	# Device	Permission	Colon separated device list.	#	/dev/console	0600		/dev/fb	/dev/console	0600		/dev/bwone0:/dev/bwtwo0	/dev/console	0600		/dev/cgone0:/dev/cgtwo0:/dev/cgthree0	/dev/console	0600		/dev/cgfour0:/dev/cgsix0:/dev/cgeight0	/dev/console	0600		/dev/cgnine0:/dev/cgtwelve0	#	/dev/console	0600		/dev/kb:/dev/mouse	/dev/console	0600		/dev/fd0c:/dev/rfd0c        After the above file has been created, reboot your machine, or log	out fully, then log back in again.	Read the man page for fbtab(5) for more information. 6.3  /usr/kvm/sys/*   *    CHECK all files and directories under /usr/kvm/sys/ are not	writable by group.              In SunOs 4.1.4 the default mode is 2775 with group staff,            allowing users in group staff to trojan the kernel. 6.4  /dev/nit (Network Interface Tap)   *    DO run the CERT tool cpm to check if your system is running in 	promiscuous mode.            For access details for cpm see B.6.   *    DO disable the /dev/nit interface if you do not need to run in        promiscuous mode.	    For SunOS 4.x and Solbourne systems, the promiscuous interface 	    to the network can be eliminated by removing the /dev/nit            capability from the kernel.  Once the procedure is complete, you	    may remove the device file /dev/nit since it is no longer 	    functional.            Apply "method 1" as outlined in the System and Network            Administration manual, in the section, "Sun System            Administration Procedures," Chapter 9, "Reconfiguring the            System Kernel."  Excerpts from the method are reproduced below:	          # cd /usr/kvm/sys/sun[3,3x,4,4c]/conf		  # cp CONFIG_FILE SYS_NAME            [Note that at this step, you should replace the CONFIG_FILE            with your system specific configuration file if one exists.]	          # chmod +w SYS_NAME		  # vi SYS_NAME		  #		  # The following are for streams NIT support.  NIT is used by	          # etherfind, traffic, rarpd, and ndbootd.  As a rule of thumb,		  # NIT is almost always needed on a server and almost never		  # needed on a diskless client.		  #		  pseudo-device   snit            # streams NIT		  pseudo-device   pf              # packet filter		  pseudo-device   nbuf            # NIT buffering module	    [Comment out the 3 "pseudo-device" lines; save and exit the            editor before proceeding.]		  # config SYS_NAME		  # cd ../SYS_NAME		  # make	          # mv /vmunix /vmunix.old		  # cp vmunix /vmunix	          # /etc/halt		  > b                                                                 [This step will reboot the system with the new kernel.]            [NOTE that even after the new kernel is installed, you need to            take care to ensure that the previous vmunix.old , or other            kernel, is not used to reboot the system.]	See CERT Advisory CA_94.01 (see C.7)              6.5    SUN recommended and security patches are available via anonymous ftp 	from	    ftp://ftp.auscert.org.au/pub/mirrors/sunsolve1.sun.com/*------------------------------------------------------------------------------7.0  IRIX specific security------------------------------------------------------------------------------	The following is a list of security issues that relate specifically	to the IRIX operating system.  This is not necessarily a complete list. 7.1  /usr/lib/vadmin/serial_ports        The /usr/lib/vadmin/serial_ports program is used to initialise the         data files for the serial ports on your system.         (This only be applies to IRIX Version 4 systems, or Version 5        systems that still contain the serial_ports program.)    *    DO DISABLE this program 	1)If you are not using the serial ports on your IRIX Version 4        system.        2)If you are using serial ports and do not wish to change the        configuration of those ports.        3)If you are using version 5 and the serial_ports program is present.	    This program has been superseded by /usr/Cadmin/bin/cports on            Version 5 and therefore, is no longer required. 	    /usr/lib/vadmin/serial_ports can be disabled by the command:	        # /bin/chmod 700 /usr/lib/vadmin/serial_ports   *    If you intend changing the serial port configuration, you can still        disable the serial_ports program as above.  To change the serial 	port configuration, run the serial_ports program as root. 		(Refer to AUSCERT Advisory AA-94.05a (see A.1)) 7.2    Some IRIX patches are available via anonymous ftp from            ftp://ftp.auscert.org.au/pub/mirrors/ftp.sgi.com/security/*	    ftp://ftp.auscert.org.au/pub/mirrors/sgigate.sgi.com/*------------------------------------------------------------------------------8.0  X windows security------------------------------------------------------------------------------	Access to your X server may be controlled through either a host-	based or user-based method.  The former is left to the discretion	of the Systems Administrator at your site and is useful as long as	all hosts registered in the /etc/Xn.hosts file have users that can be	trusted, where "n" represents your X server's number.	This may not be possible at every site, so a better method is	to educate each and every user about the security implications	(see references below).  Better still, when setting up a user, give	them a set of X security related template files, such as .xserverrc 	and .xinitrc. These are located in the users home directory.	You are strongly advised to read the section on X windows security	referred to in C.4 below. 8.1  Problems with xdm	Note: Release 6 of X11 is now available and solves many problems        associated with X security which were present in previous releases.  	If possible, obtain the source for R6 and compile and install it on 	your system.  Source for R6 is available via anonymous ftp from:            ftp://munnari.oz.au/X.V11/R6           xdm bypasses the normal getty and login functions, which means that         quotas for the user, ownership of /dev/console and possibly other        preventive measures put in place by you may be ignored. 	You should consult your vendor and ask about potential security holes	in xdm and what fixes are available. 8.2  X security - General   *	DO Read the man pages for xauth and Xsecurity.            Use this information to set up the security level you require.   *	CHECK that the permissions on /tmp are set to 1777 (or drwxrwxrwt).            i.e. the sticky bit should be set.  The owner MUST always be            root and group ownership should be set to group-id 0, which is            "wheel" or "system".            If the sticky bit is set, no one other than the owner can delete	    the file /tmp/.X11-unix/X0, which is a socket for your X server.  	    Once this file is deleted, your X server is gone forever!                        If the permissions or ownership are not set as above, then            type the following commands:	         # /bin/chown root.wheel /tmp	         # /bin/chmod 1777 /tmp            Note: This will NOT recursively set the sticky bit on            sub-directories below /tmp, such as /tmp/.X11-unix and            /tmp/.NeWS-unix; you may have to set these manually or through            the system startup files.------------------------------------------------------------------------------Appendix A:  Other AUSCERT information sourcesA.1     AUSCERT advisories            Past AUSCERT advisories can be retrieved via anonymous ftp from                ftp://ftp.auscert.org.au/pub/auscert/advisory/* A.2	AUSCERT's World Wide Web server            AUSCERT maintains a World Wide Web server.  Its URL is                http://www.auscert.org.au------------------------------------------------------------------------------Appendix B:   Useful security tools        There are many good tools available for checking your system.        The list below is not a complete list, and you should NOT rely on 	these to do ALL of your work for you.  They are intended to be only 	a guide.  It is envisaged that you may write some site specific tools	to supplement these.B.1	Crack	    Crack is a fast password cracking program designed to assist site 	    administrators in ensuring that users use effective passwords.            Available via anonymous ftp from:  	        ftp://ftp.auscert.org.au/pub/cert/tools/crack/*B.2	COPS and Tiger            These packages identify common security and configuration            problems.  They also check for common signs of intrusion.             Though there is some overlap between these two packages, they            are different enough that it may be useful to run both. Both 	    are available via anonymous ftp.	    COPS:		ftp://ftp.auscert.org.au/pub/cert/tools/cops/1.04	    tiger:		ftp://ftp.auscert.org.au/pub/mirrors/net.tamu.edu/tiger*B.3	npasswd and passwd+            These programs are proactive password checkers.  They run a	    series of checks on passwords at the time users set them and	    refuse password that fail the tests.  Note that these programs 	    are not designed to work with shadow password systems.  Both are	    available via anonymous ftp.            npasswd:                ftp://ftp.auscert.org.au/pub/mirrors/ftp.cc.utexas.edu			/npasswd/npasswd.tar.Z   	    passwd+:                 ftp://ftp.auscert.org.au/pub/mirrors/dartmouth.edu			/security/passwd+.tar.ZB.4	tcp_wrapper            This software gives logging and access control to most network            services.  It is available via anonymous ftp from:                ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl			/tcp_wrappers_7.2.tar.gz	B.5	Tripwire            This package maintains a checksum database of important system            files.  It can serve as an early intrusion detection system. It            is available via anonymous ftp from: 	        ftp://ftp.auscert.org.au/pub/coast/COAST/Tripwire/*B.6	cpm 	    cpm checks to see if your network interfaces are running in 	    promiscuous mode.  If you do not normally run in this state then 	    it may be an indication that an intruder is running a network 	    sniffer on your system.  This program was designed to run on 	    SunOS 4.1.x and may also work on many BSD systems.  It is available 	    via anonymous ftp from:	       ftp://ftp.auscert.edu.au/pub/cert/tools/cpm/*B.7	Vendor supplied C2 security packages            Consult manuals supplied by your vendor as to installing C2            security. The SunOS manual is "SunOS System & Network            Administration Guide".B.8	Vendor supplied security auditing packages            Sun provides an additional security package called SUNshield.             Please direct enquiries about similar products to your vendor.B.9	smrsh 	    The smrsh(8) program is intended as a replacement for /bin/sh            in the program mailer definition of sendmail(8).  smrsh is a            restricted shell utility that provides the ability to specify,            through a configuration, an explicit list of executable            programs.  When used in conjunction with sendmail, smrsh            effectively limits sendmail's scope of program execution to            only those programs specified in smrsh's configuration.	               It is available via anonymous ftp from:	       ftp://ftp.auscert.org.au/pub/cert/tools/smrshB.10	md5	    md5 is a message digest algorithm.  An implementation of this is 	    available via anonymous ftp from:	       ftp://ftp.auscert.org.au/pub/cert/tools/md5/*	       ftp://ftp.auscert.org.au/pub/cert/tools/md5check/*------------------------------------------------------------------------------Appendix C:	ReferencesC.1	Practical UNIX Security	Simson Garfinkel and Gene Spafford	(C) 1991 O'Reilly & Associates, Inc.C.2	UNIX Systems Security	Patrick Wood and Stephen Kochan	(C) 1986 Hayden BooksC.3	UNIX system security: A Guide for Users and System Administrators	David A. Curry	Addison-Wesley Professional Computing Series	May 1992.C.4	X Windows System Administrators Guide	Chapter 4	(C) 1992 O'Reilly & Associates, Inc.C.5	Information Security Handbook	William Caelli, Dennis Longley and Michael Shain	(C) 1991 MacMillan Publishers Ltd.C.6     Firewalls and Internet Security	William R. Cheswick & Steven M. Bellovin	(C) 1994 AT&T Bell Laboratories	Addison-Wesley Publishing CompanyC.7     CERT advisories can be found via anonymous FTP from	   ftp://ftp.auscert.org.au/pub/cert/cert_advisories/*C.8     UNIX System Administration Handbook        Nemeth, Evi, Garth Snyder and Scott Seebas	Prentice-Hall, Englewood Cliffs(NJ), 1989C.9     Essential System Administration	Aeleen Frisch        O'Reilly & Associates, Inc.-----------------------------------------------------------------------------Appendix D: Abbreviated Checklist	It is intended that this short version of the checklist be used in	conjunction with the full checklist as a progress guide (ie. check	the sections off as you go so that you remember what you have done	so far).  1.0   Patches [ ]    Installed latest patches?2.0   Network security [ ]    Filtering [ ]    "r" commands [ ]    /etc/hosts.equiv [ ]    $HOME/.rhosts [ ]    NFS [ ]    /etc/hosts.lpd [ ]    /etc/ttytab [ ]    /etc/inetd.conf [ ]    Trivial ftp (tftp)  [ ]    /etc/services    [ ]    tcp_wrapper (also known as log_tcp) [ ]    /etc/aliases [ ]    /etc/sendmail.cf         [ ]    majordomo [ ]    fingerd [ ]    UUCP	3.0   ftpd and Anonymous ftp [ ]    Versions [ ]    SITE EXEC [ ]    Configuration of your ftp server [ ]    Permissions [ ]    Writable directories [ ]    Disk mounting4.0   Password and account security [ ]    Policy [ ]    Proactive Checking [ ]    Root Password [ ]    NIS and /etc/passwd entries [ ]    Password shadowing and C2 security [ ]    Administration [ ]    Special accounts [ ]    Root account5.0   File system security [ ]    General [ ]    /etc/rc.local [ ]  	/usr/lib/expreserve [ ]    External file systems/devices [ ]    File Permissions [ ]    Files run by root [ ]    Bin ownership [ ]    Tiger/COPS6.0   SUNOS specific security [ ]    IP forwarding [ ]  	Framebuffers  /dev/fb 	 [ ]    /usr/kvm/sys/* [ ]    /dev/nit (Network Interface Tap)7.0   IRIX specific security [ ]    /usr/lib/vadmin/serial_ports8.0   X windows security [ ]	Problems with xdm [ ]	X security - General-----------------------------------------------------------------------------Appendix E: Shell ScriptsE.1   Script for printing the umask value for each user.#!/bin/shPATH=/bin:/usr/bin:/usr/etc:/usr/ucbHOMEDIRS=`cat /etc/passwd | awk -F":" 'length($6) > 0 {print $6}' | sort -u`FILES=".cshrc .login .profile"for dir in $HOMEDIRSdo	for file in $FILES	do		grep -s umask /dev/null $dir/$file	donedone-----------------------------------------------------------------------------The AUSCERT team have made every effort to ensure that the information contained in this checklist is accurate.  However, the decision to use the tools and techniques described is the responsiblitiy of each user or organization. The appropriateness of each item for an orgaization or individual system should be considered before application.  AUSCERT takes no responsibility for the consequences of applying the contents of this document.  Please feel free to copy and distribute this document provided you acknowledgeAUSCERT copyright.(C) Copyright 1995-----------------------------------------------------------------------------If you believe that your system has been compromised, contact AUSCERT or yourrepresentative in FIRST (Forum of Incident Response and Security Teams).Internet Email: AUSCERT@AUSCERT.org.auAUSCERT Hotline:      (07) 365 4417      Facsimile:      (07) 365 4477          AUSCERT personnel answer during business hours (AEST - GMT+10:00),	  on call after hours for emergencies.		  Australian Computer Emergency Response Teamc/- Prentice CentreThe University of QueenslandBrisbane, AustraliaQld.  4072.