AusCERT - AusCERT UNIX and Linux Security Checklist v3

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

AusCERT UNIX and Linux Security Checklist v3.0 Date: 13 February 2007 Original URL: http://www.auscert.org.au/render.html?cid=1937&it=5816

UNIX and Linux Security Checklist v3.0 AusCERT public release 2007-07-25

Introduction This document has been published by the Australian Computer Emergency Response Team (AusCERT). It provides a checklist of steps to improve the security of UNIX and Linux systems. We encourage system administrators to review all sections of this document and if appropriate modify their systems to fix potential weaknesses. The checklist is structured to follow the lifecycle of a system, from planning and installation to recovery and maintenance. Sections A to G of the checklist are best applied to a system before it is connected to the network for the first time. In addition, the checklist can be reapplied on a regular basis, to audit conformance. No two organisations are the same, so in applying the checklist consideration should be given to the appropriateness of each action to your particular situation. Rather than enforcing a single configuration, this checklist will identify the specific choices and possible security controls that should be considered at each stage. Operating system specific footnotes throughout the document offer some additional information to help with applying these steps on specific UNIX and Linux variants. The most current version of this document is available at http://www.auscert.org.au/1935 We will continue to update this checklist. Any comments should be directed via email to [email protected]. Before using this document, please ensure you have the latest version. New versions of this checklist will be available via the URL listed above and should be checked for periodically. Disclaimer AusCERT advises 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 software products or tools within this document does not constitute endorsement by AusCERT or The University of Queensland.

Contents A. Determine Appropriate Security B. Installation C. Patch and Update D. Minimise

1 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

E. Secure Base OS F. Secure Major Services G. Add Monitoring Capability H. Connect to Net I. Test Backup/Rebuild Strategy J. Maintain References

A. Determine Appropriate Security Apply your organisation's information security policy to guide the decisions made in this section.

A.1 Computer role First decide on and document the role of this computer. This means specifying exactly which services the computer will provide. Example computer roles are: email server and email virus/spam scanner user workstation for word processing, email and web browsing combined web server / database server

A.2 Assess security needs of each kind of data handled The security measures appropriate for this computer will depend greatly on what information will be stored on it, or pass through it. For Internet connected computers, even for unimportant data, a certain baseline level of security will be required, to stop this computer being used as a platform to attack further into the network or other external networks. The following steps will help to determine the security needs of this system: 1. Data on this system Considering the computer role, identify each kind of information that will be handled by this computer. Examples are: office emails client personal data private keys and certificates source code being developed in-house The list should also identify information such as user passwords, which may be typed into this computer but which also give access to other systems that use the same password. 2. Threats Consider the potential threats to each kind of information identified above. Which classes of attacker will be motivated to read, modify or disable each of these kinds of data? Consideration of the threat should include both targeted and indiscriminate

2 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

attacks. Targeted attacks: Targeted attacks refer to those where attackers may specifically target your business or your customers. Depending on the kind of information processed, threats may include malicious changes by a disgruntled insider, a denial of service attack for the purpose of extortion, or industrial espionage or sabotage. Indiscriminate attacks: All computers on the Internet are subject to these threats. Some organisations believe that their systems will not be of interest to attackers; this is incorrect. Attackers are interested in controlling your computers for a number of reasons, including to launch attacks on other organisations, to send spam, or to capture users' authentication credentials. 3. Impacts if threats are realised For each of the threat scenarios, estimate the impact on your organisation if the attack is realised. The cost may be measured in money / time / reputation 4. Determine acceptable risk Based on the potential impacts, determine what level of risk can be accepted. Such determination of risk acceptance levels should be done in conjunction with senior management.

