I Teach PHP.com
Apache Apache1.3 to 2.0
Configuration Basics
Install Fedora C1
Install Red Hat 7.2
Install Red Hat 7.3
SSH Clients
Virtual Hosting
links
syllabus
apache-refcard-letter

Bash Bash Shell Tips And Tricks
bash

CSS CSS2 Reference
links
syllabus

DHTML syllabus

HTML Basic HTML Tags
Creating Images
links
syllabus

Linux Install Fedora C1
Install Red Hat 7.2
Install Red Hat 7.3
Linux Basics
SSH Clients
links
mailme

Linux Clusters Cluster Books
Install Fedora C1
Install Red Hat 7.2
Install Red Hat 7.3
SSH Clients
syllabus

Linux Security Install Fedora C1
Install Red Hat 7.2
Install Red Hat 7.3
PHP Security
SSH Clients
Security QuickRef
UnixSecurity2.0
syllabus

Linux SysAdmin Install Fedora C1
Install Red Hat 7.2
Install Red Hat 7.3
PHP Security
SSH Clients
Security QuickRef
UnixSecurity2.0
syllabus
show book

Linux for Business Install Fedora C1
Install Red Hat 7.2
Install Red Hat 7.3
syllabus
show book

PHP 4 page DB system
Install Fedora C1
Install Red Hat 7.2
Install Red Hat 7.3
Linux Basics
PHP Security
Password Protect
Perl CGI Problems
Perl vs. PHP
Yahoo Stocks
links
syllabus

PHP for Flash 1-Flash Intro
2-Flash-PHP Form
Flash-PHP FAQ
Linux Basics
SSH Clients
syllabus

Perl Perl CGI Problems
SSH Clients
syllabus

TCP-IP Subnetting Tutorial
links

WML Yahoo Stocks
links
syllabus


E-MAIL
UnixSecurity2.0.html

UNIX Security Checklist v2.0

Introduction

This document has been published jointly by The Australian Computer Emergency Response Team (AusCERT) and the CERT® Coordination Center (CERT/CC) and details steps to improve the security of Unix Operating Systems. We encourage system administrators to review all sections of this document and if appropriate modify their systems accordingly to fix potential weaknesses.

The most current version of this document is available from:

http://www.auscert.org.au/Information/Auscert_info/papers.html
While this document details security procedures for UNIX based systems, it should not be used as a tool for recovering from a system compromise. For information regarding recovering from a system we encourage you to review the "Steps for Recovering from a UNIX or NT System Compromise" document, available from:
http://www.auscert.org.au/Information/Auscert_info/Papers/win-UNIX-system_compromise.html
It is our intention to continue to update this checklist. Any comments should be directed via email to auscert@auscert.org.au and cert@cert.org. Before using this document, ensure you have the latest version. New versions of this checklist will be placed in the same area and should be checked for periodically.

If possible, apply this checklist to a system before attaching it to a network. In addition, 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, with consideration given to the appropriateness of each action to your particular situation.

Disclaimer

AusCERT and CERT/CC advise that this information is provided without warranty - sites should ensure that actions and procedures taken from information in this document are verified and in accordance with security policies that are in place within their organisation. Listing of an application program or tool within this document does not constitute endorsement by AusCERT, The University of Queensland, or CERT/CC.

Table of Contents:

Section I. The First Step

Section II. The Basic Operating System

Section III. Major Services

Section IV. Specific Operating Systems

Section V. Appendixes

Section I. The First Step

1.0 Patches

  • Retrieve the latest patch list for your specific operating system, as well as any applications (i.e. web server, DNS, etc...) from the appropriate vendors. Install any security patches not yet installed that are recommended for your system. Be aware that some patches may re-enable default configurations. For this reason, it is important to go through this checklist AFTER installing ANY new patches or software packages.
  • Details on obtaining patches for particular operating systems may be found in Section IV.
  • Verify the digital signature of any signed files. Encryption tools like PGP and GnuPG may be used to sign files and to verify those signatures. Refer to A.2.10 for PGP and GnuPG access information.
  • If a digital signature is not supplied but an MD5 checksum is, then verify the checksum information to confirm that you have retrieved a valid copy. Refer to A.2.6 for information on obtaining MD5 tools.
  • If only a generic sum(1) checksum is provided, then check that. Be aware that the sum(1) checksum will only detect modifications during transfer (e.g. download) and won't detect malicious changes prior to download. For this reason, it is always preferable to verify files with either PGP/GnuPG or MD5.
  • Keep your software and patches up to date. Notifications of patch releases are generally done via mailing lists.
    • Subscribe to the vendor's security update mailing list for your particular operating system. Refer to Section IV for individual operating system vendors.
    • Subscribe to security advisory mailing lists from your local incident response team (if you have one). These mailing lists are typically low volume and provide invaluable information for system and security administrators. Refer to B.2.3 for information on subscribing to related mailing lists.


Section II. The Basic Operating System

2.0 Network Services

2.1 /etc/inetd.conf

  • ENSURE that the permissions on this file are set to 600.
  • 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. Even seemingly innocuous services such as echo and chargen may be used in a DoS attack.
    • Enable the ones you NEED by removing the "#" from the beginning of the line. In particular, it is best to avoid "r" commands (e.g. rsh, rlogin) 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 commands in C.1. For some systems (including AIX), these commands are not sufficient. Refer to vendor documentation for more information.
    • Verify that you have disabled any unnecessary startup scripts. This may be done by removing the executable bit, or renaming the files so they do not start with K or S under /etc/init.d or startup script directory for your system. See your vendor's documentation for specific details.
  • DO use tcp_wrappers to provide greater access and logging on any enabled network services (see 2.2).
  • DO enable access controls and logging for inetd if your version supports it.
  • CONSIDER alternatives to inetd. Xinetd is claimed to have enhanced access control and logging capabilities as well as resistance to DoS attacks. It is included in the Red Hat Linux 7 distribution and the source code is available for other systems from:
    • http://www.xinetd.org/
2.2 tcp_wrapper
  • ENSURE that you are using this package as it allows you to monitor and filter incoming requests for common network services.
  • See A.1.13 for instructions to obtain tcp_wrapper.
  • Customise and install it for your system.
  • Enable PARANOID mode.
  • CONSIDER running with the RFC931 (ident) option.
  • Explicitly list trusted hosts which are allowed access to services on your machine in /etc/hosts.allow.
  • Deny all other hosts by putting all:all:deny in /etc/hosts.allow. Please note that the rules in this file work on a "First match wins" basis, so be sure to allow any required hosts/services before you deny all other connections.
  • Put all:all in /etc/hosts.deny to protect services that still use this file.
  • DO wrap all TCP services that you have enabled in /etc/inetd.conf.
  • CONSIDER wrapping any UDP services you have enabled. If you wrap them, then you will need to enable the nowait option in the /etc/inetd.conf file.
2.3 fingerd
  • CONSIDER disabling the finger service if it is not considered essential.
  • ENSURE that you have an up-to-date version of fingerd. Do not use a version of fingerd that is older than 16 October, 2000. Refer to the AusCERT ESB:
    • ftp://ftp.auscert.org.au/pub/auscert/ESB/ESB-2000.286
  • Fingerd can provide a would-be intruder with a lot of information about your host. CONSIDER the finger information you provide and think about reducing the content by disabling finger or by replacing it with a version that only offers restricted information. [NOTE: Other services such as rusers and netstat may give out similar information.]
  • DO NOT enable reverse finger as this can create a 'finger war' DoS loop with other systems also configured for reverse finger.
  • ENSURE that you configure fingerd to deny indirect finger requests. (i.e. finger user@some_host@your_host)
2.4 "r" Commands
  • If you don't NEED to use the "r" commands (e.g. rlogin, rsh, rcp)...
    • DO disable all "r" commands unless specifically required, as they may increase your risk of password exposure in network sniffer attacks. Also, "r" commands have been a regular source of insecurities and attacks. Disabling them is by far the lesser of the two evils (Refer to 2.1).
  • If you must run the "r" commands...
    • CONSIDER replacing the "r" command functionality with more secure utilities, for example ssh and scp. Ssh is a vastly superior program over rsh, telnet, etc... because it encrypts your password as well as all data transmitted in the session. Refer to A.2.13 for information on where you can obtain ssh.
    • DO NOT allow the use of $HOME/.rhosts (See 2.6).
    • DO use more secure versions of the "r" commands for cases where there is a specific need. Wietse Venema's logdaemon package contains a more secure version of the "r" command daemons. These versions can be configured to consult only /etc/hosts.equiv and not $HOME/.rhosts. There is also an option to disable the use of wildcards ('+'). Refer to A.2.4 for access information for the logdaemon package.
    • DO filter ports 512, 513, and 514 (TCP) at your network border router to prevent access to them by people outside of your network. To limit access by people inside your network, these commands must either be disabled completely or restricted to certain hosts only by the configuration of the hosts.allow and hosts.deny files.
