• Use netstat to find all listening network services.
• Also use the ps command to view which processes are running by default on startup.
• Preferably uninstall any services that are not required
• Otherwise disable them by editing or removing the relevant startup scripts

FreeBSD, AIX

• If none of the services in the inetd configuration are needed then disable inetd completely,
• Otherwise, disable all non-needed services in the configuration.

Solaris, HP-UX

Disable the portmap service completely unless it is necessary for the system to perform its role. Usually a machine that does not use NFS or NIS/NIS+ does not need portmap, however there are some other software packages that may need it such as FAM (on IRIX or Linux), mcserv, dracd and several Solaris specific services.

Disable any non-required services that are registered with the portmapper on start up.

To check for registered RPC services, use the command: /usr/bin/rpcinfo -p

On systems that track software package dependencies, that gives an even more convenient way to identify any packages that depend on the portmapper.

See also section F.7 for advice on configuring RPC.

• Remove or disable the "r" commands
  This includes rlogind, rshd, rcmd, rexecd, rbootd, rquotad, rstatd, rusersd, rwalld and rexd. These services are inadequately authenticated. It is better to remove these and use SSH and scp instead.

  Note the special case of rsync, which is not one of the traditional "r" commands. rsync is useful and while by default it provides authentication of connections and transferred data, its native authentication is not strong so where rsync is required it is recommended to run it over SSH.

• Remove or disable fingerd
  Remove or disable fingerd if present. Apart from the possibility of a software vulnerability, fingerd allows an attacker to enumerate usernames on the system and to determine the timing and frequency of system administrator logins.

• Remove or disable tftpd
  Do not use tftpd (trivial file transfer protocol) unless unavoidable.

  If tftpd is required for the computer's role, 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, unless this is required for the system's role.

  TFTP is not authenticated, so to protect devices using TFTP, it is highly recommended only to allow it over a trusted network, such as a trusted management network for configuring network devices and not over the main LAN.

• Disable SNMP daemon
  If present by default, disable any SNMP daemon unless this is really required for the role of the computer.

Solaris, AIX

Consider having a paper User Registration Form for each user on the system. This form includes a section that the user signs, stating that they have read your security policy or acceptable use policy and what the consequences are if they contravene the policy.

Consider requiring that users physically identify themselves before granting any requests regarding accounts (e.g., before creating a user account or resetting passwords).

Have a documented process for when staff leave, to ensure that dormant accounts can not occur.

Have a process for staff transfers and role changes, to ensure that appropriate changes are made to the user's authorisation and access rights on the system.

Note when disabling accounts:
In general, besides setting the accounts to disabled or deleting them entirely it is also necessary to:

• search for and remove all files owned by that UID (in case the UID gets reallocated to a new user);
• check that the accounts have no cron or at jobs;
• use ps to check for and kill any processes running under that UID.

Ensure that there are no shared accounts other than root. (i.e. more than one person should not know the password to an account)

Disable any guest accounts (accounts that can be used without any authentication) and do not create guest accounts. (Note: Even now, some systems come preconfigured with guest accounts.)

Disable any default vendor accounts shipped with the operating system that can be logged in to. This may need to be rechecked after an upgrade.
Note that default accounts may sometimes be added during installation of third-party software applications, so these should be checked for after installation.

Disable accounts with no password which execute a single command, for example sync.

Ensure non-functional login shells (such as /bin/false or /sbin/nologin) are assigned to system accounts such as bin and daemon. There is no need to remove the default system accounts but it is important that they can not be logged in to.

IRIX

E.2.3.1 Root password

E.2.3.2 No direct root logins

Check that the current directory "." is not in the PATH. Note that an empty string is interpreted to mean the same as "." so also make sure the PATH does not contain any empty strings. For example, the following PATH is insecure:
/sbin:/bin:/usr/sbin::/usr/bin This PATH advice is especially important for the root account.

Ensure that directories writable by other users are not specified before system directories in a user's PATH, and check that no files in the PATH of a user can be modified by other users.

Do specify absolute path names when writing scripts and cron jobs.
(e.g. /bin/su, /bin/find, /bin/passwd.) This is to ensure that even if scripts get run in an environment with a different PATH, they can not be tricked into executing a malicious program. One way to address this is explicitly to set the PATH variable at the start of the script, giving it a minimal list of directories.

Note: when using su, it is good practice to use the dash parameter, i.e. "/bin/su -" to reset the environment. While this does not give any significant protection if the user account were compromised, it does prevent bad environment variables from being unintentionally inherited by the privileged shell.