Making explicit the threats and impacts in this way will highlight what the priorities should be for protecting each kind of information on the system. For organisations with little dependence on IT and no critical data these steps can be done informally. Otherwise, consider doing the assessment in writing, integrated with the risk assessment for the overall network. More formal risk management frameworks are available to assist with this, such as OCTAVE (http://www.cert.org/octave). In the Australian context, guidelines for information security risk management are provided by HB 231:2004, available from Standards Australia.

A.3 Trust relationships Identifying trust relationships will determine whether the security of this computer is appropriate relative to other computers. For example, a secure configuration is useless if a UNIX server is managed from day to day using a workstation controlled by an attacker. Below are three questions to ask to determine the trust relationships: 1. Which systems does this computer trust? These will include the following: Workstations used to administer this computer e.g. by SSH or web interface; Authentication servers (e.g. kerberos or LDAP servers); Backup servers (e.g. during a restore). Those systems must be made at least as secure as this computer. 2. Which computers trust integrity of data served up by this computer?

3 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

For example: Authentication clients, if this is an authentication server; Computers that may be administered from this computer; Workstations, if this is a file server. This computer must be made at least as secure as those systems. 3. Which computers trust this computer to maintain confidentiality of data? These may include: Peer VPN endpoints; Database clients. This computer must be made at least as secure as those systems.

A.4 Uptime requirements and impact if these are not met Consider how reliable this computer is expected to be, and what the impact will be if these uptime requirements are not met. This can include issues such as the following: Will work in the organisation be affected if this computer fails? Are specific service levels required by contract? Will business be lost if customers cannot access a web site? These uptime requirements will also influence the Backup/Rebuild Strategy chosen later in section I.

A.5 Determine minimal software packages required for role From the role determined in A.1, document which programs are needed to fully implement this role. This includes any extra libraries or support software that the main software needs. Later in this checklist, installed software will be minimised to just the software determined here.

A.6 Determine minimal net access required for role Document which TCP and UDP port numbers this computer will need to communicate on to perform its role, including the direction (in or outbound). Where appropriate, also record which specific computers this one will be communicating with for each service. Later in this checklist, network access will be restricted to only this required access.

B. Installation B.1 Install from trusted media If installing the operating system from downloaded ISO images, Use a trustworthy computer to check the integrity of the install CDs after they are burnt, using a hash

4 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

(MD5/SHA1/other) or detached PGP signature. An example command to check the MD5 hash of a CD under Linux would be: dd if=/dev/cdrom bs=64k | md5sum If using MD5 or SHA1 hashes, make sure that the list of hashes itself comes from a trusted source (either digitally signed (preferably) or from a trusted SSL authenticated web site).

B.2 Install while not connected to the Internet Install the operating system while not connected to the Internet. For a network installation of multiple machines, it is preferable to use an isolated staging network during the initial installation.

B.3 Use separate partitions Creating separate partitions for different parts of the filesystem allows: more flexibility in applying different mount options to different parts of the hierarchy, to restrict the use of files (as described below in E.5.2); avoiding denial of service by disk space exhaustion (e.g. log files); hard links are prevented from crossing partition boundaries. Use separate partitions for /, /usr, /var, /tmp and /home. Good planning of the partition scheme is essential.

B.4 Install minimal software When making selections during the installation process, install only the software sets required for this computer's role, as determined in A.5

Installation - general notes:

Solaris, HP-UX, AIX

C. Apply all Patches and Updates Ensuring the latest patches and updates are applied is crucial to security as UNIX systems with unpatched public vulnerabilities are quickly compromised by attackers.

C.1 Initially apply patches while offline After the first install, consider applying patches and updates while disconnected from the network, either: 1. from a CD containing the patches, or 2. on a trusted staging network disconnected from the Internet. If updating directly over the Internet is really necessary, then first install and configure a restrictive host firewall (see H.1) on the new system, allowing only the connections required for updating. (Often DNS plus one of HTTP, HTTPS or SSH outbound is all that is required.) In this case, after the initial updating is complete, the host can then be disconnected from the network until the remaining steps in sections D to H have been completed to bring the system to the appropriate level of security. Do also patch and update any third party software installed.

5 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

C.2 Verify integrity of all patches and updates Before installing any patches or updates that have been downloaded, check that they have not been modified. On some systems, digital signatures on patches or updates may be verified automatically by the package tool. Patches or updates for some other systems may be PGP signed. These signatures can be verified using GnuPG, available with your system or from http://www.gnupg.org If a digital signature is not available but an MD5 or SHA hash is, then use this to verify the integrity of the patch/update. For those operating systems that do not come with an MD5 tool, a free implementation is available at http://www.fourmilab.ch/md5

Red Hat / Fedora,

Solaris

C.3 Subscribe to mailing lists to keep up to date Ensure that you are subscribed to the "announce" and "security" mailing lists for each vendor of software that you use to ensure that you have rapid notification of future patches and security updates (see J.1). If automatic update checks and/or automatic application of updates are available, also consider whether using this is appropriate for your situation. Some other steps recommended to be ready for future patching are described in section J (Maintain).

Patching - general notes:

HP-UX

D. Minimise After the initial installation is complete, minimise the amount of software that is present by uninstalling or disabling the unneeded software packages, leaving a minimal set of software. Ideally, only the software that will be used in performing the computer's role, as decided in A.1 above, should remain. Check the dependencies between software packages to determine which libraries and helper software are also required for the role.

D.1 Minimise network services D.1.1 Locate services and remove or disable 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

6 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

FreeBSD,

http://www.auscert.org.au/render.html?it=5816&template=1

AIX

D.1.2 Minimise inetd/xinetd 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

D.1.3 Minimise portmapper and RPC services 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.

D.1.4 Notes on particular network services 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

7 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

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

D.2 Disable all unnecessary startup scripts The way startup scripts are used to start services when the system boots is different on different variants of UNIX. See your vendor's documentation for specific details. On BSD style systems, the file rc.conf or rc.conf.local can be edited to change which services will be started. Some systems have further startup scripts located in /usr/local/etc/rc.d/ On System V style systems, the services to be started each have a script with an entry under /etc/init.d or /etc/rc.d/init.d Use ps at this stage to view the processes running by default. Understand the purpose of each process and disable it in the startup scripts if it is not needed. Solaris,

AIX

D.3 Minimise SetUID/SetGID programs Programs which are SetUID or SetGID are good candidates for removal because any bugs in these programs are likely to have a security impact, allowing an attacker who already has access to the system to elevate priveleges and increase their control. The steps below are particularly important for multi-user systems, such as web hosting servers with multiple accounts. Locate SetUID/SetGID programs using a command such as +6000 -ls

find / -perm

Preferably uninstall them if not needed Otherwise disable the SUID or SGID bit, so that the program is only given the privileges of the user running it. Note that in some cases this can mean that the program will then only work when run by root. If SetUID/SetGID programs really need to be used by other users, then consider restricting who can run them by group membership: create a new group for this program change the group ownership of the binary to this new group change the permissions of the binary to deny execute permission for Others (chmod o-rx) add the users who must use this program to the new group. Never allow SetUID shell scripts.

8 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

Debian,

Solaris

http://www.auscert.org.au/render.html?it=5816&template=1

OpenBSD

D.4 Other minimisation If a graphical user interface is not required on this computer then consider not installing the X window system, as well as desktop environments such as CDE, Gnome and KDE. The reason is that these are large, complex software systems with components that must run with privileged access to the computer's hardware. If IPv6 is not being used, then consider also turning off the IPv6 stack. OpenBSD

Minimise - general notes:

Solaris, HP-UX, AIX

E. Secure Base OS E.1 Physical, console and boot security Check that physical access to the computer is restricted appropriately. Regardless of what configuration is used, an attacker with physical access to the computer can in most cases take full control of the system. That said, the following controls should be considered to increase the difficulty of the walk-in attack: Disable booting from any removable media by configuring the BIOS or EEPROM. Set a password to prevent changes to these BIOS or EEPROM settings. Ensure the boot loader does not allow booting to single user mode without a password. Consider disabling any special hotkeys that drop the console into a debugging mode. For situations where access is public, such as an internet cafe or shared computer lab, these measures are essential. For other situations these measures can be considered based on physical security. Solaris,

HP-UX,

FreeBSD,

OpenBSD

E.2 User Logons E.2.1 Account Administration 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

9 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

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.

E.2.2 Special accounts 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 Root account E.2.3.1 Root password Restrict the number of people who know the root password.

E.2.3.2 No direct root logins Consider not allowing root to directly log in over the network. Instead, require first to log on as an ordinary user, then use sudo or else su to root. Reasons: 1. For accountability. This is particularly important if there is more than one person who logs on to this computer. 2. It also makes an attacker do more work to get to root. Secure terminals: The relevant configuration file may be called /etc/ttys,

10 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

/etc/default/login, /etc/security or /etc/securetty depending on the system. See the manual pages for file format and usage information.

Check that the secure option is removed from any 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 command.] If it is not already the default, consider using a special group (such as the wheel group on BSD systems) to restrict which users can use su to become root.