2.5 /etc/hosts.equiv
  • It is recommended that the following actions be taken whether or not the "r" commands are in use on your system.
    • CHECK if the file /etc/hosts.equiv is required. If you are running "r" commands, this file 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 your machine from a trusted machine without supplying a password. If you are not running "r" commands or you do not wish to explicitly trust other systems, you should have no use for this file and it should be removed or emptied. Creating /etc/hosts.equiv as a zero-length file enables it to be monitored by utilities such as Tripwire (A.1.15) for modification. If it does not exist or is empty, it cannot cause you any problems if any of the "r" commands are accidentally re-enabled.
  • If you must use a /etc/hosts.equiv 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) or NIS+.
    • DO only trust hosts within your domain or under your management.
    • ENSURE that your /etc/host.conf (or equivalent) is set to the order hosts, bind. Specify in /etc/hosts.equiv the hosts for which you wish to allow "r" commands.
    • ENSURE that you use fully qualified hostnames (i.e. hostname.domainname.au).
    • DO specify usernames in /etc/hosts.equiv if access is only required for specific users.
    • ENSURE that you do NOT have a '+' entry by itself anywhere in the file as this may allow users access to the system.
    • 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.6 $HOME/.rhosts
  • It is recommended that the following action be taken whether or not the "r" commands are in use on your system.
    • ENSURE that no user has a .rhosts file in their home directory. These files 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, (e.g. running unattended backups over a network) so consider each one on a case-by-case basis.
    • DO use cron to periodically check for, report the contents of and delete (or clear) $HOME/.rhosts files. Users should be made aware that you regularly perform this type of audit, as directed by your internal policy.
  • If you must have such a file:
    • ENSURE that you do NOT have the symbol "-" as the first character in this file, or the symbol "+" on any line, as these may allow users access to the system.
    • ENSURE that the permissions are set to 600.
    • ENSURE that you use fully qualified hostnames (i.e. hostname.domainname.au).
    • ENSURE that your /etc/host.conf (or equivalent) is set to the order hosts, bind and specify in it the hosts for which you wish to allow "r" commands.
    • ENSURE that the owner of the file is the account's owner.
    • ENSURE that usernames are specified.
    • ENSURE that usage of netgroups within .rhosts does not allow unintended access to this account. This is best achieved by specifying individual users and hosts you want to have access.
    • REMEMBER that you can also use logdaemon to restrict the use of $HOME/.rhosts (Refer to A.2.4).
2.7 /etc/netgroup
  • If you require the functionality of NIS, CONSIDER using NIS+ due to the inherent insecurity of NIS (YP).
  • If you are using NIS (YP) or NIS+, DO define each netgroup to contain only usernames or only hostnames. All utilities parse /etc/netgroup for either hosts or usernames, but never both. Using separate netgroups makes it easier to remember the function of each netgroup. The added time required to administer these extra netgroups is a small cost to ensure that strange permission combinations have not left your machine in an insecure state. Refer to the manual pages for more information.
  • ENSURE that the permissions on this file are set to 600.
  • ENSURE that the owner is set to root.
2.8 /etc/services
  • ENSURE that the permissions on this file are set to 644.
  • ENSURE that the owner is root.
2.9 /etc/hosts.lpd
  • ENSURE that the owner is set to root.
  • ENSURE that the permissions on this file are set to 600.
  • ENSURE that you use fully qualified hostnames (i.e. hostname.domainname.au).
  • CONSIDER preventing lpd from listening to the network unless necessary. It may be possible to accomplish this with command-line arguments - refer to your vendor documentation or man pages.
  • DO filter the printer port (515/tcp) on your routers. Many of the recent worms exploit buffer overflows in lpd.
2.10 /etc/login.access
  • CONSIDER using this file as it provides finer control over user access. Please refer to your vendor documentation for more details. [NOTE: This file may not exist on all versions of Unix.]
  • CONSIDER modifying this file to disallow remote access to privileged accounts. An example to disallow non-local logins to privileged accounts (group wheel):
    • -:wheel:ALL EXCEPT LOCAL
  • ENSURE that the owner is set to root.
  • ENSURE that the permissions on this file are set to 600.
  • ENSURE that you use fully qualified hostnames or domains (i.e. hostname.domainname.au or .domainname.au)
2.11 /etc/login.conf
  • This file is used by default on some BSD systems, users that are not created with a specified class are in the 'default' class.
  • DO use this file to set up user environment and to set policy and accounting restrictions.
  • ENSURE that the owner is set to root.
  • ENSURE that the permissions on this file are set to 600.
  • CONSIDER creating specific user classes to enable finer control of users.
2.12 /etc/login.defs
  • This file is used by some Linux systems.
  • DO use this file to provide centralised control over user environment settings.
  • ENSURE that the owner is set to root.
  • ENSURE that the permissions on this file are set to 600.
2.13 PAM (Pluggable Authentication Modules)
  • Be aware that PAM may be operational by default on your system.
  • To find out if a given executable uses PAM, execute the command ldd [path to executable file]. For example, the resulting output for /usr/bin/login on a FreeBSD 4.x system:
    •     /usr/bin/login:
    libutil.so.3 => /usr/lib/libutil.so.3 (0x28068000)
    libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x28072000)
    libpam.so.1 => /usr/lib/libpam.so.1 (0x28074000)
    libc.so.4 => /usr/lib/libc.so.4 (0x2807d000)
    Note the libpam.so.1, this is a PAM module.
  • Depending on the system, PAM may be configured with the file /etc/pam.conf or with individual configuration files in /etc/pam.d/.
  • ENSURE that PAM is configured to be secure by default - a misconfigured service may result in an attempt to authenticate using a less secure mechanism, which should be always denied.
  • CONSIDER disabling unneeded services under PAM, either by renaming/deleting the individual files or by editing /etc/pam.conf.
  • More information about PAM is available from:
    • http://www.kernel.org/pub/linux/libs/pam/
    http://www.sun.com/solaris/pam/
2.14 cron
  • ENSURE that the permissions for root's crontab are set to 600.
  • ENSURE that the owner is set to root.
  • CONSIDER disallowing cron for regular users.
2.15 Secure terminals
  • This file may be called /etc/ttys, /etc/default/login, /etc/security or /etc/securetty depending on the operating system. See the manual pages for file format and usage information.
  • ENSURE that this file is owned by root.
  • ENSURE that the permissions on this file are 600.
  • DO NOT allow remote root access.
  • ENSURE that the secure option is removed from all local entries that don't need root login capabilities. The secure option should be removed from console if you do not want users to be able to reboot in single user mode. [NOTE: This does not affect usability of the su(1) command.]
2.16 RPC
  • ENSURE that your system is not running a vulnerable rpc.statd. Refer to the AusCERT ESB:
    • ftp://ftp.auscert.org.au/pub/auscert/ESB/ESB-2000.222
  • DO use secure RPC for the running services where possible.
  • DO filter port 111 (tcp) on your router to disable access to RPC services from outside your network.
  • 2.16.1 portmapper/rpcbind
    • DON'T enable the portmap service unless necessary. A machine that doesn't use the sunrpc services (i.e. NFS or NIS) doesn't need portmap.
    • DO disable any non-required services that are registered with the portmapper on start up. See C.2 for a command to help check for registered services.
    • CONSIDER replacing portmapper/rpcbind with a more secure version which can restrict local forwarding of rpc calls (indirect calls) and provides enhanced logging. See A.2.11 for more info.
2.17 Trivial FTP (tftp)
  • DO disable tftp if not needed, comment it out from the file /etc/inetd.conf and restart the inetd process. (Refer to C.1)
  • If required, DO create a separate partition to store the files to be served by tftp and limit the tftp daemon to the directory where this partition is mounted.
  • ENSURE that the files in the tftp area are not writable.
2.18 Majordomo 2.19 UUCP
  • DO disable the uucp account, including it's login shell, if it is not used at your site. Remember, uucp may be shipped in a dangerous state.
  • REMOVE any .rhosts file at the uucp home directory.
  • ENSURE that the file L.cmds is owned by root.
  • ENSURE that no uucp owned files or directories are world writable.
  • ENSURE that you have assigned a different uucp login for each site that needs uucp access to your machine.
  • ENSURE that you have limited the number of commands that each uucp login can execute to a bare minimum.
  • CONSIDER deleting the whole uucp subsystem if it is not required.
  • ENSURE there are no vendor-supplied uucp or root crontab entries.