Consider enforcing disk usage quotas on user accounts, by enabling quota support for individual users or by using the resource-limits PAM module where available.

Consider using the resource limiting features of a user's logon shell to restrict the maximum memory/processes/CPU time used. For sh style shells (sh, bash, ksh) use the ulimit command. For csh style shells (csh, tcsh) use the limit command.

Evaluate the other facilities provided by your operating system to put conditions on user logon access, limit remote access, control user resource usage and enforce other policies on user sessions such as logging/accounting. These features vary significantly between different UNIX variants, so check the documentation for your system.

Consider configuring user login sessions to log out automatically after a certain period of inactivity, in particular for the root user. To do this, set the appropriate variable in your shell's startup files.
For csh: set -r autologout=15   (15 minutes)
For bash: typeset -r TMOUT=900  (15 minutes = 900 seconds)

HP-UX, FreeBSD, AIX

E.3.1.1 Evaluate two-factor authentication

E.3.1.2 Shadow passwords

E.3.1.3 Ensure all accounts have passwords or are disabled.

E.3.1.4 Password Policy

E.3.1.5 Enforce password complexity

E.3.1.6 Password ageing and password history

Evaluate the use of one-time passwords for remote connections. In certain situations this mechanism can be more secure than public key authentication or reusable passwords.

For example, a malicious trojan on a client machine can easily capture passwords, secret keys and their passphrases to obtain ongoing remote access to an account. In contrast, where one-time passwords are used a trojan would have to hijack a legitimate session, and the attacker will then have to go to more trouble to maintain ongoing access to the compromised account.

Notes if using one-time passwords:

• Generate the master key or password lists while logged on at the console of a trustworthy machine.
• Ensure users are aware they must not store password lists on or near their computer.
• Minimise the number of one-time passwords printed and given to each user at any one time.

OPIE is a commonly used free implementation, available at http://inner.net/opie
PAM modules implementing one-time passwords are also available.

On many UNIX systems, PAM is the main framework for authentication, and will be operational by default.
PAM is provided by default on Linux, FreeBSD, Solaris, HP-UX and AIX.

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 6.x system:

% ldd /usr/bin/login
/usr/bin/login:
libutil.so.5 => /lib/libutil.so.5 (0x28077000)
libpam.so.3 => /usr/lib/libpam.so.3 (0x28083000)
libc.so.6 => /lib/libc.so.6 (0x2808a000)

Note the libpam.so.3, this shows the program is linked with PAM.

Depending on the system, PAM may be configured with the file /etc/pam.conf or with individual configuration files in /etc/pam.d/. PAM is very flexible and it is possible to require more than one authentication method.

Check that PAM is configured to deny access by default - a misconfigured service may result in an attempt to authenticate using a less secure mechanism, or even no authentication at all.
If contemplating any change to the PAM configuration be careful that the effect is understood, so as not to leave the system in an insecure state.

Enforce your password policy using PAM, as discussed in E.3.1

Consider enforcing user resource limits with PAM: This may be done using the pam_limits.so module with configuration in /etc/limits.conf where available.

Linux, Solaris, OpenBSD

Do not use NIS. It is inherently insecure on an untrusted network. It is for this reason and others that NIS was superceded by the more secure NIS+.

Use LDAP instead to achieve the same goal of centralized directory services. If only authentication is required, then Kerberos can be considered as another alternative.

NIS+ is much more secure than NIS, but is only fully implemented on a few UNIX variants. Sun has announced End of Feature status for NIS+, and suggests that customers migrate to LDAP.

LDAP is a protocol for accessing online directory services. In the special case where LDAP is used to distribute authentication data the security of the LDAP server and its configuration become critical.

For authentication to the LDAP server itself consider using client-side certificates or Kerberos. Alternatively, as a bare minimum use SASL DIGEST-MD5 authentication.

Verify that communication with the LDAP server is protected by TLS, so that data is not transmitted in the clear.

For the UNIX system's authentication data, if supported by the LDAP server use SHA1 (preferably) or MD5 password hashes rather than the weaker UNIX crypt hashes or plaintext passwords.

Ensure that LDAP access controls are correct for all attributes that contain authentication credentials or other sensitive data. In particular, password hashes should not be readable by other users, whether authenticated or not.

E.4.1.1 Permissions for key files and directories

E.4.1.2 Protect programs used by root

E.4.1.3 Protect directories written to by root

E.4.1.4 Group membership

E.4.1.5 umask for users