E.2.4 PATH advice 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.

E.2.5 User session controls 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.

11 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

For csh: set -r autologout=15 (15 minutes) For bash: typeset -r TMOUT=900 (15 minutes = 900 seconds) HP-UX,

FreeBSD,

AIX

E.3 Authentication E.3.1 Password authentication E.3.1.1 Evaluate two-factor authentication Consider the benefit and cost of using one-time password sheets, security tokens or smart cards instead of relying on reusable passwords alone. Passwords do not scale well in a network because lack of trust between domains requires different passwords. In practice this results in users either choosing bad passwords, reusing passwords with multiple systems or companies, or writing them down. The various forms of two-factor authentication offer an answer to this.

E.3.1.2 Shadow passwords Most UNIX systems now use a shadow password scheme by default. A few may not - see notes below. Using the shadow password scheme is important because it ensures that the password hashes are not world readable. This prevents simple dictionary and brute force attacks being applied to get the passwords from the hashes. Enable password shadowing if it is not on by default. See OS specific footnotes for details. HP-UX,

AIX,

IRIX

E.3.1.3 Ensure all accounts have passwords or are disabled. Verify that all accounts have passwords. (i.e. the password field is not empty) Check NIS+ passwords too, if you have them. Debian

E.3.1.4 Password Policy Have a clear password policy for your organisation. See the AusCERT Advisory SA-93.04 for guidelines on developing password policies.