2.20 REXD
  • DO disable this service. Comment this out in the inetd.conf file. Refer to 2.1 for details on how to do this. rexd servers have little or no security in their design or implementation. Intruders can exploit this service to execute commands as any user.


3.0 Networking Administration

3.1 Packet Filtering

  • DO use packet filtering at network or administrative borders to enforce security policies by restricting network traffic entering and leaving your domain.
  • DO use multi-layer firewalls, such as a host-based firewall in addition to network packet filtering.
  • DO use protocol type, destination address, and destination port information to construct packet filters to enforce security policies for inbound traffic.
  • ENSURE that ONLY packets for those services which require access across your network or administrative border are allowed to enter and leave your domain.
  • In particular, if external traffic to and from the following services is not required at your site, use packet filters to block traffic to and from the following services. Inbound filters should block based on protocol type and destination port. Outbound filters should block based on protocol type and source port.
    • 
    NAME       PORT/PROTOCOL    NAME              PORT/PROTOCOL

    tcpmux        1/tcp         netbios-ns         137/udp
    echo          7/tcp         netbios-dgm        138/tcp
    echo          7/udp         netbios-dgm        138/udp
    discard       9/tcp         netbios-ssn        139/tcp
    discard       9/udp         netbios-ssn        139/udp
    systat       11/tcp         imap               143/tcp
    daytime      13/tcp         snmp               161/udp
    daytime      13/udp         snmp-trap          162/udp
    netstat      15/tcp         xdmcp              177/udp
    chargen      19/tcp         exec               512/tcp
    chargen      19/udp         biff               512/udp
    ftp          21/tcp         login              513/tcp
    ssh          22/tcp         who                513/udp
    telnet       23/tcp         shell              514/tcp
    smtp         25/tcp         syslog             514/udp
    domain (DNS) 53/tcp         printer            515/tcp
    domain (DNS) 53/udp         talk               517/udp
    bootps       67/tcp         ntalk              518/udp
    bootps       67/udp         route              520/udp
    bootpc       68/tcp         klogind            543/tcp
    bootpc       68/udp         socks             1080/tcp
    tftp         69/udp         nfs               2049/tcp
    finger       79/tcp         nfs               2049/udp
    http         80/tcp         X11     6000 to 6000+n/tcp
    pop2        109/tcp
    pop3        110/tcp         (n = maximum number of X servers)
    sunrpc      111/tcp
    netbios-ns  137/tcp
  • ENSURE that ONLY hosts in your domain exchanging legitimate traffic with external hosts are allowed to send and receive packets for required services.
  • For inbound filters, use protocol type, destination address, and destination port. For outbound filters, use protocol type, source address, and source port.
  • Hosts not required to route TCP/IP packets should have this facility disabled. An example of disabling this for a Linux system:
    • echo 0 > /proc/sys/net/ipv4/ip_forward
  • Filtering can be difficult to implement correctly. For more information on packet filtering and firewalls, please see:
    • Firewalls and Internet Security B.1.6

    Building Internet Firewalls B.1.7

    Deploying Firewalls

    http://www.cert.org/security-improvement/modules/m08.html
3.2 Denial of Service Attacks 3.3 Encryption and Strong Authentication
  • DO use encryption technologies when administrating hosts and network equipment in your domain to prevent administrator passwords and other sensitive information from crossing your network in clear-text. Information on various methods is available from:
    • http://www.sans.org/infosecFAQ/encryption/encryption_list.htm
  • DO use strong authentication when accessing hosts in your domain to reduce the risk of a security breach due to false credentials.
  • The SSH protocol employs public key cryptography and provides both encryption and strong authentication. Refer to A.2.13 for information on where you can obtain ssh.


4.0 File system security