E.4.1.6 Permissions for user home directories

Consider using file attributes if your operating system supports them.

• system binaries and key configuration files can be made immutable,
• log files can be made append-only.

Linux, FreeBSD

Consider using Role Based Access Control (RBAC) to split the role of root, if available for your system. (See OS specific footnotes)

This reduces the risk of a frequently used all-powerful root account that can control the whole machine if compromised.

In an environment with multiple system administrators, RBAC can also give the ability to split administration powers among several people if desired.

Linux, Solaris, HP-UX, AIX

The sudo utility is available for practically all UNIX variants and can help minimise the need to use the root account.

For systems administered by more than one person, sudo can also be helpful to split the power of root to some extent if full Role Based Access Control is not available.

sudo allows users or groups of users to execute specific authorized commands as another user, such as the root user. It requires unprivileged users to enter their own user password in order to execute privileged commands. This enables administrative tasks to be distributed among different users, while limiting the distribution of the root password.

Also, sudo can be configured to log each access (or attempted access) to commands by users, enabling some auditing of users' privileged actions.

Exercise caution when configuring sudo. Even if a user is only granted access to execute one specific program with root privileges, if that program can be made to spawn a shell or run other commands (e.g. many text editors can do this), then the user can execute arbitrary commands as root using their sudo access, and this usage may not be logged. It can be difficult to determine which programs may grant unintended access or privilege escalation. This is why permitting an extremely limited set of commands is preferable.

Mandatory access control allows all accesses to data on the system to be controlled by a site policy rather than user discretion. Depending on which policy model is used, this can be aimed at preventing an attacker from leaking confidential information from the system, or at preventing an attacker from making unauthorised changes, even after subverting software on the system.

Mandatory access control implementations usually also provide more reliable and fine-grained auditing of access events.

• Some operating systems offer mandatory access control and data labelling as optional features.
• Other operating systems instead have a separate "trusted" version which implements these features.

Consider the benefits and costs of installing and enabling these trusted operating system features if available. Note that some of these controls may impact software compatibility and usability, so enforcing these will not be useful to all organisations.

For systems where mandatory access control is enabled by default, verify that the current configuration is the appropriate one for your situation.

Linux

Ensure that the permissions for root's crontab are set to 600 and that the owner is set to root.

Consider not allowing regular users to add cron jobs.

Choosing to use separate partitions as recommended in section B.3 now allows flexibility for mount options.

Configure the mount options nosuid, nodev and noexec for /var and /tmp in your /etc/fstab or vfstab file.

For user home partitions, use nosuid and nodev and consider using noexec.

Mount external filesystems with the nosuid and nodev options. This includes both removable media such as CDs and USB drives as well as network filesystems. Consider also using the noexec and read-only options for these filesystems where practical.

AIX

Install and turn on non-executable stack protection if available for your operating system. This makes buffer overflow bugs more difficult for attackers to exploit.

Some implementations also provide non-execute protection for other memory regions such as the heap, or provide broader protection ensuring that memory regions are not both writable and executable.

Solaris, HP-UX, AIX

Ensure that any startup scripts use a umask of 022 or better. This should already be the case for vendor-supplied startup scripts.

~/.netrc is a file used by ftp and by rexec to automate file transfers and remote execution.

Do not use .netrc files. Instead use SSH and scp, or rsync over SSH if automated file transfers or execution are required.

Ensure that services run under unprivileged accounts where possible.

Many services do this automatically, however some will run as root by default and will need to be configured manually.

chroot jails are the most common confinement mechanism, available on almost all UNIX and Linux systems. The chroot(2) system call is used to confine the daemon to a small subtree of the real filesystem and it appears to that process to be the root directory. Any libraries that the daemon requires will also need to be put inside the chroot directory structure.

The software and files deployed within the chroot environment can then be minimized to those only needed by that specific service.

Many daemons now have a built-in configuration option to chroot themselves to a specified directory after starting, which is more convenient than manually using the chroot command in a startup script.

Be aware that chroot is not foolproof - if an attacker is able to gain root privileges within the chroot jail, then there are potentially several ways they may break out.

Several operating systems provide their own more advanced mechanisms for confining processes. See the OS specific footnotes for details on Solaris Containers and privileges, FreeBSD jails and SE Linux Type Enforcement.

Linux, Solaris, FreeBSD

Instead of allowing services to listen on a wildcard network interface, configure them to listen on only one specific IP address where possible.

If the service is only required for use on the local host, then it should listen only on the loopback interface where possible, with address 127.0.0.1