E.3.1.5 Enforce password complexity Check if your operating system has a built-in way to configure requirements on password complexity, such as minimum password lengths, requirements for numbers and symbols, etc. For PAM systems this can be done by a PAM module. If your PAM enabled system does not have such a module, you can use the pam_passwdqc module available from http://www.openwall.com /passwdqc/ which supports Linux, Solaris, FreeBSD and HP-UX. For a multi-user system which does not have any mechanism for enforcing difficult passwords, password auditing is discussed in

12 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

section J.7.3 HP-UX

AIX

E.3.1.6 Password ageing and password history Consider enforcing password aging, so that users will need to change passwords after a certain maximum period of time. Be aware that using too short a change period will probably just result in users circumventing policy by writing passwords down. Consider enforcing a password history, so that users do not re-use recently used passwords. Note that if using a history, a minimum period between password changes may also be necessary, so that people do not rapidly cycle through passwords to get around the history/ageing restrictions. HP-UX

E.3.2 One-time passwords 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.

E.3.3 PAM Pluggable Authentication Modules 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 . 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)

13 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

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

E.3.4 NIS / NIS+ 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.

E.3.5 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 Access Control E.4.1 File Permissions

14 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

E.4.1.1 Permissions for key files and directories Ensure that system configuration and runtime files are owned by root and are not writable by other users. A few examples of such files are: startup scripts (rc.* and init.d files), any firewall configuration files, /etc/profile, /etc/hosts.allow, /etc/mtab, /etc/utmp, /var/adm/wtmp (or /var/log/wtmp), /etc/syslog.pid (or /var/run/syslog.pid)

Ensure that log files (usually located in /var/log/ or /var/adm) are only writable by root. Ensure that the files holding the kernel and any kernel modules are owned by root, have group ownership set to group id 0 and permissions that prevent them being written to by any non-root users. Ensure that there are no unexpected world writable files or directories on your system. Use the find command to locate these, for example find / -type d -perm +2 -ls will locate world writable directories. Ensure the sticky-bit is set on /tmp, /var/tmp and any other worldwritable directories that exist. This is often denoted by a "t" in the last column of permissions when listing with ls -ld Make a list of the non-root-owned directories outside of the user home area, using find / -path /home -prune -o -type d ! -uid 0 -ls and ensure that there is nothing unexpected. In particular /etc, /usr/etc, /bin, /usr/bin, /sbin, /usr/sbin, /tmp and /var/tmp should all be owned by root. Some systems ship files and directories owned by user "bin" (or "sys"). This varies from system to system and may have security implications, especially if filesystems are exported with NFS. Change all non-setuid files and all non-setgid files and directories owned by "bin" that are world readable but not world or group writable to be owned by root instead, with group ownership by group id 0. Solaris

E.4.1.2 Protect programs used by root Any binary that might get run as root, as well as all parent directories of that binary, must be owned by root and also not be writable by any other user or group. This means: any program used by system startup scripts any program used by daemons any program used in root cron jobs any program in root's PATH any program used in root's shell startup scripts any program executed in turn by the programs above. as well as all parent directories of these programs. Ensure that root's PATH is secure, as described in section E.2.4.

15 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

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. Check the contents of the following files for the root account. Any programs or scripts referenced in these files should have the permissions recommended above: ~/.login, ~/.profile, ~/.bashrc, ~/.cshrc and similar shell initialization files; ~/.logout and similar session cleanup files;

Program configuration files in the home directory such as .vimrc and .exrc; crontab and at entries;

scripts and programs on NFS partitions; /etc/rc* and similar system startup and shutdown scripts.

If any programs or scripts run by these files use further programs or scripts then those also need to be secure. Do not allow any shell scripts to be SetUID.

E.4.1.3 Protect directories written to by root The advice in this section also applies to protecting other daemon or server accounts. Any predictably named files created by scripts, daemons, server processes, or cron jobs MUST be in a directory that is non-writable by less privileged users and groups. This includes directories used for logging. Otherwise, a symlink attack may be used to escalate privileges from unprivileged user to a more privileged one, such as root. Scripts and programs that need to create files in a directory writable by others, such as /tmp, must take special precautions to create the file atomically. If your organisation's system administration scripts need to use temporary files, refer to the Secure Programming for Linux and Unix HOWTO for a discussion on doing this securely in shell scripts, Perl and C.

E.4.1.4 Group membership There are two different schemes in use for arranging UNIX groups, and these lead to different recommendations for home directory permissions and umask. 1. Traditional group scheme In this scheme most users belong to a common group by default, such as the group "users". This is the default on OpenBSD, Slackware, ... 2. User Private Group scheme In this scheme a separate group is created in /etc/groups for each user. The user should be the only member of that group. This scheme makes working on group projects easier, as users do not need to use