4.1 General

  • DO consider using the EXINIT environment variable to disable .exrc file functionality. These files may inadvertently perform commands that may compromise the security of your system if you happen to start either vi(1) or ex(1) in a directory which contains such a file. See C.11 for example commands to find .exrc files.
  • ENSURE that there are no .exrc files on your system that have no legitimate purpose.
  • ENSURE that any .forward files in user home directories do not execute an unauthorised command or program. The mailer may be fooled into allowing a normal user privileged access. Authorised programs may be restricted through use of smrsh (8.1 Sendmail). See C.12 for example commands to find .forward files.
  • ENSURE user or directories shared amongst users are not specified before system directories in executable search paths (allows installation of Trojan programs).
  • DO consider using mount options, such as nosuid, nodev and noexec for user home partitions, /var and /tmp in your /etc/fstab or vfstab file. (please refer to your specific operating system's documentation for the exact file and location)
  • DO consider setting filesystem limits. For example, by enabling quota support for individual users or by using the resource-limits PAM module.
4.2 Startup and Shutdown Scripts
  • ENSURE that the default umask for all programs is 022.
4.3 External File Systems/Devices
  • DO mount external file systems non-setuid and read-only where practical. For more information, refer to 11.1.
4.4 File Permissions
  • ENSURE that the permissions of /etc/utmp and /var/adm/wtmp are set to 644.
  • ENSURE that the permissions of /etc/motd and /etc/mtab are set to 644.
  • ENSURE that the permissions of /etc/syslog.pid (/var/run/syslog.pid on some systems) are set to 644. [NOTE: This may be reset each time you restart syslog.]
  • CONSIDER removing read access to system configuration files that users do not need to access, for example rc.* startup files and authentication files like /etc/hosts.allow.
  • ENSURE that logfiles (usually in /var/log/) are only writable by root.
  • CONSIDER using filesystem security features if your operating system supports them - system binaries may be made immutable, log files append-only.
  • ENSURE that the kernel (e.g., /vmunix) is owned by root, has group set to 0 (wheel on SunOS) and permissions set to 644.
  • ENSURE that /etc, /usr/etc, /bin, /usr/bin, /sbin, /usr/sbin, /tmp and /var/tmp are owned by root and that the sticky-bit is set on /tmp and on /var/tmp (see C.14) Refer to the AusCERT Advisory:
    • ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-95.07.Incorrect.Permissions.on.tmp.may.allow.root.access
  • ENSURE that there are no unexpected world writable files or directories on your system. See C.15 for example commands to find group and world writable files and directories.
  • ENSURE that files which have the SUID or SGID bit set, need to have it that way (see C.16). Remove this bit from programs that do not require elevated privileges to function successfully.
  • ENSURE the umask value for each user is set to something sensible like 027 or 077. (Refer to C.4 for a shell script to check this).
  • ENSURE all files in /dev are special files. Special files are identified with a letter (usually c for 'character' or b for 'block') in the first position of the permissions bits. See C.17 for a command to find files in /dev which are not special files or directories. [NOTE: Some systems have directories and a shell script in /dev which may be legitimate.] Please check the manual pages for more information.
  • ENSURE that there are no unexpected special files outside /dev. See C.18 for a command to find any block special or character special files.
4.5 Files Run by root

We recommend that any script or binary to be executed by root should be owned by root and should not be world or group writable. Additionally, this file should only be located in a directory for which every parent directory 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
    • files on NFS partitions
    • /etc/rc* and similar system startup and shutdown files
  • If any programs or scripts referenced in these files source further programs or scripts they also need to be verified.
4.6 Bin Ownership

Many systems ship files and directories owned by bin (or sys). 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. - Please note that under Solaris 2.x changing ownership of system files can cause warning messages during installation of patches and system packages. One utility available to help Solaris administrators avoid this problem is fix-modes (A.2.3). Anything else should be verified with the vendor.
4.7 Tiger
  • DO run Tiger or a similar program that can automatically parse log files or check for vulnerable files. Many of the checks in this section can be automated by using this type of program.
  • To obtain this program, see A.1.14
4.8 Tripwire
  • Tripwire is a file integrity checker, it is used for intrusion detection by monitoring for file-system changes.
  • DO run the statically linked binary.
  • DO store the binary, the database and the configuration file on hardware write-protected media.
  • To obtain this program, see A.1.15
4.9 The Coroner's Toolkit
  • A forensic analysis tool, written by Wietse Venema and Dan Farmer. It may be used to statically examine storage devices from a compromised system, or to monitor a running system for unusual files or processes.
  • DO run this tool for compromise recovery and analysis on a non-networked machine.
  • To obtain this program, see A.1.8


5.0 Account Security

5.1 Policy

  • ENSURE that you have a password policy for your site. See the AusCERT Advisory:
    • ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-93.04.Password.Policy.Guidelines
    for guidelines on developing password policies.
  • 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.
  • DO use anlpasswd or a similar utility to proactively screen passwords as they are entered. This program runs a series of checks on passwords when they are set, which assists in avoiding poor passwords. It works with normal, shadow and NIS (or yp) password systems. (Refer to A.1.2 for how to obtain it)
  • DO apply and enforce password aging.
  • It is possible to implement both proactive password screening and aging with Pluggable Authentication Modules (PAM). This facility provides for other forms of access control - consult the documentation if it is available for your system. Similar functionality is available in the /etc/login.defs file on some Linux systems.
  • CONSIDER checking passwords periodically with Crack or "John the Ripper" or other password cracking program. (Refer to A.2.2 for how to obtain these programs). Organisations may wish to incorporate this procedure into a published security policy.
  • DO implement the use of sudo in installations where multiple users require the ability to run processes as root. sudo allows for greater security by providing configurable limitations on the use of the root account. sudo will also log all attempts to use it via syslog or to a specified file. sudo is available from:
    • http://www.courtesan.com/sudo/
    http://www.stikman.com/sudo/
  • CONSIDER implementing a Role Based Access Control mechanism such as RBAC which was developed by the National Institute of Standards and Technology (NIST). (Refer to A.2.12 for additional information)
5.2 Administration
  • ENSURE that you regularly audit your system for dormant accounts and disable any that have not been used for a specified period of time, in accordance with your site's security policy. Send out account renewal notices by post and delete any accounts of users that do not respond. [NOTE: Do not email renewal notices because any accounts being used illegitimately will reply as expected and hence will not be discovered.]
  • ENSURE that all accounts have passwords. Check shadow, NIS, and NIS+ passwords too, if you have them. (i.e. the password field is not empty)
  • ENSURE that any user area is adequately backed up and archived.
  • DO regularly monitor logs for successful and unsuccessful su(1) 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.
  • Consider requiring that users physically identify themselves before granting any requests regarding accounts (e.g., before creating a user account).
5.3 Special Accounts
  • ENSURE that there are no shared accounts other than root in accordance with site security policy. (i.e. more than one person should not know the password to an account)
  • Disable guest accounts. Better yet, do not create guest accounts! [NOTE: Some systems come preconfigured with guest accounts.]
  • DO use special groups (such as the "wheel" group under FreeBSD) to restrict which users can use su to become root.
  • DISABLE ALL default vendor accounts shipped with the Operating System. This should be checked after each upgrade or installation.
  • DO disable accounts that have no password which execute a command, for example "sync". Delete or change ownership of any files owned by these accounts. Ensure that these accounts do not have any cron or at jobs. It is best to remove these accounts entirely.
  • DO assign non-functional shells (such as /bin/false) to system accounts such as bin and daemon and to the sync account if it is not needed.
  • DO put system accounts in the /etc/ftpusers file so they cannot use ftp. This should include, as a MINIMUM, the entries: root, bin, uucp, ingres, daemon, news, nobody and ALL vendor supplied accounts.
5.4 root Account
  • DO restrict the number of people who know the root password. These should be the same users registered with groupid 0. Typically this is limited to at most 3 or 4 people.
  • DO NOT log in as root over the network, in accordance with site security policy.
  • DO su from user accounts rather than logging in as root. This provides greater accountability.
  • ENSURE root does not have a ~/.rhosts file.
  • ENSURE "." is not in root's search path.
  • ENSURE root's login files do not source any other files not owned by root or which are group or world writable.
  • ENSURE 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. (e.g. /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 "./" (e.g. ./command)
5.5 .netrc Files
  • DO NOT use .netrc files unless it is absolutely necessary.
  • If .netrc files must be used, DO NOT store password information in them.
5.6 GCOS Field
  • DO include information in the GCOS field of the password file which can be used to identify your site if the password file is stolen. e.g., joe:*:10:10:Joe Bloggs, Organisation X:/home/joe:/bin/sh
5.7 Authentication
  • 5.7.1 NIS, NIS+ and /etc/passwd Entries
    • DO NOT run NIS or NIS+ if you don't really need it.
    • If NIS functionality is required, DO use NIS+ if possible due to the additional security features provided.
    • ENSURE 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. See C.10 for instructions.
    • ENSURE that /etc/rc.local or the equivalent startup procedure is set up to start ypbind with the -s option. This may not be applicable on all systems. Check your documentation.
    • DO use secure RPC if available for your platform. This is also known as DES authentication and is a Sun Microsystems secure authentication mechanism for RPC. It depends on synchronised clocks and a shared DES key. See the manpage for nisaddcred for more info.
  • 5.7.2 Password Shadowing
    • DO enable vendor supplied password shadowing or a third party product. Password shadowing restricts access to users' encrypted passwords.
    • DO periodically audit your password and shadow password files for unauthorised additions or inconsistencies.
  • 5.7.3 One-Time Passwords
    • CONSIDER using One-Time Passwords if users log into your machine via an insecure connection or protocol (such as telnet or ftp).
    • NEVER generate the master key or password lists over an insecure connection or protocol - these should be done locally on a secure (preferably not networked) machine.
    • ENSURE your users do not store password lists on or near their computer.
    • Minimise the number of passwords given to each user.
    • CONSIDER imposing a limit to the number of sequential failed logins. [NOTE: This has the possibilities of creating a DoS situation.]
    • A commonly used free version is Secure Key (S/KEY). This is implemented by default in the FreeBSD operating system. See A.2.8.
    • One-Time Passwords in Everything (OPIE) is another free implementation of non-replayable passwords. See A.2.8.
  • 5.7.4 Lightweight Directory Access Protocol (LDAP)
    • LDAP is a protocol for accessing online directory services.
    • LDAP supports encryption and access control lists.
    • ENSURE that you provide access controls for services provided by an LDAP server.
    • An open-source implementation of LDAP is available from:
      • http://www.openldap.org/
    • A historical reference page for LDAP is at:
      • http://www.umich.edu/~dirsvcs/ldap/


6.0 System Monitoring

DISCLAIMER: We recommend you consult your organisation's security and privacy polices, as well as any laws for your area before implementing any of the suggestions in this section.

6.1 Account Security

  • DO regularly expire user passwords.
  • CONSIDER performing periodic checks of password security by running a cracking tool - for example, Crack or "John the Ripper" (See A.2.2) - against your password file.
  • CONSIDER enabling auditing capabilities if available for your system - Solaris for example has a C2 auditing facility.
  • DO actively monitor processes on your machines - tools are available that make it possible to do this remotely, like Big Brother (See A.1.3)
  • DO run process accounting.
  • CONSIDER logging all login attempts, both successful and unsuccessful.
  • DO examine accounting logfiles for activity, for example for su attempts.
  • CONSIDER disabling accounts after a number of failed login attempts. [NOTE: This has the possibilities of creating a DoS situation.]
6.2 Log Files
  • DO make use of facilities provided with your operating system to assist with disseminating log files e.g. FreeBSD emails a summary of important system and security information to root as part of its pre-configured crontab.
  • DO use a reliable mechanism for log rotation. This may include replacing an existing logging daemon with a more secure or full-featured one.
  • DO use network and system daemons that have more comprehensive logging features, such as logdaemon (See A.2.4) and tcp wrappers (See A.1.13).
  • DO make use of syslog facilities for network logging and log to more than one host if possible.
  • CONSIDER protecting your logfiles with filesystem security if possible, for example FreeBSD and Linux support flags to make files append-only.
6.3 Network Security
  • DO use utilities to enable output profiling of log data, such as ISS (See A.3.1.3) or SAINT (See A.3.2.2).
  • CONSIDER implementing automated reporting facilities so that scans of your network are reported to the administrators of their originating domains.
  • DO check system files for modification regularly, using tools like Tripwire (See A.1.15).
  • DO keep a logbook of all sysadmin activity on each host on your network.
  • lsof (See A.2.5) is a tool for monitoring open system files and may be used to check for any suspicious activity.
  • DO thoroughly document any procedures associated with system modifications or upgrades.


Section III. Major Services

7.0 Name Service

7.1 BIND

7.2 Alternatives


8.0 Electronic Mail

8.1 Sendmail

  • DO use the latest version of Eric Allman's sendmail. The latest version is available via anonymous FTP from:
    • http://www.sendmail.org/
    NOTE: If you don't already run the current version of sendmail, then it may take you some time to build, install, and configure the system to your needs. For example, other sendmail configuration files may not be compatible with the latest version of sendmail.
  • If you use a vendor version of sendmail, ENSURE that you have installed the latest patches as sendmail has been a source of several security vulnerabilities.
  • DO use smrsh if you require progmailer functionality to limit sendmail's scope of program execution to programs in smrsh configuration only. smrsh is a restricted shell utility that may be configured to execute a specific list of programs. smrsh is included with recent versions of sendmail.
  • If you do not require progmailer functionality then DO disable mail to programs by setting this field to /bin/false in the sendmail configuration file.
  • ENSURE sendmail is configured to deny relaying from unknown hosts. This helps to prevent your mail server from being used inappropriately. (e.g. for spam/UCE)
  • DO increase sendmail logging to a minimum log level of 9. This will help detect attempted exploitation of the sendmail vulnerabilities. See C.5 for example commands.
  • 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. See C.6 for example code and instructions.
  • CONSIDER disabling the daemon mode on client hosts. This will still allow clients to use sendmail for mail delivery. If this is implemented, CONSIDER adding sendmail -q to your crontab to ensure delayed messages are delivered.
  • REMEMBER that you will need to restart sendmail for any changes to take effect. If you are running a frozen configuration file (sendmail.fc), you will need to rebuild it before restarting sendmail (C.7). Note that sendmail v8.x no longer supports frozen configuration files.
  • 8.1.1 /etc/aliases
    • ENSURE that all programs executable by an alias are owned by root, have permissions 755 and are stored in a directory specified by smrsh configuration e.g., /usr/libexec/sm.bin. Refer to your sendmail documentation for more details (8.1 Sendmail).
8.2 Alternatives (qmail and postfix)
  • 8.2.1 qmail by D. J. Bernstein
    • DO use the latest version of qmail. It is available at:
      • http://cr.yp.to/qmail.html
    • Make sure you read all the documentation before you even begin to install and compile it.
    • It is recommended that qmail be used with tcpserver instead of inetd. It is available at:
      • http://cr.yp.to/ucspi-tcp.html
    • qmail contains a sendmail 'dropin' to make conversion between the two transparent to users.
  • 8.2.2 postfix by Wietse Venema
    • DO use the latest version of postfix. To find your nearest anonymous FTP site for download, see:
      • http://www.postfix.org/ftp-sites.html
    • ENSURE you have installed the relevant patches. See postfix's download page (above) for more information.
    • postfix's homepage can be found at:
      • http://www.postfix.org
    • postfix has been designed to avoid common security problems such as shell access, set-uid, buffer overruns and DoS.
    • If you are thinking of using postfix instead of sendmail, read the documentation found on the postfix website and the mailing lists.
8.3 POP/IMAP
  • ENSURE that you have the latest version of your POP/IMAP software - there are known vulnerabilities in some previous and some obsolete POP/IMAP implementations. Ask your vendor for details if you are unsure.


9.0 Web Security

9.1 General Configuration

  • 9.1.1 chroot
    • DO consider running the web server as a chrooted process. Changing the root environment so that the http service runs in a properly restricted area can minimise damage resulting from a compromised web server.
    • CONSIDER placing static files onto a read-only media, such as a hardware write-protected hard disk or CD-ROM.
  • 9.1.2 CGI Programming
    • ENSURE the server is configured to execute only those CGI scripts which reside in the CGI binary directory, e.g., /cgi-bin. Set the ownership and permissions on this directory to 755 or 751. Consider monitoring changes to these scripts with such programs as Tripwire.
    • ENSURE that all default or example CGI scripts are backed up and removed if not needed or thoroughly tested for signs of bad programming practices (refer point below).
    • DO audit CGI scripts for bad programming practices, for example, the use of:
      • within perl - eval, exec, open() to a pipe, backticks, and the regular expression modifier /e all may fork a process. These can potentially be subverted to allow an attacker to run an arbitrary command
      • within C and C++ - popen() and system() are at risk in a similar manner as perl above and can be subverted easily to allow shell access.
    • DO test for untrustworthy user input. For example:
      • unexpected input values - may cause the script to perform actions which were not intended by the author;
      • special characters - may allow unauthorised access. A preferred alternative to checking for a list of dangerous/special characters is to specify a list of allowable characters;
      • unexpectedly large input - may cause buffer overflow or inappropriate actions;
      • any other potential abuses.
    • DO use the tainting feature of Perl. CGI scripts written in Perl should be invoked with perl -T.
    • DO consider implementing CGI wrappers. Wrappers can be used to perform security checks on the script, e.g. - change the ownership of the CGI process, or use chroot as discussed above.
    • CONSIDER reading available documents on the Internet regarding secure programming. See B.2.5
  • 9.1.3 daemon non-root uid
    • ENSURE that you DO NOT run your web service as root. The UID and GID of the service should be changed, after it has been started, to a user and group that has no privileged access on the server. The most popular Unix web server, Apache, lowers its ownership level immediately after starting - it still must be invoked as root to allow it to bind to a privileged port. This avoids the risk of any scripts the web service executes running as root.
    • DO set up script directories (e.g cgi-bin) to be owned by root and set permissions to 751. This prevents users from viewing contents of the directory whilst allowing the daemon to run the scripts within it. Additionally, if the server is compromised by sending unexpected input to a CGI script, the user that is running the server has no permission to edit or remove files from the script area.
    • DO set up the web server directory with root ownership.
    • ENSURE configuration, log, and binary files for the web server are owned by root and set permissions to 755.
  • 9.1.4 Command Interpreters
    • ENSURE that shells and command interpreters are removed from the web documents path.
    • CONSIDER running the web server machine solely for the purpose of being a web server (e.g. - do not run any other services such as mail, DNS etc) For such a server also remove all unnecessary accounts, unnecessary utilities, programs, compilers etc. and do not export any directories.
  • 9.1.5 SSL
    • DO consider using SSL (Secure Socket Layer) for encrypting any TCP/IP protocols in use. SSL can be used for server authentication, client authentication, and transmitting encrypted data.
    • DO consider using SHTTP (Secure HTTP).
  • 9.1.6 Additional Configuration Matters
    • DO consider configuring the web server to not allow automatic directory listing if an index.html file is not present in the directory.
    • DO consider configuring the web server to not follow symbolic links. This prevents a user with access to the web server's document tree from making other documents, outside the tree, available via symbolic links.
    • DO consider preventing or limiting use of server-side includes. Some web servers can be configured to limit processing of server-side includes to specific directories.
    • ENSURE that the directory of the documents served by the web server is not also available via anonymous FTP. Any restrictions to access to the documents set by the web server would be circumvented by anonymous FTP.
9.2 Freely Available Servers 9.3 Client Configuration
  • DO NOT allow external programs to spawn for any downloaded files or content that contain executable material.
  • ENSURE web browsers are NOT configured to automatically run files when downloaded from the Internet. This includes not allowing browsers to automatically launch command line shells, interpreters, macro processors, and scripting language processors. This may be achieved using the application preferences for the browser.
  • DO consider terminating connections to secure pages if the web browser alerts that the host name in site certificate does not match the host name of the server the certificate came from.
  • DO consider rejecting site certificates signed by an unknown certifying authority.
  • ENSURE Java, JavaScript ActiveX are disabled in the web browser and built-in email readers that may come with the browser.
  • If you MUST enable Java, JavaScript, or ActiveX ENSURE you are running the latest version of your browser and respective run-time environments. This includes all related security patches.
  • DO NOT run a web browser as root.
  • CONSIDER removing cookies on a periodic basis. Alternatively consider making a symbolic link between the cookies file (e.g. ~/.netscape/cookies) and /dev/null.
  • DO consider utilising anti-virus software.
  • ENSURE web browsers are patched against the latest known security vulnerabilities.


10.0 FTP: ftpd and anonymous ftp

10.1 General Server Configuration

  • ENSURE that you are using the most recent version of the FTP daemon of your choice.
  • CHECK all default configuration options on your FTP server.
  • ENSURE that your FTP server does not have the SITE EXEC command (see C.8 for command details), or that this command is disabled correctly.
  • ENSURE 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 all default configuration options on your FTP server. Not all versions of ftp daemons are configurable. If you have a configurable version of ftp (e.g., 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.
  • ENSURE that you DO NOT include a command interpreter (such as a shell or tools like perl) in ~ftp/bin, ~ftp/usr/bin, ~ftp/sbin or similar directory configurations that can be executed by SITE EXEC. For an example of a previous vulnerability, refer to AusCERT advisory:
    • ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-2000.02
  • DO NOT keep system commands in ~ftp/bin, ~ftp/usr/bin, ~ftp/sbin or similar directory configurations that can be executed by SITE EXEC. It may be necessary to keep some commands, such as uncompress, in these locations. Consider the inclusion of each command on a case by case basis and be aware that the presence of such commands may make it possible for local users to gain unauthorised access. Be wary of including commands that can execute arbitrary commands. For example, some versions of tar may allow you to execute an arbitrary file.
  • ENSURE that you use an invalid password and user shell for the ftp entry in the system password file and the shadow password file (if you have one). It should look something like:
    • ftp:*:400:400:Anonymous FTP:/home/ftp:/bin/false
    where /home/ftp is the anonymous FTP area.
  • 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 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 e.g.:
    • root:*:0:0:Ftp maintainer::
    ftp:*:400:400:Anonymous ftp::
    The password file is used only to provide uid to username mapping for ls(1) listings.
  • ENSURE 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 do not exist.
  • DO set the login shell of the ftp account to a non-functional shell such as /bin/false.
  • 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 NO files or directories in the FTP area are world writable.
  • ENSURE that the anonymous ftp user cannot create files or directories in ANY directory unless required (Refer to 10.1)
  • ENSURE that the anonymous ftp user can only read information in public areas.
  • 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 that there is a mail alias for ftp to avoid mail bounces.
  • ENSURE /usr/spool/mail/ftp is owned by root with permissions 400.
  • NEVER mount disks from other machines to the ~ftp hierarchy unless they are set read-only in the mount command.
10.2 Incoming Directories
  • ENSURE 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, for instance an 'upload' directory.
  • ENSURE that writable directories are not also readable. Directories that are both writable and readable may be used in an unauthorised manner.
  • ENSURE 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.
10.3 Freely Available Servers
  • 10.3.1 WU-FTP
    • Make sure you are using the latest version of WU-FTPD and have applied all recommended patches. Versions of WU-FTPD prior to 2.6.1 have known security vulnerabilities.
    • WU-FTPD can be found at:
      • http://www.wu-ftpd.org
  • 10.3.2 ProFTPD
    • ProFTPD does not support the SITE EXEC command.
    • ProFTPD can use mySQL password databases instead of password files, although at the time of writing there are a few known bugs, and compilation of ProFTPD with mySQL support can be difficult.
    • There are several mailing lists for ProFTPD, including development and help lists.
    • DO install the latest version of ProFTPD - previous versions are known to have bugs that may lead to security problems (but are more likely to cause problems in use.)
    • ProFTPD can be found at:
      • http://www.proftpd.net/
  • 10.3.3 Publicfile
10.4 Anonymous FTP Only
  • To ascertain whether you are running anonymous FTP, try to connect to the localhost using anonymous FTP. Be sure to give an RFC822 compliant username as the password (See C.9).
  • To disable anonymous FTP, move or delete all files in ~ftp/ and then remove the user ftp from your password file.
  • If you are running distributed passwords (e.g. NIS, NIS+) then you will need to check the password entries served to your machine as well as those in your local password file.
  • ENSURE that if you want to use anonymous FTP you have configured your server correctly. In general, anonymous users should not be allowed to create directories, delete anything, change the file system in any way (for instance change the permissions of a file) or upload files. If you do want anonymous users to upload files, follow the instructions above about general server configuration.
  • Limit the number of anonymous connections allowed, and also the number of times a single IP can be logged in at once. Anonymous should only be allowed to have one session active at a time - otherwise you leave yourself open to a DoS attack.


11.0 File Services

11.1 NFS

When using NFS, you implicitly trust the security of the NFS server to maintain the integrity of the mounted files.

  • 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 apply all available patches. NFS has had a number of security vulnerabilities.
  • DO disable NFS if you do not need it. See your vendor supplied documentation for detailed instructions.
  • DO enable NFS port monitoring. Calls to mount a file system will then be accepted from ports < 1024 only. This will provide added security in some circumstances. See your vendor's documentation to determine whether this is an option for your version of UNIX (see also 15.4).
  • DO use /etc/exports or /etc/dfs/dfstab to export ONLY the file systems you need to export. If you aren't certain that a system needs to be exported, then it probably shouldn't be exported.
  • DO NOT self-reference an NFS server in its own exports file (i.e. the exports file should not export the NFS server to itself in part or in total). In particular, ensure the NFS server is not contained in any netgroups listed in its exports file.
  • DO NOT allow the exports file to contain a 'localhost' entry.
  • DO export to fully qualified hostnames only (i.e. use the full machine address 'machinename.domainname.au' and do not abbreviate it to 'machinename').
  • ENSURE that you never export file systems unintentionally to the world. Use a -access=host.domainname.au option or equivalent in /etc/exports.
  • DO export file systems read-only (-ro) whenever possible. See the manual page for exports or dfstab for more information.
  • If NFS is required in your situation, then DO use the secure option in the exports file and mount requests (if the secure option is available).
  • DO use showmount -e to see what you currently have exported.
  • ENSURE that the permissions of /etc/exports are set to 644.
  • ENSURE that /etc/exports is owned by root.
  • ENSURE that you run a portmapper or rpcbind that does not forward mount requests from clients. A malicious NFS client can ask the server's portmapper daemon to forward requests to the mount daemon. The mount daemon processes the request as if it came directly from the portmapper. If the file system is self-mounted this gives the client unauthorised permissions to the file system. Refer to A.2.11 for how to obtain an alternate portmapper or rpcbind that disallow proxy access.
  • REMEMBER that changes in /etc/exports will take effect only after you run /usr/etc/exportfs or equivalent.
  • You may wish to test your NFS implementation with NFSbug, a program which scans for known NFS holes. It is available from:
    • ftp://ftp.cs.vu.nl/pub/leendert/nfsbug.shar
NOTE: A "web of trust" is created between hosts connected to each other via NFS. That is, you are trusting the security of any NFS server you use.

11.2 Alternatives

  • 11.2.1 Samba


    • The Samba service provides filesystem shares to clients that are running other operating systems, usually a version of Microsoft Windows.

    • DO enable encrypted passwords for Samba using smbpasswd.
    • DO configure your shares for user-level security using the
      • security = user
      parameter in smb.conf.
    • DO restrict access to your Samba service with the parameters:
      • hosts allow =
      hosts deny =
    • DO protect your Samba services with firewall rules - Samba file services use NetBIOS over TCP/IP (also referred to as NBT and NetBT), so ports 135, 137, 138, and 139 (TCP) should be filtered.
    • CONSIDER using stronger authentication methods. Samba supports alternative authentication models, including Kerberos and Pluggable Authentication Modules (PAM).
    • CONSIDER encrypting your Samba traffic. Samba supports the Secure Sockets Layer (SSL) protocol.
    Samba sources and documentation are available from:
    http://www.samba.org/
  • 11.2.2 Andrew File System (AFS)


    • AFS is a distributed filesystem that makes use of Kerberos to authenticate users. It allows the use of access control lists (ACLs). It is available from the Transarc Corporation.

    • CONSIDER using AFS if it is available for your platform and appropriate for your needs.
    Information is available from:
    ftp://ftp.transarc.com/pub/afs-contrib/doc/faq/afs-faq.html
    http://www.transarc.ibm.com/Product/EFS/AFS/index.html
  • 11.2.3 DFS


    • DFS is a distributed filesystem, also available from the Transarc Corporation. Information is available from:

    http://www.transarc.ibm.com/Product/EFS/DFS/index.html


12.0 X Window System

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 window system security referred to in the X Window System Administrators Guide (B.1.4).

12.1 X Security - General

  • DO read the man pages for xauth and Xsecurity. Use this information to set up the security level you require.
  • ENSURE that the permissions on /tmp are set to 1777. (i.e. the sticky bit should be set) The owner MUST always be root and group ownership should be set to group-id 0 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 will no longer be accessible. See C.14 for example commands to set the correct permissions and ownership for /tmp.
  • DO use the X magic cookie mechanism MIT-MAGIC-COOKIE-1 or better. With logins under the control of xdm (see 12.2), you can turn on authentication by editing the xdm-config file and setting the DisplayManager*authorize attribute to true. When granting access to the screen from another machine, use the xauth command in preference to the xhost command.
  • DO not permit access from arbitrary hosts. Remove all instances of the xhost + command from the system-wide Xsession file, from user .xsession files, and from any application programs or shell scripts that use the X window system.
  • CONSIDER encrypting your X network traffic, especially if you run remote clients locally. Ssh is a useful method.
  • CONSIDER configuring workstations to disable listening for incoming X sessions over the network. This is done on some operating systems by using the -nolisten tcp option. You should consult your specific operating system's documentation for specific instructions.
12.2 Problems with xdm

DO not use any version of X11 prior to release 6 as it resolved security problems that existed in earlier versions. If necessary, obtain the source for X11R6 and compile and install it on your system. This may be obtained from:

http://www.x11.org
  • 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.
  • Newer window managers that are available for Unix and Unix clones are provided with different X display managers (e.g. gdm, the Gnome project item) so you should check that there are no vulnerabilities specific to the instance of display manager that you choose.


Section IV. Specific Operating Systems

13.0 BSD-derived Operating Systems

13.1 BSD/OS

13.2 FreeBSD 13.3 NetBSD 13.4 OpenBSD


14.0 Linux Distributions

14.1 Caldera OpenLinux

14.2 Debian GNU/Linux

Security information for Debian GNU/Linux, including links to security bulletins, patches and updates can be found at:

http://www.debian.org/security/
14.3 Mandrake Linux 14.4 RedHat Linux 14.5 Slackware Linux 14.6 SuSE Linux

Security information for SuSE Linux, including links to advisories, patches, and updates can be found at:

http://www.suse.com/us/support/security/index.html
14.7 TurboLinux

Security information for TurboLinux, including links to advisories, patches, and updates can be found at:

http://www.turbolinux.com/security/
14.8 Others

For other distributions of Linux, please refer to your vendor's website. A useful starting point for finding Linux distribution vendor's sites is:

http://www.linux.org/dist/index.html


15.0 Solaris

15.1 Patches

15.2 IP Forwarding and Source Routing

This is particularly relevant if you are using your Sun server as a bastion host or dual homed system.

  • DO disable IP forwarding and source routing. To do this you will need to edit the file /etc/rc2.d/S69.inet and set the options ip_forwarding and ip_ip_forward_src_routed to zero as illustrated below:
    • ndd -set /dev/ip ip_forwarding 0
    ndd -set /dev/ip ip_ip_forward_src_routed 0
    For the changes to take effect you will then need to reboot.
15.3 Stack Execution
  • DO Disable executable stacks by default to stop "stack smashing" attacks based on buffer overflow exploits. To do this, you will need to edit the file /etc/system and add the following lines:
    • set noexec_user_stack=1
    set noexec_user_stack_log=1
    Note that this may go against the SPARC and Intel ABIs and can be bypassed as required in programs with mprotect(2). For the changes to take effect you will then need to reboot.
15.4 NFS Port Monitoring
  • DO enable NFS port monitoring. To do this add the following line to /etc/system:
    • set nfs:nfs_portmon = 1 set nfssrv:nfs_portmon = 1
    See also 11.1.
15.5 Framebuffers /dev/fbs
  • Solaris versions 2.3 and above have a protection facility for framebuffers which is a superset of the functionality provided by /etc/fbtab in SunOS 4.1.x.
  • Under Solaris, /dev/fbs is a directory that contains links to the framebuffer devices. The /etc/logindevperm file contains information that is used by login(1) and ttymon(1M) to change the owner, group, and permissions of devices upon logging into or out of a console device. By default, this file contains lines for the keyboard, mouse, audio, and frame buffer devices. A sample /etc/logindevperm file:
    •     #
    # File:      /etc/logindevperm
    # 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/kbd:/dev/mouse
    /dev/console    0600        /dev/sound/*         # audio devices
    /dev/console    0600        /dev/fbs/*           # frame buffers
    Read the man page for logindevperm(4) for more information.
15.6 Security Bulletins 15.7 Sun BluePrints 15.8 Solaris Security Toolkit (JASS)
  • The Solaris Security Toolkit, informally known as the JumpStart Architecture and Security Scripts (JASS) toolkit, provides a flexible and extensible mechanism to minimise, harden, and secure Solaris Operating Environment systems. The primary goal behind the development of this toolkit is to simplify and automate the process of securing Solaris systems. Additional information and downloads are available from:
    • http://www.sun.com/security/jass/


16.0 IRIX

16.1 Patches

16.2 Default Account Security
  • DO review the state of accounts that are installed by default in the IRIX operating system. Several of these accounts are installed with widely-known or empty passwords. Refer to 5.2 for information about checking for password-less accounts. Some of the accounts that may be installed with empty passwords are:
    • guest
    • demos
    • EZsetup
    • OutOfBox
    • 4Dgifts
    • lp
    • root
    Other accounts may be added with known passwords. Here is a partial list of accounts known to have easily guessed passwords.
    • lp
    • field
    • tutor
    • tour
    • 4Dgifts
16.3 Security Advisories


17.0 Hewlett Packard UNIX (HP-UX)

17.1 Patches


18.0 Digital/Compaq Tru64 UNIX

18.1 Patches


19.0 AIX

19.1 Patches

19.2 Security Advisories


Section V. Appendixes

A. Useful security tools

There are many freely available tools that provide a good mechanism for checking the security of 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. It is also envisaged that you may look around on HTTP or FTP servers for other useful tools.

AusCERT and CERT/CC have not formally reviewed, evaluated or endorsed the tools described herein. The decision to use these tools is the responsibility of each user or organisation.

A.1 System Monitoring Tools


A.2 General Purpose Tools


A.3 Network Monitoring Tools


A.4 Network Access Control Tools


B. References

B.1 Bibliography


B.2 On-line references


C. List of commands by flavour

Notes:
  • The commands given here are examples only. Please consult the manual pages for your system if you are unsure of the consequence of any command.
  • BSD-style commands are marked as BSD commands, similarly for SVR4. Commands which are not labelled are expected to work for both.
  • Full directory paths and program options may vary for different flavours of UNIX. If in doubt, consult your vendor documentation.

C.1 Restart inetd

BSD commands 

     # /bin/ps -aux | /bin/grep -E "inetd|^USER" | /bin/grep -v grep
     # /bin/kill -HUP <inetd-PID>
SVR4 commands 
     # /bin/ps -ef | /bin/grep inetd | /bin/grep -v grep
     # /bin/kill -HUP <inetd-PID>
C.2 Ascertain which services are registered with the portmapper 
     # /usr/bin/rpcinfo -p
C.3 Rebuild alias maps 
     # /usr/bin/newaliases
If you run NIS (YP), you will then need to rebuild your maps to have the change take effect over all clients: 
     # (cd /var/yp; /usr/bin/make aliases)
C.4 Printing the umask value for each user

Use the following shell script: 

    #!/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
C.5 Set sendmail log level to 9

Include lines describing the log level (similar to the following two) in the options part of the general configuration information section of the sendmail configuration file: 

     # log level
     OL9
The log level syntax changed in sendmail 8.7 to: 
     # log level
     O LogLevel=9
C.6 Set syslog log level for mail messages

Include lines describing the logging required (similar to the following two) in the syslog.conf file: 

     mail.info                       /dev/console
     mail.info                       /var/adm/messages
For the change to take effect, you must then instruct syslog to reread the configuration file.

BSD commands
Get the current PID of syslog: 

     # /bin/ps -aux | /bin/grep syslogd | /bin/grep -v grep
Then tell syslog to reread its configuration file: 
     # /bin/kill -HUP <syslog-PID>
SVR4 commands
Get the current PID of syslog: 
     # /bin/ps -ef | /bin/grep syslogd | /bin/grep -v grep
Then tell syslog to reread its configuration file: 
     # /bin/kill -HUP <syslog-PID>
NOTE: In the logs, look for error messages like:
- mail to or from a single pipe ("|")
- mail to or from an obviously invalid user (e.g., bounce or blah)

C.7 (Rebuilding and) restarting sendmail(8)

To rebuild the frozen configuration file, firstly do: 

     # /usr/lib/sendmail -bz
NOTE: The above process does not apply to sendmail v8.x which does not support frozen configuration files.

To restart sendmail(8), you should kill *all* existing sendmail(8) processes by sending them a TERM signal using kill, then restart sendmail(8).

BSD commands
Get the pid of every running sendmail process: 

     # /bin/ps -aux | /bin/grep sendmail | /bin/grep -v grep
Kill every running sendmail process and restart sendmail: 
     # /bin/kill <pid>     #pid of every running sendmail process
     # /usr/lib/sendmail -bd -q1h
SVR4 commands
Get the pid of every running sendmail process: 
     # /bin/ps -ef | /bin/grep sendmail | /bin/grep -v grep
Kill every running sendmail process and restart sendmail: 
     # /bin/kill <pid>     #pid of every running sendmail process
     # /usr/lib/sendmail -bd -q1h
C.8 Test whether ftpd supports SITE EXEC

For normal users: 

     % ftp localhost 21
     USER username
     PASS password
     SITE EXEC
For anonymous users: 
     % ftp localhost 21
     USER ftp
     PASS username@domainname.au
     SITE EXEC
You should see the response "5nn error return" (e.g., "500 'SITE EXEC' command not understood"). If your ftp daemon has SITE EXEC enabled, make sure you have the most recent version of the daemon. Older versions of ftpd allow any user to gain shell access using the SITE EXEC command. Use QUIT to end the telnet session.

C.9 Ascertain whether anonymous FTP is enabled 

     % ftp localhost
     Connected to localhost
     220 hostname FTP server ready
     Name (localhost:username):  anonymous
     331 Guest login ok, send username as password
     Password:  user@domain.au
     230 Guest login ok, access restrictions apply.
     Remote system type is UNIX.
     Using binary mode to transfer files.
     ftp>
C.10 Ensure that '*' in the password field is correctly implemented
  • 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 '+', then your implementation is vulnerable. Contact the vendor for more information. If NIS users can log in ANC you cannot log in as the user '+', your implementation should not be vulnerable to this problem.
C.11 Find .exrc files 
    # /bin/find /  -name '.exrc' -exec /bin/cat {} \; -print
See also C.19.

C.12 Find .forward files 

    # /bin/find / -name '.forward' -exec /bin/cat {} \; -print
See also C.19.

C.13 Remove execute permission on /usr/lib/expreserve 

    # /bin/chmod 400 /usr/lib/expreserve
C.14 Set ownership and permissions for /tmp correctly 
     # /bin/chown root /tmp
     # /bin/chgrp 0 /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.

C.15 Find group and world writable files and directories 

     # /bin/find / -type f \( -perm -2 -o -perm -20 \) -exec ls -lg {} \;

     # /bin/find / -type d \( -perm -2 -o -perm -20 \) -exec ls -ldg {} \;
See also C.19.

C.16 Find files with the SUID or SGID bit enabled 

     # /bin/find / -type f \( -perm -004000 -o -perm -002000 \) \
       -exec ls -lg {} \;
See also C.19.

C.17 Find normal files in /dev 

     # /bin/find /dev -type f -exec ls -l {} \;
See also C.19.

C.18 Find block or character special files 

     # /bin/find / \( -type b -o -type c \) -print | grep -v '^/dev/'
See also C.19.

C.19 Avoid NFS mounted file systems when using /bin/find 

     # /bin/find / \( \! -fstype nfs -o -prune \) <expression>
As an example, <expression> could be 
     -type f \( -perm -004000 -o -perm -002000 \) -exec ls -lg {} \;

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 (mark off the sections as you go so that you remember what you have done so far).

Section I. The First Step

Section II. The Basic Operating System

Section III. Major Services

Section IV. Specific Operating Systems

E. Unix Security Checklist - The Essentials

Before You Begin

  • Don't attach the machine to an insecure network until all steps in this document have been addressed - preferably, perform all installations on the machine while it is completely isolated from any network. This may be facilitated by the use of patches stored on a CD or file server located within an isolated staging network.
  • Retrieve the latest patch list from your vendor and retrieve any recommended security patches not included with your system. Some patches may re-enable default configurations so it is important to go through this checklist after installing any new patches or packages. Information about where to obtain operating system patches or packages is available in the USC at Section IV. Patches for software applications not supplied by the operating system vendor should be obtained directly from the software vendor's web site.
  • Ensure that software patches and packages are only downloaded from a reliable source (i.e. direct from the vendor or a trusted mirror). This also applies to the operating system if it is publicly-available or open-source.
  • Verify the cryptographic digital signature of any signed downloaded files to ensure integrity. Don't use a file whose signature doesn't match its contents! Information about PGP/GnuPG is available in the USC at A.2.10 PGP/GnuPG.
  • Verify the md5 checksum, when possible, of any downloaded patches with a utility like md5(1) or md5sum(1). Information about obtaining an MD5 utility is available in the USC at A.2.6 MD5.
  • Subscribe to the vendor's security update mailing list for your particular operating system. Information for individual vendors is available in the USC at Section IV.
  • Subscribe to security advisory mailing lists from your local incident response team (if you have one). These mailing lists are typically low volume and provide invaluable information for system and security administrators. Information on subscribing to mailing lists is available in the USC at B.2.3 Mailing Lists.

Before the System is "Live"

Step One - Patches

  • Check for last-minute updates for your system that need to be performed subsequent to installation.
  • Install security patches retrieved before installation.
  • Check for the availability of a hardening script package for your particular system. Information on hardening scripts is available in the USC at Section IV - Specific Operating Systems.

Step Two - System Configuration

  • For more detailed information, refer to the USC at 2.0 Network Services
  • Disable any services which you do not absolutely require, by commenting out individual lines in /etc/inetd.conf with a "#" character, then reenabling essential services only. See 2.1 /etc/inetd.conf.
  • Unless "r" commands (i.e. rsh, rlogin) are required, remove or empty the file /etc/hosts.equiv.
  • If "r" commands are required, consider replacing them with secure alternatives, such as ssh. See A.2.13 ssh in the USC for more information.
  • Configure tcp_wrappers in /etc/inetd.conf to provide greater access and logging on enabled services if using the inetd daemon. See 2.2 tcp_wrapper. If using Xinetd, ensure that it is correctly configured in /etc/xinetd.conf. See 2.1 /etc/inetd.conf.
  • Edit /etc/hosts.allow to include this entry as the first uncommented line AFTER any configuration lines allowing connections for any specific services required:
    • ALL:ALL:deny
  • Edit /etc/hosts.deny to include this entry as the first uncommented line in the file:
    • ALL:ALL
  • Verify that you have disabled any unnecessary startup scripts under /etc, /etc/rc.d or /etc/init.d (or startup script directory for your system) and disabled any unneeded services from starting in these scripts.
  • Remove unneeded accounts/groups and disable interactive login access to system accounts.
  • After restarting the machine, check for running network services by issuing the command netstat -a. Ensure that only required services are running and listening for connections. This helps in preventing security compromises on possibly unknown and unpatches services.
  • On systems that implement the /etc/login.access file, consider modifying this file to disallow remote access to privileged accounts. An example to disallow non-local logins to privileged accounts (group wheel):
    • -:wheel:ALL EXCEPT LOCAL
    See also 2.10 /etc/login.access
  • Ensure that the terminal security file (for example, /etc/securetty or /etc/ttys) is configured to deny privileged (root) access from any external connections. See 2.15 Secure Terminals.
  • Check that the configuration files for PAM (/etc/pam.conf, /etc/pam.d/*) are secure. See 2.13 PAM (Pluggable Authentication Modules)
  • Ensure that the file /etc/ftpusers contains the names of all system accounts, as well as root. See 5.3 Special accounts
  • Prevent lpd and syslogd from listening for network connections if possible. Caution should be exercised to ensure outbound connections are still allowed if required for your system configuration. This may be accomplished with command-line arguments and/or tcp_wrappers - refer to your system's info or man pages.
  • Clear /etc/hosts.lpd if not required. If the host is a print server, ensure that only fully qualified domain names are specified ie. hostname.domainname. See 2.9 /etc/hosts.lpd

Step Three - Network Options

  • At a minimum, make use of any built-in firewalling utility that the operating system provides. For example: Linux has ipchains and iptables (See A.4.2.4 and A.4.2.5), BSD has ipfw (See A.4.2.1), Sun Solaris includes a "light" version of their SunScreen product with Solaris 8 (See A.4.2.6).
  • Ensure that the host is configured against IP spoofing and attacks with kernel and firewall rules. See 3.1 Packet Filtering and 3.2 Denial of Service Attacks.
  • If you wish to remotely administer your host, don't use unencrypted channels to do so (like telnet). Configure your host to use encrypted communications with a utility like SSH. See 3.3 Encryption and Strong Authentication

Step Four - System Monitoring and Additional Tools

  • Implement and maintain utilities for intrusion detection. At a minimum, implement a file integrity checker to monitor file-system changes. More information is available in the USC at 4.0 File System Security
  • Additional information on security and monitoring tools is available in the USC at Appendix A

Step Five - Final Updates

  • Ensure you implement a procedure to regularly parse and check system log outputs for unusual activity.
  • Make a backup of the completed system before putting it on a production network. This allows you a clear path to restore the system to an operational state. You should also implement a continuing backup policy.
  • Create and maintain a logbook for each system. This allows you to document any changes made to system configurations.
Revision History 
Oct 8, 2001 Initial Release
Questions or comments regarding this page? auscert@auscert.org.au
Disclaimer - Copyright © 2001, AusCERT
http://www.auscert.org.au/
This site contains files and links to support the free courses taught by James D. Keeline at the New Media Center / North City Center through the San Diego Community College District's Centers For Education and Technology.   A list of courses available at the center may be consulted.

The site will be updated throughout the semester both with new content and as a way to try out technologies used in several of the classes. This file modified 14-Jan-2007.