All files are for educational and/or historic purposes only. [back to library]


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

This document can be retrieved via anonymous ftp from the location

It is AUSCERT's intention to continue to update this checklist.  Any
comments should be directed via email to [email protected] 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. 

			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.
	    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 
            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, 
   *    ENSURE that you do NOT have a '+' entry by itself anywhere in the
   *    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
   *    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 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 
   *	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
            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/
   *    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: 
            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
            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
   *    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:                       /dev/console                       /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/`
            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
            [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:
                  (? will be B or S for the Binary or Source version)


   *    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 

   *    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 

   *    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:

 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 

 4.2  Proactive Checking

   *	DO use npasswd or passwd+ to proactively screen passwords as they are 
            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; 
	      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 
   *    CHECK that /etc/rc.local is set up to start ypbind with the -s
            This may not be applicable on all systems.  Check your 

 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 
   *    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
   *    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 
	           # /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
  	        # /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/ 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 
   *    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 
            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
		options "IPFORWARDING=-1" 
	    For information on how to customise a kernel, see the file: 

 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 

            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
            [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 

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
        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

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:

        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

A.2	AUSCERT's World Wide Web server
            AUSCERT maintains a World Wide Web server.  Its URL is

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:

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.

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.

B.4	tcp_wrapper
            This software gives logging and access control to most network
            services.  It is available via anonymous ftp from:
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:

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:*

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:

B.10	md5
	    md5 is a message digest algorithm.  An implementation of this is 
	    available via anonymous ftp from:**

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*

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/
 [ ]    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.


HOMEDIRS=`cat /etc/passwd | awk -F":" 'length($6) > 0 {print $6}' | sort -u`
FILES=".cshrc .login .profile"

for dir in $HOMEDIRS
	for file in $FILES
		grep -s umask /dev/null $dir/$file

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: [email protected]
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.