16 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

the umask command when working in a common project directory. This is the default on FreeBSD, Red Hat, Debian, ... Do not use the legacy feature of password protected groups. It is insecure because the /etc/group file is not shadowed, so hashes are world readable. HP-UX

E.4.1.5 umask for users A user's umask determines the default permissions on new files created by the user. Note that unlike file permissions, the umask shows which permission bits are not allowed, e.g. a umask of 777 means no access. Ensure the umask for each user is set to a restrictive value within the user's shell startup scripts. The appropriate umask will depend on whether a User Private Group scheme is used. If the traditional group scheme is being used, ensure a umask of 077 or 027 is set in the users' shell startup scripts. A weaker umask of 007 is acceptable if the User Private Group scheme is being used.

E.4.1.6 Permissions for user home directories Ensure user home directories are owned by the user, and are not writable by any other user or group. If the traditional group scheme is in use, the group ownership on home directories may be set to the common group, so ensure that the directory is not group-writable. If the User Private Group scheme is in use, the group ownership on home directories should be set to the user's private group. For either scheme, consider setting permissions on home directories to 700 to prevent other people from viewing the contents by default.

E.4.2 Filesystem attributes 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

E.4.3 Role Based Access Control 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,

17 of 41

Solaris,

HP-UX,

AIX

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

E.4.4 sudo 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.

E.4.5 Consider mandatory access control features 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

E.5 Other E.5.1 Cron Ensure that the permissions for root's crontab are set to 600 and that the owner is set to root.

18 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

Consider not allowing regular users to add cron jobs.

E.5.2 Mount options 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

E.5.3 Non-execute memory protection 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

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

E.5.5 .netrc files ~/.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.

Secure Base OS - general notes:

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

F. Secure Major Services F.1 Confinement Server processes can be confined with reduced access to the system, so that if the software misbehaves or is compromised the damage is limited. The facilities available to do this vary on different UNIX systems.

F.1.1 Running under an unprivileged account Ensure that services run under unprivileged accounts where possible.

19 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

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

F.1.2 using chroot jails 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.

F.1.3 Other confinement mechanisms 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

F.2 tcp_wrappers The primary way to restrict accesses to the host's services by IP address is to use a host firewall, discussed in section H.1. However, many UNIX and Linux systems also provide a second control, in the form of tcp_wrappers. This may already be in use on your system by default. tcp_wrappers does provide some extra flexibility if needed; it can be configured to require reverse DNS lookups or ident (RFC931) lookups, allows automatic execution of scripts when conditions are met, and can also provide improved logging for services that do not have adequate access logs of their own. There are two ways that tcp_wrappers may be used on the system: It is possible to explicitly "wrap" a service, by running the program tcpd to accept connections which are then passed to the actual network service. More commonly though, the vendor has already compiled network services to use the libwrap library. In this case the relevant daemon will enforce the tcp_wrappers restrictions when accepting connections. The main configuration file for tcp_wrappers is /etc/hosts.allow Explicitly list host IPs which are allowed access to the services in this file. At the bottom of the file put all:all:deny to deny all other IP addresses. The rules in this file work on a "first match wins" basis. The file /etc/hosts.deny may also be used, though this is no longer required. If /etc/hosts.deny is present, put all:all in this file. HP-UX

20 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

F.3 Other general advice for services F.3.1 Configure services to listen on one interface only. 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

F.3.2 Adding SSL to existing services 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/

F.4 SSH Do not log in via SSH from an insecure workstation. Contrary to popular belief, public key cryptography will not protect you in doing this. Where SSH is used, a trust relationship is implied - the SSH server computer trusts the security of the SSH client computer. Be aware that when doing X-forwarding through SSH, the trust relationship is also reversed - the workstation running the X display must also trust the computer running each X program. This is due to the cross-client X attacks described below in F.9.3 Suggested configuration options for the OpenSSH sshd implementation: In the configuration file sshd_config do use: Protocol 2 (the SSH 1 protocol had weaknesses) ListenAddress 192.168.45.3 (bind to one address only) PermitRootLogin no Listen 222 (consider using an alternate port) PermitEmptyPasswords no AllowUsers one two@host1 three

Disable other authentication options. In particular, do not use: RhostsAuthentication HostBasedAuthentication RhostsRSAAuthentication (not good for accountability)

Where SSH is used by scripts, configure SSH on the server side to allow execution of a certain single command only. This is achieved using a command= directive in the authorized_keys file. Many UNIX and Linux systems are compromised by attackers through SSH, by

21 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

