unix computer security checklist.0

1000 HOWTOs for various needs [WINDOWS]

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