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