simply using a dictionary attack on passwords. It is strongly recommended to use public key authentication instead of passwords. If password authentication must be used with SSH, verify that a strong password policy is in effect, as described in E.3.1.

F.5 Printing There are several different default printing systems supplied with UNIX and Linux systems. The three most common of these are BSD style lpr (also found on AIX), LPRng and CUPS. In general, prevent the printing service from listening to the network unless necessary for this computer's role. If a network printing service is part of this computer's role, then do not rely solely on IP addresses for authentication (for instance the hosts.lpd file with lpd or LPRng is based only on IP address.)

F.6 RPC/portmapper Look for the specific facilities provided by your operating system for securing RPC access with authentication and/or encryption. The security features available vary greatly between UNIX variants. Be aware that some older portmapper/rpcbind daemons may forward RPC requests from remote hosts, and make them appear to come from the localhost.

F.7 File services NFS/AFS/Samba F.7.1 NFS 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.

22 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

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

F.7.2 Samba 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).

F.8 Email service Check that your Mail Transport Agent (mail server software) is configured not to relay mail from unauthenticated hosts. This helps to prevent your mail server from being misused to send bulk spam. The open relay testing page at http://www.abuse.net/relay.html can assist in testing this.

23 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

24 of 41

http://www.auscert.org.au/render.html?it=5816&template=1

F.8.1 Sendmail 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.

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

F.8.2 Mail server MTA choices 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

F.9 The X Window System F.9.1 Restrict access to the X server 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.

F.9.2 Protect any X traffic 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)

F.9.3 Avoid cross-client X attacks 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.

25 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

F.9.4 X display managers 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).

Ensure familiarity with the man pages for xauth and Xsecurity. This information will be useful in configuring the security you require. The chapter on X Window System security in the X Window System Administrator's Guide is also a good reference.

F.10 DNS service F.10.1 BIND 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.

F.10.2 DNS server choices 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

F.11 WWW service F.11.1 General configuration

26 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

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.

F.11.2 Web applications 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.

F.11.3 TLS / SSL 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.

27 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

28 of 41

http://www.auscert.org.au/render.html?it=5816&template=1

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.

F.11.4 Static-only webserver 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

F.12 Squid proxy Avoid providing an open proxy Configure access controls so that only authorised clients can make requests through the proxy. Note that Squid ACLs use the first rule that matches. If none match, the last rule checked is used inverted. So to avoid unintended access it is best to put a catch-all deny rule last: http_access deny all Listen on a single interface If this computer has more than one network interface, specify the interface's IP address with a configuration line: http_port 192.168.0.7:8080 to cause squid to only listen on that interface. Disable unused protocols If you are not using the inter-cache and management protocols, then turn them off by setting the port to 0, as in the following configuration lines: snmp_port 0 htcp_port 0 icp_port 0 Deny proxy to localhost To ensure that a remote attacker cannot connect to other ports on the local computer via the Squid proxy, include access rules similar to the following: acl to_localhost dst 127.0.0.1/8 deny to_localhost Secure squid files Check that squid logs and cache files are not world readable. These can contain data from proxy users that should remain confidential.

F.13 CVS Use SSH to authenticate and encrypt all CVS access. Do not use CVS pserver functionality. Create a UNIX account on the computer for each CVS user, and limit their SSH session so it is only able execute the command "cvs server". Why this provides better security than cvs pserver: 1. cvs does not need to run as root 2. Access control is enforced by the operating system, not by cvs.

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

Be aware that CVS access control is per-directory, rather than per-file. (The CVS manual in section 2-2-2 describes the access control model.) Use LockDir in CVSROOT/config to have read only directories where appropriate.

F.14 Web browsers Do not allow external programs to spawn automatically for any type of downloaded content. This includes not allowing browsers to automatically launch multimedia viewers, shells, script interpreters or macro processors. Instead configure the browser to prompt before opening external programs. This can be achieved using the helper application preferences for the browser. Consider disabling Java and JavaScript in the web browser. Do not run a web browser as root.

F.15 FTP service Do not run an FTP service unless there is no alternative. If the purpose is to provide unauthenticated access or public access it is better to use a simple HTTP server such as publicfile (see section F.11.4). If authenticated access is required, it is better to use sftp. An sftp server is included as part of OpenSSH, which is available either as packages from your OS vendor, or as source from http://openssh.com/. Several free graphical clients are available to support Windows users, including WinSCP (http://winscp.net/).

F.15.1 General configuration Ensure that your FTP server does not have the SITE EXEC command, or that this command is disabled correctly. Test with: % telnet localhost 21 USER username PASS password SITE EXEC

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,

29 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

~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: ftp:*:400:400:Anonymous ftp:/home/ftp:/bin/false 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.: root:*:0:0:Ftp maintainer:: ftp:*:400:400:Anonymous ftp:: 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