If this UNIX or Linux system provides services that involve sensitive data, but the built-in encryption or authentication of the software is inadequate, then consider using stunnel to secure these services.

stunnel is a free tool that can be used to add TLS (or SSL) authentication and encryption capabilities to any existing client and server that uses TCP. For example, it can be used to secure access to POP3, or to secure an existing in-house application that communicates using TCP.

If required, client access to the wrapped service can also be authenticated using client-side certificates.

stunnel packages may be available from the OS vendor, or otherwise by downloading source from http://www.stunnel.org/

Filter NFS traffic at the router, blocking TCP/UDP on port 111 and TCP/UDP on port 2049. This will help prevent machines not on the local subnet from accessing file systems exported by this host.

Be aware of the trust relationships implied by the current NFS configuration, to determine what impact an attacker may have if they compromised or spoofed the identity of either the server or the client. This is particularly relevant if NFS sessions are only being authenticated by IP address.

Configure NFS to use TCP rather than UDP. This is supported by all NFS 3 implementations.

Consider tunnelling NFS over SSH or stunnel to provide authentication and encryption.

Configure statd, mountd and lockd to bind to a fixed port number if possible so that configuring a host firewall is more straightforward.

Confirm NFS is configured to accept mount requests only from ports less than 1024. This is configured by default on some NFS implementations, and may be set by the 'secure' option on exports in others.

Verify that you run a portmapper or rpcbind that does not forward mount requests from clients. With older portmappers a malicious remote NFS client could ask the host's portmapper daemon to forward requests to the mount daemon, which would then process the request as if it came directly from the local host. If a file system is exported to the local machine this then gives the remote client unauthorised access to the file system.

Configure /etc/exports or /etc/dfs/dfstab to export the minimum set of file systems that need to be exported.

Export file systems read-only (-ro) whenever possible. See the manual page for exports or dfstab for more information.

Check that any important exported files that clients should not be able to modify are owned by root, and not owned by bin or any other account.

Ensure that file systems are exported with the root_squash or -maproot option, to map root to an unprivileged user. Without this, an attacker controlling root on one of the clients will also be able to access the server as root.

Confirm that no file systems are exported unintentionally to the world. Invoke showmount -e to verify what is currently being exported. If required, add -access=192.168.50.3 option or equivalent in /etc/exports to restrict access by IP. If you must specify hostnames instead of IPs, then export to fully qualified domain names only (i.e. use 'machinename.domainname.com' rather than abbreviating it to 'machinename').

Solaris

The Samba service provides filesystem and printer shares using the CIFS protocol that is also used in Microsoft Windows.

If users in your environment authenticate to Active Directory for other services, then consider pointing to the same AD server for Samba authentication, setting
security = ADS
See the Samba HOWTO for further details on implementing this: HOWTO

Otherwise, configure your shares for user-level security using the
security = user
parameter. In current versions of Samba this is the default.

Require at least NTLM2 authentication as a bare minimum, with
lanman auth = no
ntlm auth = no
restrict anonymous = 2
guest ok = no

Consider using stronger client authentication methods. Samba supports better authentication through Kerberos or Pluggable Authentication Modules (PAM).

Restrict access to the Samba service with the parameters:
hosts allow =
hosts deny =

Protect the Samba services with firewall rules to ensure they can not be accessed from hosts outside the local network. Samba uses ports 137 and 138 (UDP) and ports 139 and 445 (TCP).

On most UNIX and Linux systems the default MTA will be Sendmail. This section provides configuration recommendations specifically for Sendmail, though the same configuration goals can be applied to other MTAs.

If this computer is not a mail server, then:

• Disable SMTP connections from other computers by adding
  Addr=127.0.0.1 to each DAEMON_OPTIONS macro that is in your config.
  For example:
  DAEMON_OPTIONS(`Name=IPv4, Family=inet, Addr=127.0.0.1')
  DAEMON_OPTIONS(`Name=IPv6, Family=inet6, Addr=::1')
  FEATURE(`no_default_msa')
  DAEMON_OPTIONS(`Name=MSA, Port=587, Address=127.0.0.1')


• Consider disabling the daemon mode altogether by removing the -bd option from the startup script. This will still allow most local Mail User Agents to invoke the sendmail binary to send mail. In this case, do use a -q30m option to ensure queued outbound messages are still processed.

If this IS a mail server, then:

• Ensure familiarity with Sendmail access control and anti-spam control features. See http://www.sendmail.org/m4/anti_spam.html for an overview.


• If it is really necessary to relay mail from roaming users outside your local address range, then configure Sendmail to require SMTP AUTH for these connections.

In both cases:

• If you do not require emails to be piped to other programs for processing then disable prog mailer functionality with
  MODIFY_MAILER_FLAGS(`LOCAL', `-|')


• If you do require piping email to programs, use smrsh to limit the programs that can be executed to only those programs linked in the smrsh configuration directory. This can be turned on with
  FEATURE(`smrsh', `/usr/libexec/smrsh')
  (The location of the smrsh binary may vary on different systems.)


• Consider setting sendmail logging to a minimum log level of 10.
  This will help detect attempted exploitation of sendmail vulnerabilities as well as logging each connection and the username used in each SMTP AUTH. To do this use:
  define (`confLOG_LEVEL', `10')


• /etc/mail/aliases
  check that any programs executed from this file are owned by root, have permissions 755 and are stored in the smrsh configuration directory, e.g. /etc/smrsh

Remember that it is necessary to regenerate sendmail.cf and/or *.db files and then restart sendmail for any changes to take effect.

Sendmail is the most fully featured MTA software. On the other hand it is also a large and complex program. The complexity leaves more scope for security vulnerabilities through misconfiguration or software flaws.

If this computer accepts email from other systems, and Sendmail's extra functionality is not required, then consider the benefits and costs of using an alternative to Sendmail with a more simple and privilege-separated design.

qmail is a replacement for sendmail designed with security and correctness as a primary goal, but implementing a more limited set of features. It is available at: http://cr.yp.to/qmail.html

Postfix is another Mail Transport Agent that has been designed to avoid common security problems. Postfix's homepage is: http://www.postfix.org

Consider configuring workstations to disable listening for incoming X sessions over the network. On many operating systems this is done by using the -nolisten tcp option in the script that starts the X server. Alternatively, on some systems this may be set in the configuration file for xdm, gdm or kdm.

Use the X magic cookie authentication mechanism MIT-MAGIC-COOKIE-1 or better. With logins under the control of xdm, authentication can be enabled for all displays by editing the xdm-config file to include the line DisplayManager*authorize: true
This may or may not be the default on your system.

If granting access to the display from another machine, use the xauth command in preference to the xhost command.

Do not use host based access control. 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 X.

If X is used across the network, then encrypt and authenticate all X network traffic. Using the X Forwarding feature of SSH is the most straightforward way to achieve this. (See section F.4)

Note that in most X servers there is little to protect one X client program from another. This allows any X client program to capture keystrokes and screenshots of other X client programs and also to inject input to other programs.

Therefore if some X applications are less trusted than others, consider the risk of this for your environment and separate the use of applications appropriately.
For example, consider not typing the root password while in X, instead using the console (or a separate logical X display).

Secure X servers included with B level trusted operating systems such as Trusted Solaris are designed to eliminate this issue.

If the system is configured to provide a graphical login screen, the display manager (such as xdm, gdm or kdm) is the program that does this.

xdm may bypass 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.

Desktop environments that are available for UNIX may provide different X display managers (e.g. gdm from Gnome and kdm from KDE).

For most UNIX systems, BIND will be the default domain name server software provided.

Turn off dynamic updates unless they are really required, for example to support Active Directory.

Consider applying the security practices detailed in the following documents:

Secure BIND Template By Rob Thomas http://www.cymru.com/Documents/secure-bind-template.html

Securing an Internet Name Server By Cricket Liu http://www.linuxsecurity.com/resource_files/server_security/securing_an_internet_name_server.pdf

Chroot-BIND HOWTO By Scott Wunsch http://www.losurs.org/docs/howto/Chroot-BIND.html for BIND version 9.x or http://www.losurs.org/docs/howto/Chroot-BIND8.html for BIND version 8.x.

BIND is the DNS server software that provides the most comprehensive set of DNS features. On the other hand it is also a large and complex piece of software. The complexity leaves more scope for security vulnerabilities through misconfiguration or software flaws.

If BIND's extra functionality is not required, then consider the benefits and costs of using an alternative with a more simple design such as djbdns.

djbdns is a set of DNS server software designed with security as a primary goal, but implementing a more limited set of features. It provides separate programs for the DNS cache and DNS server roles. djbdns is available at: http://cr.yp.to/djbdns.html

Apache is the most common web server on Unix systems. If you are using Apache, implement the security recommendations outlined in http://httpd.apache.org/docs/misc/security_tips.html

Consider running the web server in a chroot jail (see section F.2.1). Some systems supply the web server in this configuration by default. Example steps for chrooting Apache on Linux and Solaris can be found at http://penguin.triumf.ca/chroot.html. A simpler way to chroot Apache is now provided by the mod_security's SecChrootDir option, as described here.

Consider configuring the web server to disallow automatic directory listing if an index.html file is not present in the directory.

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.

Consider running the web server on a dedicated computer that is not relied on for other services.

This section applies to dynamic web content including all web applications, CGI and server-side scripting languages such as PHP, Perl or Python.

If using ready-made web applications such as content management systems, portals or discussion forums, be careful in choosing high quality software and be especially vigilant in keeping these up to date. Known vulnerabilities in PHP web applications are some of the most common ways that UNIX and Linux web servers are compromised.

Ensure that any default or example scripts included with an application of framework are removed if not needed.

Consider monitoring changes to scripts and web applications using a file integrity checking program such as Tripwire. (See section G.5.1)

For any web site developed in-house or by contract, ensure all developers doing web programming understand the specific issues of secure web programming. In particular the OWASP Guide to Building Secure Web Applications, available at http://www.owasp.org/index.php/OWASP_Guide_Project is indispensible.

The most common vulnerabilities exploited are listed in the OWASP Top Ten at http://www.owasp.org/index.php/OWASP_Top_Ten_Project

Set minimal filesystem permissions, especially on the directories containing scripts. The permissions required by different applications and frameworks vary. Preferably the unprivileged account running the httpd should not have permission to write to the script area.

Use TLS (Transport Layer Security) or its predecessor SSL (Secure Socket Layer) to provide authentication and encryption where appropriate.

Confirm that sensitive form data is not submitted unencrypted.

Confirm that the private key file can not be read by the unprivileged account that the httpd process runs as (usually www or nobody).

SSL version 2.0 is insecure and should be disallowed.

For logon pages, it is recommended to use SSL not only for the form submission, but also for the logon page itself, as this makes it easier to instruct users not to submit their password to an unauthenticated site.

If serving static pages is all that is required, consider running more cut-down and minimal web server software.

publicfile is a simple, read-only HTTP and FTP server designed with security as a primary goal. It is available from: http://cr.yp.to/publicfile.html

Ensure that your FTP server does not have the SITE EXEC command, or that this command is disabled correctly.
Test with:

If it is correctly disabled, you should receive an error response like
500 'SITE EXEC' command not understood
Then type QUIT to end the session.

Ensure that you have set up the file /etc/ftpusers. This file 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.

Use chroot to confine the ftp daemon. (See section F.1.2)

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 there are no shells, interpreters or system commands in ~ftp/bin, ~ftp/usr/bin, ~ftp/sbin or similar directories. 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:
where /home/ftp is the anonymous FTP area.

Set the permissions of the FTP home directory ~ftp/ to 555 (read nowrite execute), and check that this directory is owned by root (ftp).

Make sure 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.:

The password file is used only to provide uid to username mapping for ls listings within ftp.

Make sure 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.

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 directories ~ftp/etc and ~ftp/bin are owned by root with permissions 111.

Ensure that any files in ~ftp/bin are owned by root with permissions 111.

Ensure that files in ~ftp/etc are owned by root with permissions 444.

Ensure that there is a mail alias for ftp to avoid mail bounces.

Ensure the mail spool file for the ftp daemon account is owned by root with permissions 400. (Depending on the system this will be in a location such as /var/mail/ftp or /usr/spool/mail/ftp )

Never mount disks from other machines to the ~ftp hierarchy unless they are mounted read-only.

HP-UX

To ascertain whether you are running anonymous FTP, try to connect to the localhost with username "anonymous", and give a well formed email address as the password.

To disable anonymous FTP, move or delete all files in ~ftp/ and then remove the "ftp" user account from the system.

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 intend to allow anonymous users to upload files, read the section below about upload directories.

Limit the number of anonymous connections allowed, and also the number of times a single IP can be logged in at once. Anonymous users should only be allowed to have one session active at a time - otherwise you make a DoS attack easier.

Ensure that the anonymous ftp user account cannot create files or directories in ANY directory unless required.

Verify that the anonymous ftp user account can only read information in public areas.

Preferably, check that you do not have any writable directories as this is safest. If you must have writable directories to allow upload, we recommend that you limit the number to one, for instance an 'upload' directory.

Ensure that the writable directory is not also readable. Directories that are both writable and readable are likely to be misused.

Check that any writable directories are owned by root and have permissions 1733. (note sticky bit set)

Put writable directories on a separate partition if possible. This will help to prevent denial of service through disk exhaustion.

Logs and audit trails are only of limited use unless people are actively monitoring them. Decide on a specific time period within which people will monitor the logs.

Consider automatically emailing logs or log extracts to the internal email addresses of the relevant people. Check that the sensitivity of information contained in the logs is appropriate to distribute this way.

Automated tools cannot replace human judgement, but they make the process of people monitoring the logs much more efficient by providing different filtered and processed views on the logs, and alerting automatically based on defined patterns.

Automating to some degree is highly recommended as otherwise it is unlikely that the human component of the log monitoring task will actually be done.

Two example programs are swatch and logsentry. Further information on log monitoring and available tools is available at http://loganalysis.org

Do actively monitor the running status of server processes on your machines - tools are available that make it possible to do this remotely. Some examples of these are:

• Argus system monitoring software http://argus.tcp4me.com/
• Big Brother http://www.bb4.org
• Nagios http://www.nagios.org/

For some commercial UNIX variants, specialized server monitoring tools are also available from the vendor.

Consider turning on process accounting, if available for your system. Process accounting allows the kernel to keep records of each command run, the user and the time, exit codes, as well as what amount of system resources (CPU, memory, disk I/O) were used.

Regularly monitor process accounting log files for activity of interest.

Check that process accounting log files are owned by root and have permissions 600.

lsof is a tool for monitoring open system files that can be useful in checking current activity on the system. lsof may be included with your operating system, and is also available from the source at ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/

Consider using a file integrity checker for intrusion detection, providing monitoring for unexpected filesystem changes.

When using a file integrity checker:

• Have a system administration procedure in place to check and update the database at least weekly to reflect legitimate changes. Without this any real security alerts may be lost amidst the noise of legitimate changed files.


• Consider storing the integrity checker binary, its database and configuration file on hardware write-protected media, and using a binary that is statically linked.


• Consider running the integrity checker from a bootable CD. This is the most tamper-proof option, but is not appropriate in many cases because it involves downtime while the check is run.

An example file integrity checker is the open source Tripwire, available from http://sourceforge.net/projects/tripwire/

AIX, Solaris

Antivirus products that run on UNIX systems are often aimed at detecting Windows malware that passes through a UNIX email or file server. However several companies also produce antivirus software specifically targeting known UNIX malware.

In particular where UNIX is deployed on desktop workstations, consider the use of antivirus / malware detection software to detect content-based attacks on the clients.

Depending on the operating system, free tools may also be available to check for known trojaned binaries or malicious kernel modules that may be installed by an attacker after compromising the system. The chkrootkit tools available from www.chkrootkit.org are able to detect some of the most common rootkits. Chkrootkit runs on Linux, *BSD, Solaris, HP-UX and Mac OS X.

Consider deploying a signature matching network intrusion detection system, aimed at detecting attempted and successful network attacks.

Snort is one open source network IDS which performs real-time traffic analysis and packet logging. It can use protocol analysis and content searching/matching to detect a variety of known attacks, based on configured signatures. Snort is available at: http://www.snort.org/

Do not run a signature matching network IDS tool or protocol analyser in promiscuous mode on the server itself. Instead use a separate computer/device. This protects your server and network from vulnerabilities in the IDS software itself.

Consider connecting the IDS to the network to be monitored via a read-only network tap or a spanning port on the switch.

Consider using an ARP monitoring tool to detect ARP spoofing attacks within your LAN.
One such tool is arpwatch, available at http://www-nrg.ee.lbl.gov/

Most UNIX operating sytems provide a packet filtering host firewall system, either as part of the base install, or as an option you can install.

On a minority of systems, a reasonable host firewall is already configured by default on newly installed systems, though this can usually be tightened further.

Linux, Solaris, HP-UX, FreeBSD, OpenBSD, AIX, IRIX

Do not assume that there is an internal network whose computers are trusted.
The point of the host firewall is to ensure that when one of the other computers on your internal network is compromised, and the attacker is then able to launch attacks directly from the local LAN, they will still be unable to contact all of the services on this computer. Therefore, design the host firewall by assuming that the internal computers are already compromised, and may seek to attack this system.

Restrict incoming network connections to the minimum set of TCP/UDP port numbers required for this computer's role, as determined in section A.6

Consider also restricting outgoing connetions to the minimum set of destination port numbers required for the computer's role. If this computer is compromised, this can make it more difficult for (the less sophisticated) malicious software to connect back out to an attacker to receive instructions.

Where a service on this computer only needs to communicate with specific hosts, consider making this explicit in the firewall rules, restricting that port number to only communicate with the specified hosts.

Ensure that the following ports can NOT be accessed over the network:

• TCP port 25 (SMTP, unless this host is a mail server),
• UDP and TCP port 111 (portmap),
• TCP port 587 (mail submission agent)
• TCP ports 6000-6010 (the X Window System),
• and any other services that are for use on the local computer only.

If the IPv6 stack on this computer has not been disabled, then verify that the firewall rules correctly handle IPv6 packets coming from the local LAN. Some firewall configurations ignore IPv6. Even on an IPv4 network this may give unintended access if the attacker already controls another point on the LAN.

Packet filtering can be difficult to implement correctly. For more information on firewalls and packet filtering, the following references may be of use:

Internet Firewalls FAQ
http://www.interhack.net/pubs/fwfaq/

Building Internet Firewalls, Second Edition

For computers with more than one network interface, be aware of the "weak end system" model used by most UNIX operating systems (RFC1122). This means that on hosts with more than one network interface, even if a service only binds to the IP address of one interface, this will not protect it from packets that are received on a different interface but addressed to that IP.

This is particularly important where second network cards are used to provide a separate management network.

To address this, either:

1. Turn off weak ES behaviour (see OS specific footnotes) or,
2. add explicit host firewall rules to block packets coming into one interface but addressed to the IP address of another interface.

Solaris, FreeBSD

Have a documented response process in place before any incident occurs.

If it is decided that police investigation is desirable, it is recommended to contact law enforcement at the earliest possible stage in the process, and to coordinate any actions with them first.

One suggested response procedure is described in the document Steps for Recovering from a UNIX or NT System Compromise Your procedure should be tailored to meet your specific requirements.

As part of your process, record in writing any steps taken in investigating an incident.

It is usually important to determine how the attacker broke in, since if you clean and restore the system without knowing this then the attacker may simply re-enter the system via the same vulnerability.

Any investigation is best done on a forensically sound image of the affected hard disk, rather than on the original disk. If law enforcement involvement is desired, then it is recommended to leave the disk imaging to law enforcement, and to avoid altering the system in any way before this is done.

In other cases, consider having the capability to make a forensically sound image of an affected hard disk, using dd or similar tools on a second, clean system. This will require having spare hard disks available ahead of time to create the image.

It is beyond the scope of this document to detail sound handling of the digital evidence. Some of the issues involved are mentioned in the document Collecting Electronic Evidence After a System Compromise

Autopsy is one free forensic filesystem analysis tool for UNIX systems. It may be used to examine images of storage devices from a compromised system, and generate a timeline of recent file access.

If using this tool, run it only on an image copy of the original hard disk, on a non-networked machine.

Autopsy is available at http://www.sleuthkit.org/autopsy/desc.php

Solaris

For some incidents it may be useful to apply known-malware detection as described in section G.5.2 as a quick way to confirm that the system was compromised. Of course, a failure to detect known malware does not indicate that the system was clean.

Only administer the computer at the console, or else over the network using tools that are properly encrypted and authenticated, such as SSH or a web interface protected by SSL. Do not assume that a corporate internal network is secure.

Ensure workstations used to administer a UNIX or Linux server are as least as secure as the server itself. Otherwise keystroke logging can steal your SSH private key passphrase and all administrative passwords. Public key cryptography will not protect against this.

Consider allocating system administrators two separate workstations, one for administering the systems, and the other for general work such as email, web browsing and document creation.

Periodically re-check the system against this checklist, and ensure that the system is still in conformance with your security policy.

In particular, re-check at this time that the software installed is only the minimal set decided on.

Regularly audit the 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.

At this stage also audit the password files for unauthorised additions or inconsistencies.

Where appropriate, consider regularly applying a password cracking program such as "John the Ripper" to check for weak passwords.

This is especially worth considering for a multi-user system which does not have any mechanism for enforcing difficult passwords. John the Ripper is available from: http://www.openwall.com/john/

Use network port scanning and vulnerability scanning tools from a separate computer to check periodically that open network ports are as expected, and that no well known vulnerabilities are detected.

nmap is a port scanning tool available from: http://www.insecure.org/nmap/

Nessus is a vulnerability scanning tool available from: http://www.nessus.org

OpenVAS is a vulnerability scanning tool available from: http://www.openvas.org