30 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

F.15.2 Anonymous FTP 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.

F.15.3 Upload directories 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.

G. Add Monitoring Capability 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.

G.1 syslog configuration Consider using syslog's remote logging feature to send logs to a separate logging computer. Remote logging ensures that even if the UNIX system is compromised, attackers cannot simply modify the log files to cover their tracks. Consider protecting the network logging stream with authentication and encryption, for example by tunnelling it over SSH with netcat. If logging over the network, do log to local files as well.

31 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

Unless this computer is a log server, ensure that syslog will not accept incoming log packets over the network. On some systems this is the default. On others it may be implemented by starting syslog with the -t option (nolisten). Consider increasing the level of logging provided by syslog. Make sure that the messages of the LOG_AUTH facility at level LOG_INFO and above get logged. For email, enable a minimum level of "info" for mail messages to be logged by syslog. Check that there is a reliable mechanism for log rotation. If there is not, you may need to replace an existing logging daemon with a more secure or full-featured one. Check that all login attempts are logged, both successful and unsuccessful. There may be several different ways to log in, such as at the console, through X and through SSH. Consider protecting your log files with filesystem attributes if possible, to make them append-only. See section E.4.2 for details. OpenBSD,

AIX

G.2 Monitoring of logs G.2.1 Process for log monitoring 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.

G.2.2 Automated log monitoring tools 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 Ensure any automated reporting facilities provided by your operating system are turned on, and are sending output to an appropriate user for reading. (e.g. FreeBSD / OpenBSD daily scripts) Regularly monitor logs for both successful and unsuccessful logins, and uses of su and sudo. Regularly check for repeated access failures.

G.3 Enable trusted audit subsystem if available

32 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

On many platforms a more comprehensive audit subsystem is optionally available. The benefit is to allow more dependable and configurable logging of a wider range of security events. Enable the trusted system audit features if available for your platform. Linux,

Solaris,

HP-UX,

AIX

G.4 Monitor running processes G.4.1 Availability of servers 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.

G.4.2 Process accounting 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.

G.4.3 lsof 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/

G.5 Host-based intrusion detection G.5.1 File integrity checker 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

33 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

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

G.5.2 Antivirus / malware detection 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.

Host-based intrusion detection - notes:

HP-UX

G.6 Network intrusion detection G.6.1 Signature matching IDS 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.

G.6.2 ARP monitoring 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/

34 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

Monitoring - general notes:

http://www.auscert.org.au/render.html?it=5816&template=1

OpenBSD

H. Connect to Net H.1 First put in place a host firewall. H.1.1 Identify host firewall software 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

H.1.2 Design host firewall 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/

35 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

Building Internet Firewalls, Second Edition

H.1.3 Weak end system 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

H.2 Position this computer behind a border firewall. Position the UNIX system on a protected subnet, with at least a separate firewall device sitting between it and the open Internet.

H.3 Network stack hardening/sysctls The kernel's network settings can be tuned and made more secure, usually using the sysctl command or configuration file. The details of how to do this are very specific to each operating system. It is recommended to check the following settings: Disable IP source routing. Disable ICMP redirects. Disable forwarding/routing of IP packets unless this computer is a router. See OS specific footnotes for details. If your OS provides syncookies to mitigate SYN-flood denial of service, then ensure that this feature is turned on. Syncookies are available on Linux, Solaris and FreeBSD. Consider configuring shorter state timeouts and increasing the size of state tables to make the system more resistant to denial of service. For servers, consider configuring a static IP address on the host itself, rather than using a static IP allocation through DHCP. On critical computers, consider using a static ARP cache to prevent ARP spoofing attacks from the local LAN. Linux,

Solaris,

HP-UX,

FreeBSD,

OpenBSD,

AIX

Further information on adjusting network parameters is provided in the following documents: UNIX IP Stack Tuning Guide v2.7 (Rob Thomas) - covers AIX, Solaris, HP-UX, Linux, FreeBSD and IRIX. http://www.cymru.com/Documents/ip-stack-tuning.html TCP/IP Stack Hardening - covers AIX, FreeBSD, HP-UX, Linux, Solaris and IRIX. http://www.cromwell-intl.com/security/security-stack-hardening.html

36 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

H.4 Connect to network for the first time It is recommended to connect the computer to the network for the first time at this stage.

I. Test Backup/Rebuild Strategy I.1 Backup/rebuild strategy When an intrusion or suspected intrusion is detected, your options in responding will depend critically on whether you have an effective backup/rebuild strategy in place beforehand. With a rebuild process that is largely automated, it is possible to either swap in a new hard disk and rebuild the server, or rapidly deploy a replacement server, allowing the compromised machine to be taken off the network quickly while maintaining uptime. This ability to disconnect the computer rapidly reduces the risk of further intrusion to other systems, and at the same time preserves evidence on the hard disk at an early stage. But it depends on an effective restore and rebuilding process already being in place. Implement a backup, restore and rebuilding process that satisfies your security policy. Depending on the uptime requirements determined in section A.4 for this system, consider whether a replacement hard disk or a full replacement server is appropriate for your situation. Protect the confidentiality and integrity of the backups themselves, as the information in the backups is usually as sensitive as the original system. For example, the authentication information in the backup is often sufficient to compromise the original system remotely. For integrity, the aim is that an attacker compromising this system can only alter future backups, and not past backups.

I.2 TEST backup and restore The implementation of the restore/rebuild system is not complete until it has been tested out in practice. Schedule a full restore/rebuild of the system to verify that the process works and is sufficiently fast.

I.3 Allow separate restore of software and data Consider having business data backed up and restorable separately from executable programs. After a compromise, this allows more flexibility, for example to restore today's data but with the system and software backup from three weeks ago.

I.4 Repatch after restoring Repatch the system immediately after restoring from backup, to ensure that all the patches and software updates released between the time that backup was made and the present are applied.

37 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

I.5 Process for intrusion response After an intrusion or suspected intrusion has taken place, it may be necessary to liaise with law enforcement, and/or investigate what has happened, and determine if other systems on your network have been affected.

I.5.1 Documented process 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.

I.5.2 Forensic tools 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

I.5.3 Malware detection tools 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.

38 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

J. Maintain J.1 Mailing lists Notifications of patch releases and security updates are generally done via mailing lists. Subscribe to the vendor "announce" list as well as any security mailing lists for your specific operating system. Subscribe to the appropriate security/updates mailing list for each third party software package installed. Also subscribe to security advisory mailing lists from your local incident response team (if you have one available). AusCERT Security Bulletins are available at http://www.auscert.org.au/1 US-CERT Vulnerability Notes are available at http://www.kb.cert.org/vuls/

J.2 Software inventory Maintain an up-to-date list of software installed on each system, with version numbers. This list includes the base OS and each piece of third party software. This is significant, as when a vulnerability advisory is released, it is easy to check whether the versions on your systems are affected.

J.3 Rapid patching The window of time between vulnerabilities being publicly announced and widespread exploitation is now very short. Design your patching and update process aiming to allow critical patches to be applied within 48 hours of patch release. For important systems, maintain a test environment where patches can be trialled first before deploying to production systems. Be aware that installing patches/updates can sometimes re-enable services that you have disabled.

J.4 Secure administrative access J.4.1 Strongly authenticated access only 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.

J.4.2 Administer only from a secure workstation 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,

39 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

web browsing and document creation.

J.5 Log book for all sysadmin work Maintain a log book to record all significant system administration work on the system.

J.6 Configuration change control with CVS Consider using a CVS server on a separate computer to manage the configuration files such as those in /etc and /usr/local/etc. This also makes rebuilding the system more efficient. See section F.14 for secure use of CVS.

J.7 Regular audit Design and put into action a process to re-assess the security of the system at regular intervals.

J.7.1 Re-apply this checklist 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.

J.7.2 Check for dormant accounts 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.

J.7.3 Audit weak passwords 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/

J.7.4 Apply network scan/audit tools 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

40 of 41

27-05-2013 09:32 PM

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

http://www.auscert.org.au/render.html?it=5816&template=1

Index of OS Specific Footnotes i. Linux ii. Solaris iii. HP-UX iv. FreeBSD v. OpenBSD vi. AIX vii. IRIX

Further Reading Books Practical UNIX & Internet Security, 2nd Edition Simson Garfinkel and Gene Spafford O'Reilly & Associates, 1996 Volume 8: X Window System Administrator's Guide Linda Mui and Eric Pearce O'Reilly & Associates, 1992 (out of print) PDF now free online at http://www.oreilly.com/openbook/ Securing Systems with the Solaris Security Toolkit Alex Noordergraaf and Glenn Brunette Prentice Hall PTR/Sun Microsystems Press, 2003 Managing NFS and NIS, 2nd Edition Hal Stern O'Reilly & Associates, 2001 Building Internet Firewalls, Second Edition Elizabeth D. Zwicky, Simon Cooper, and D. Brent Chapman O'Reilly & Associates, 1995

Online References AusCERT Security Bulletins http://www.auscert.org.au/1 US-CERT Technical Cyber Security Alerts http://www.us-cert.gov/cas/techalerts /index.html US-CERT Current Activity http://www.us-cert.gov/current/

41 of 41

27-05-2013 09:32 PM