unix and linux security checklist

8/8/2019 UNIX and Linux Security Checklist

1/59

UNIX and Linux SecurityChecklist v3.0

AusCERT public release2007-07-25

Introduction

This document has been published by the Australian ComputerEmergency Response Team (AusCERT). It provides a checklist of steps to improve the security of UNIX and Linux systems. Weencourage system administrators to review all sections of thisdocument and if appropriate modify their systems to fix potentialweaknesses.

The checklist is structured to follow the lifecycle of a system, fromplanning and installation to recovery and maintenance. Sections Ato G of the checklist are best applied to a system before it isconnected to the network for the first time. In addition, the checklistcan be reapplied on a regular basis, to audit conformance.

No two organisations are the same, so in applying the checklistconsideration should be given to the appropriateness of each actionto your particular situation. Rather than enforcing a singleconfiguration, this checklist will identify the specific choices andpossible security controls that should be considered at each stage.

Operating system specific footnotes throughout the document offersome additional information to help with applying these steps onspecific UNIX and Linux variants.

The most current version of this document is available athttp://www.auscert.org.au/1935

We will continue to update this checklist. Any comments should bedirected via email to [email protected].

Before using this document, please ensure you have the latestversion. New versions of this checklist will be available via the URLlisted 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 withsecurity policies that are in place within their organisation. Listing of
http://www.auscert.org.au/1935http://www.auscert.org.au/1935


2/59


3/59

For Internet connected computers, even for unimportant data, acertain baseline level of security will be required, to stop thiscomputer being used as a platform to attack further into thenetwork or other external networks.

The following steps will help to determine the security needs of thissystem:

1. Data on this system

Considering the computer role, identify each kind of information thatwill 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 accessto other systems that use the same password.2. Threats

Consider the potential threats to each kind of information identifiedabove. Which classes of attacker will be motivated to read, modifyor disable each of these kinds of data?

Consideration of the threat should include both targeted andindiscriminate attacks.

Targeted attacks: Targeted attacks refer to those where attackers may specificallytarget your business or your customers. Depending on the kind of

information processed, threats may include malicious changes by adisgruntled 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. Someorganisations believe that their systems will not be of interest toattackers; this is incorrect. Attackers are interested in controllingyour computers for a number of reasons, including to launch attackson other organisations, to send spam, or to capture users'

authentication credentials.


4/59

3. Impacts if threats are realised

For each of the threat scenarios, estimate the impact on yourorganisation 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 beaccepted. Such determination of risk acceptance levels should bedone in conjunction with senior management.

Making explicit the threats and impacts in this way will highlightwhat the priorities should be for protecting each kind of informationon the system.

For organisations with little dependence on IT and no critical datathese steps can be done informally. Otherwise, consider doing theassessment in writing, integrated with the risk assessment for theoverall network.

More formal risk management frameworks are available to assistwith this, such as OCTAVE ( http://www.cert.org/octave ).

In the Australian context, guidelines for information security riskmanagement are provided by HB 231:2004, available fromStandards Australia.

A.3 Trust relationships

Identifying trust relationships will determine whether the security of this computer is appropriate relative to other computers. Forexample, a secure configuration is useless if a UNIX server ismanaged from day to day using a workstation controlled by anattacker.

Below are three questions to ask to determine the trustrelationships:

1. Which systems does this computer trust?

These will include the following:
http://www.cert.org/octave/http://www.cert.org/octave/


5/59


6/59

A.5 Determine minimal software packages required

for role

From the role determined in A.1, document which programs areneeded to fully implement this role. This includes any extra librariesor support software that the main software needs.

Later in this checklist, installed software will be minimised to justthe software determined here.

A.6 Determine minimal net access required for role

Document which TCP and UDP port numbers this computer will needto communicate on to perform its role, including the direction (in oroutbound).

Where appropriate, also record which specific computers this onewill be communicating with for each service.

Later in this checklist, network access will be restricted to only thisrequired access.

B. Installation

B.1 Install from trusted media

If installing the operating system from downloaded ISO images, Usea trustworthy computer to check the integrity of the install CDs afterthey are burnt, using a hash (MD5/SHA1/other) or detached PGPsignature. An example command to check the MD5 hash of a CDunder 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) orfrom a trusted SSL authenticated web site).

B.2 Install while not connected to the Internet


7/59

Install the operating system while not connected to the Internet. Fora network installation of multiple machines, it is preferable to use anisolated staging network during the initial installation.

B.3 Use separate partitions

Creating separate partitions for different parts of the filesystemallows:

more flexibility in applying different mount options to differentparts of the hierarchy, to restrict the use of files (as describedbelow in E.5.2);

avoiding denial of service by disk space exhaustion (e.g. logfiles);

hard links are prevented from crossing partition boundaries.

Use separate partitions for /, /usr, /var, /tmp and /home. Goodplanning of the partition scheme is essential.

B.4 Install minimal software

When making selections during the installation process, install onlythe software sets required for this computer's role, as determined inA.5

Installation - general notes: Solaris , HP-UX, AIX

C. Apply all Patches and Updates

Ensuring the latest patches and updates are applied is crucial tosecurity as UNIX systems with unpatched public vulnerabilities arequickly compromised by attackers.

C.1 Initially apply patches while offline

After the first install, consider applying patches and updates whiledisconnected from the network, either:

1. from a CD containing the patches, or2. on a trusted staging network disconnected from the Internet.
https://www.auscert.org.au/5818#Bhttps://www.auscert.org.au/5819#Bhttps://www.auscert.org.au/5822#Bhttps://www.auscert.org.au/5818#Bhttps://www.auscert.org.au/5819#Bhttps://www.auscert.org.au/5822#B


8/59

If updating directly over the Internet is really necessary, then firstinstall and configure a restrictive host firewall (see H.1) on the newsystem, allowing only the connections required for updating. (OftenDNS plus one of HTTP, HTTPS or SSH outbound is all that is

required.) In this case, after the initial updating is complete, the hostcan then be disconnected from the network until the remainingsteps in sections D to H have been completed to bring the system tothe appropriate level of security.

Do also patch and update any third party software installed.

C.2 Verify integrity of all patches and updates

Before installing any patches or updates that have beendownloaded, check that they have not been modified.

On some systems, digital signatures on patches or updatesmay be verified automatically by the package tool.

Patches or updates for some other systems may be PGPsigned. 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 hashis, then use this to verify the integrity of the patch/update.

For those operating systems that do not come with an MD5tool, a free implementation is available athttp://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 thatyou have rapid notification of future patches and security updates(see J.1).

If automatic update checks and/or automatic application of updatesare available, also consider whether using this is appropriate foryour situation.

Some other steps recommended to be ready for future patching aredescribed in section J (Maintain).
http://www.gnupg.org/http://www.fourmilab.ch/md5/https://www.auscert.org.au/5817#C.2https://www.auscert.org.au/5818#C.2http://www.gnupg.org/http://www.fourmilab.ch/md5/https://www.auscert.org.au/5817#C.2https://www.auscert.org.au/5818#C.2


9/59

Patching - general notes: HP-UX

D. MinimiseAfter the initial installation is complete, minimise the amount of software that is present by uninstalling or disabling the unneededsoftware packages, leaving a minimal set of software. Ideally, onlythe software that will be used in performing the computer's role, asdecided in A.1 above, should remain.

Check the dependencies between software packages to determinewhich 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

FreeBSD , AIX

D.1.2 Minimise inetd/xinetd

If none of the services in the inetd configuration are neededthen disable inetd completely,

Otherwise, disable all non-needed services in theconfiguration.

Solaris , HP-UX

D.1.3 Minimise portmapper and RPC services

Disable the portmap service completely unless it is necessary forthe system to perform its role. Usually a machine that does not useNFS or NIS/NIS+ does not need portmap, however there are some

other software packages that may need it such as FAM (on IRIX orLinux), mcserv, dracd and several Solaris specific services.
https://www.auscert.org.au/5819#Chttps://www.auscert.org.au/5820#D.1.1https://www.auscert.org.au/5822#D.1.1https://www.auscert.org.au/5818#D.1.2https://www.auscert.org.au/5819#D.1.2https://www.auscert.org.au/5819#Chttps://www.auscert.org.au/5820#D.1.1https://www.auscert.org.au/5822#D.1.1https://www.auscert.org.au/5818#D.1.2https://www.auscert.org.au/5819#D.1.2


10/59

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

To check for registered RPC services, use the command:

/usr/bin/rpcinfo -p

On systems that track software package dependencies, that givesan even more convenient way to identify any packages that dependon 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 areinadequately authenticated. It is better to remove these anduse SSH and scp instead.

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

Remove or disable fingerdRemove or disable fingerd if present. Apart from the possibilityof a software vulnerability, fingerd allows an attacker toenumerate usernames on the system and to determine thetiming and frequency of system administrator logins.

Remove or disable tftpdDo not use tftpd (trivial file transfer protocol) unless

unavoidable.If tftpd is required for the computer's role, create a separatepartition to store the files to be served by tftp and limit thetftp daemon to the directory where this partition is mounted.

Ensure that the files in the tftp area are not writable, unlessthis is required for the system's role.

TFTP is not authenticated, so to protect devices using TFTP, it

is highly recommended only to allow it over a trusted network,


11/59

such as a trusted management network for configuringnetwork devices and not over the main LAN.

Disable SNMP daemon

If present by default, disable any SNMP daemon unless this isreally 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 systemboots 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 editedto change which services will be started. Some systems have furtherstartup scripts located in /usr/local/etc/rc.d/

On System V style systems, the services to be started each have ascript 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 startupscripts if it is not needed.

Solaris , AIX

D.3 Minimise SetUID/SetGID programs

Programs which are SetUID or SetGID are good candidates forremoval because any bugs in these programs are likely to have asecurity impact, allowing an attacker who already has access to thesystem to elevate priveleges and increase their control. The stepsbelow are particularly important for multi-user systems, such as webhosting servers with multiple accounts.

Locate SetUID/SetGID programs using a command such asfind / -perm +6000 -ls

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
https://www.auscert.org.au/5818#D.1.4https://www.auscert.org.au/5822#D.1.4https://www.auscert.org.au/5818#D.2https://www.auscert.org.au/5822#D.2https://www.auscert.org.au/5818#D.1.4https://www.auscert.org.au/5822#D.1.4https://www.auscert.org.au/5818#D.2https://www.auscert.org.au/5822#D.2


12/59

some cases this can mean that the program will then onlywork 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.

Debian , Solaris OpenBSD

D.4 Other minimisation

If a graphical user interface is not required on this computer thenconsider not installing the X window system, as well as desktopenvironments such as CDE, Gnome and KDE.

The reason is that these are large, complex software systems withcomponents that must run with privileged access to the computer'shardware.

If IPv6 is not being used, then consider also turning off the IPv6stack.

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 restrictedappropriately. Regardless of what configuration is used, an attacker

with physical access to the computer can in most cases take fullcontrol of the system.
https://www.auscert.org.au/5817#D.3https://www.auscert.org.au/5818#D.3https://www.auscert.org.au/5821#D.3https://www.auscert.org.au/5821#D.4https://www.auscert.org.au/5818#Dhttps://www.auscert.org.au/5819#Dhttps://www.auscert.org.au/5822#Dhttps://www.auscert.org.au/5817#D.3https://www.auscert.org.au/5818#D.3https://www.auscert.org.au/5821#D.3https://www.auscert.org.au/5821#D.4https://www.auscert.org.au/5818#Dhttps://www.auscert.org.au/5819#Dhttps://www.auscert.org.au/5822#D


13/59

That said, the following controls should be considered to increasethe 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 orshared computer lab, these measures are essential. For othersituations these measures can be considered based on physicalsecurity.

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 thesystem. This form includes a section that the user signs, stating thatthey have read your security policy or acceptable use policy andwhat the consequences are if they contravene the policy.

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

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

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

Note when disabling accounts:In general, besides setting the accounts to disabled or deleting thementirely it is also necessary to:
https://www.auscert.org.au/5818#E.1https://www.auscert.org.au/5819#E.1https://www.auscert.org.au/5820#E.1https://www.auscert.org.au/5821#E.1https://www.auscert.org.au/5818#E.1https://www.auscert.org.au/5819#E.1https://www.auscert.org.au/5820#E.1https://www.auscert.org.au/5821#E.1


14/59


15/59

1. For accountability. This is particularly important if there ismore 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,/etc/default/login, /etc/security or /etc/securetty depending on thesystem. See the manual pages for file format and usageinformation.

Check that the secure option is removed from any local entries thatdon't need root login capabilities. The secure option should beremoved from console if you do not want users to be able to rebootin single user mode. [Note: This does not affect usability of the sucommand.]

If it is not already the default, consider using a special group (suchas the wheel group on BSD systems) to restrict which users can usesu to become root.

E.2.4 PATH advice

Check that the current directory "." is not in the PATH. Note that anempty string is interpreted to mean the same as "." so also makesure the PATH does not contain any empty strings. For example, thefollowing PATH is insecure:/sbin:/bin:/usr/sbin::/usr/bin This PATH advice is especially importantfor the root account.

Ensure that directories writable by other users are not specifiedbefore system directories in a user's PATH, and check that no files inthe 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 notbe tricked into executing a malicious program. One way to addressthis 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 anysignificant protection if the user account were compromised, it does


16/59

prevent bad environment variables from being unintentionallyinherited by the privileged shell.

E.2.5 User session controls

Consider enforcing disk usage quotas on user accounts, by enablingquota support for individual users or by using the resource-limitsPAM module where available.

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

Evaluate the other facilities provided by your operating system toput conditions on user logon access, limit remote access, controluser resource usage and enforce other policies on user sessionssuch as logging/accounting. These features vary significantlybetween different UNIX variants, so check the documentation foryour system.

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

HP-UX, FreeBSD , AIX

E.3 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 reusablepasswords alone.

Passwords do not scale well in a network because lack of trustbetween domains requires different passwords. In practice thisresults in users either choosing bad passwords, reusing passwords

with multiple systems or companies, or writing them down. Thevarious forms of two-factor authentication offer an answer to this.
https://www.auscert.org.au/5819#E.2.5https://www.auscert.org.au/5820#E.2.5https://www.auscert.org.au/5822#E.2.5https://www.auscert.org.au/5819#E.2.5https://www.auscert.org.au/5820#E.2.5https://www.auscert.org.au/5822#E.2.5


17/59

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 hashesare not world readable. This prevents simple dictionary and bruteforce attacks being applied to get the passwords from the hashes.

Enable password shadowing if it is not on by default. See OS specificfootnotes 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 isnot 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 AusCERTAdvisory 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 configurerequirements on password complexity, such as minimum passwordlengths, requirements for numbers and symbols, etc.

For PAM systems this can be done by a PAM module. If your PAMenabled system does not have such a module, you can use thepam_passwdqc module available fromhttp://www.openwall.com/passwdqc/ which supports Linux, Solaris,FreeBSD and HP-UX.

For a multi-user system which does not have any mechanism forenforcing difficult passwords, password auditing is discussed insection J.7.3

HP-UX AIX

E.3.1.6 Password ageing and password history
https://www.auscert.org.au/5819#E.3.1.2https://www.auscert.org.au/5822#E.3.1.2https://www.auscert.org.au/5823#E.3.1.2https://www.auscert.org.au/5817#E.3.1.3http://www.auscert.org.au/1832http://www.openwall.com/passwdqc/https://www.auscert.org.au/5819#E.3.1.5https://www.auscert.org.au/5822#E.3.1.5https://www.auscert.org.au/5819#E.3.1.2https://www.auscert.org.au/5822#E.3.1.2https://www.auscert.org.au/5823#E.3.1.2https://www.auscert.org.au/5817#E.3.1.3http://www.auscert.org.au/1832http://www.openwall.com/passwdqc/https://www.auscert.org.au/5819#E.3.1.5https://www.auscert.org.au/5822#E.3.1.5


18/59

Consider enforcing password aging, so that users will need tochange 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 passwordsdown. 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 donot rapidly cycle through passwords to get around thehistory/ageing restrictions.

HP-UX

E.3.2 One-time passwords

Evaluate the use of one-time passwords for remote connections. Incertain situations this mechanism can be more secure than publickey authentication or reusable passwords.

For example, a malicious trojan on a client machine can easilycapture passwords, secret keys and their passphrases to obtainongoing remote access to an account. In contrast, where one-timepasswords are used a trojan would have to hijack a legitimatesession, and the attacker will then have to go to more trouble tomaintain ongoing access to the compromised account.

Notes if using one-time passwords:

Generate the master key or password lists while logged on atthe 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 givento each user at any one time.

OPIE is a commonly used free implementation, available athttp://inner.net/opiePAM modules implementing one-time passwords are also available.

E.3.3 PAM Pluggable Authentication Modules

On many UNIX systems, PAM is the main framework forauthentication, and will be operational by default.
https://www.auscert.org.au/5819#E.3.1.6http://inner.net/opiehttps://www.auscert.org.au/5819#E.3.1.6http://inner.net/opie


19/59

PAM is provided by default on Linux, FreeBSD, Solaris, HP-UX andAIX.

To find out if a given executable uses PAM, execute the command

ldd . For example, the resulting outputfor /usr/bin/login on a FreeBSD 6.x system:

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

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

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

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

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

Consider enforcing user resource limits with PAM: This may be doneusing 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. Itis for this reason and others that NIS was superceded by the moresecure NIS+.

Use LDAP instead to achieve the same goal of centralized directoryservices. If only authentication is required, then Kerberos can be

considered as another alternative.
https://www.auscert.org.au/5817#E.3.3https://www.auscert.org.au/5818#E.3.3https://www.auscert.org.au/5821#E.3.3https://www.auscert.org.au/5817#E.3.3https://www.auscert.org.au/5818#E.3.3https://www.auscert.org.au/5821#E.3.3


20/59


21/59

Ensure that the files holding the kernel and any kernel modules areowned by root, have group ownership set to group id 0 andpermissions that prevent them being written to by any non-rootusers.

Ensure that there are no unexpected world writable files ordirectories on your system. Use the find command to locate these,for examplefind / -type d -perm +2 -ls will locate world writable directories.

Ensure the sticky-bit is set on /tmp, /var/tmp and any other world-writable directories that exist. This is often denoted by a "t" in thelast column of permissions when listing with ls -ld

Make a list of the non-root-owned directories outside of the userhome area, usingfind / -path /home -prune -o -type d ! -uid 0 -lsand ensure that there is nothing unexpected. In particular /etc,/usr/etc, /bin, /usr/bin, /sbin, /usr/sbin, /tmp and /var/tmp should allbe owned by root.

Some systems ship files and directories owned by user "bin" (or"sys"). This varies from system to system and may have securityimplications, especially if filesystems are exported with NFS. Changeall non-setuid files and all non-setgid files and directories owned by"bin" that are world readable but not world or group writable to beowned 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 bewritable 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.

o as well as all parent directories of these programs.
https://www.auscert.org.au/5818#E.4.1.1https://www.auscert.org.au/5818#E.4.1.1


22/59

Ensure that root's PATH is secure, as described in section E.2.4.

Ensure root's login files do not source any other files not owned byroot or which are group or world writable.

Ensure root cron job files do not source any other files not owned byroot or which are group or world writable.

Check the contents of the following files for the root account. Anyprograms or scripts referenced in these files should have thepermissions recommended above:

~/.login, ~/.profile, ~/.bashrc, ~/.cshrc and similar shellinitialization 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 orscripts 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 orserver accounts.

Any predictably named files created by scripts, daemons, serverprocesses, or cron jobs MUST be in a directory that is non-writableby less privileged users and groups. This includes directories usedfor logging.

Otherwise, a symlink attack may be used to escalate privileges fromunprivileged user to a more privileged one, such as root.

Scripts and programs that need to create files in a directory writableby others, such as /tmp, must take special precautions to create thefile atomically. If your organisation's system administration scriptsneed to use temporary files, refer to the Secure Programming for

Linux and Unix HOWTO for a discussion on doing this securely inshell scripts, Perl and C.
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html#TEMPORARY-FILEShttp://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html#TEMPORARY-FILEShttp://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html#TEMPORARY-FILEShttp://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html#TEMPORARY-FILES


23/59

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 schemeIn 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 schemeIn this scheme a separate group is created in /etc/groups for eachuser. The user should be the only member of that group. Thisscheme makes working on group projects easier, as users do notneed to use the umask command when working in a commonproject directory. This is the default on FreeBSD, Red Hat, Debian, ...

Do not use the legacy feature of password protected groups. It isinsecure because the /etc/group file is not shadowed, so hashes areworld readable.

HP-UX

E.4.1.5 umask for users

A user's umask determines the default permissions on new filescreated by the user. Note that unlike file permissions, the umaskshows which permission bits are not allowed, e.g. a umask of 777means no access.

Ensure the umask for each user is set to a restrictive value withinthe user's shell startup scripts. The appropriate umask will depend

on whether a User Private Group scheme is used. If the traditionalgroup scheme is being used, ensure a umask of 077 or 027 is set inthe users' shell startup scripts.

A weaker umask of 007 is acceptable if the User Private Groupscheme 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.
https://www.auscert.org.au/5819#E.4.1.4https://www.auscert.org.au/5819#E.4.1.4


24/59

If the traditional group scheme is in use, the group ownership onhome directories may be set to the common group, so ensure thatthe directory is not group-writable.

If the User Private Group scheme is in use, the group ownership onhome directories should be set to the user's private group.

For either scheme, consider setting permissions on home directoriesto 700 to prevent other people from viewing the contents by default.

E.4.2 Filesystem attributes

Consider using file attributes if your operating system supportsthem.

system binaries and key configuration files can be madeimmutable,

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 accountthat can control the whole machine if compromised.

In an environment with multiple system administrators, RBAC canalso give the ability to split administration powers among severalpeople if desired.

Linux , Solaris , HP-UX, AIX

E.4.4 sudo

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

For systems administered by more than one person, sudo can alsobe helpful to split the power of root to some extent if full Role BasedAccess Control is not available.
https://www.auscert.org.au/5817#E.4.2https://www.auscert.org.au/5820#E.4.2https://www.auscert.org.au/5817#E.4.3https://www.auscert.org.au/5818#E.4.3https://www.auscert.org.au/5819#E.4.3https://www.auscert.org.au/5822#E.4.3https://www.auscert.org.au/5817#E.4.2https://www.auscert.org.au/5820#E.4.2https://www.auscert.org.au/5817#E.4.3https://www.auscert.org.au/5818#E.4.3https://www.auscert.org.au/5819#E.4.3https://www.auscert.org.au/5822#E.4.3


25/59

sudo allows users or groups of users to execute specific authorizedcommands as another user, such as the root user. It requiresunprivileged users to enter their own user password in order toexecute privileged commands. This enables administrative tasks to

be distributed among different users, while limiting the distributionof the root password.

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

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

E.4.5 Consider mandatory access control features

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

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

Some operating systems offer mandatory access control anddata 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 thesetrusted operating system features if available. Note that some of these controls may impact software compatibility and usability, soenforcing these will not be useful to all organisations.


26/59

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

Linux

E.5 Other

E.5.1 Cron

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

Consider not allowing regular users to add cron jobs.

E.5.2 Mount options

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

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

For user home partitions, use nosuid and nodev and consider usingnoexec.

Mount external filesystems with the nosuid and nodev options. Thisincludes both removable media such as CDs and USB drives as wellas 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 foryour operating system. This makes buffer overflow bugs moredifficult for attackers to exploit.

Some implementations also provide non-execute protection forother memory regions such as the heap, or provide broaderprotection ensuring that memory regions are not both writable andexecutable.
https://www.auscert.org.au/5817#E.4.5https://www.auscert.org.au/5822#E.5.2https://www.auscert.org.au/5817#E.4.5https://www.auscert.org.au/5822#E.5.2


27/59

Solaris , HP-UX, AIX

E.5.4 Umask for startup scripts

Ensure that any startup scripts use a umask of 022 or better. Thisshould 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 transfersand 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 thesystem, so that if the software misbehaves or is compromised thedamage is limited. The facilities available to do this vary on differentUNIX systems.

F.1.1 Running under an unprivileged account

Ensure that services run under unprivileged accounts wherepossible.

Many services do this automatically, however some will run as rootby 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 thereal filesystem and it appears to that process to be the root
https://www.auscert.org.au/5818#E.5.3https://www.auscert.org.au/5819#E.5.3https://www.auscert.org.au/5822#E.5.3https://www.auscert.org.au/5817#Ehttps://www.auscert.org.au/5818#Ehttps://www.auscert.org.au/5819#Ehttps://www.auscert.org.au/5820#Ehttps://www.auscert.org.au/5821#Ehttps://www.auscert.org.au/5822#Ehttps://www.auscert.org.au/5818#E.5.3https://www.auscert.org.au/5819#E.5.3https://www.auscert.org.au/5822#E.5.3https://www.auscert.org.au/5817#Ehttps://www.auscert.org.au/5818#Ehttps://www.auscert.org.au/5819#Ehttps://www.auscert.org.au/5820#Ehttps://www.auscert.org.au/5821#Ehttps://www.auscert.org.au/5822#E


28/59

directory. Any libraries that the daemon requires will also need to beput 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 chrootthemselves to a specified directory after starting, which is moreconvenient than manually using the chroot command in a startupscript.

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

F.1.3 Other confinement mechanisms

Several operating systems provide their own more advancedmechanisms for confining processes. See the OS specific footnotesfor details on Solaris Containers and privileges, FreeBSD jails and SELinux Type Enforcement.

Linux , Solaris , FreeBSD

F.2 tcp_wrappers

The primary way to restrict accesses to the host's services by IPaddress is to use a host firewall, discussed in section H.1. However,many UNIX and Linux systems also provide a second control, in theform of tcp_wrappers. This may already be in use on your system bydefault.

tcp_wrappers does provide some extra flexibility if needed; it can beconfigured to require reverse DNS lookups or ident (RFC931)lookups, allows automatic execution of scripts when conditions aremet, and can also provide improved logging for services that do nothave 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 theprogram tcpd to accept connections which are then passed to

the actual network service.
https://www.auscert.org.au/5817#F.1.3https://www.auscert.org.au/5818#F.1.3https://www.auscert.org.au/5820#F.1.3https://www.auscert.org.au/5817#F.1.3https://www.auscert.org.au/5818#F.1.3https://www.auscert.org.au/5820#F.1.3


29/59

More commonly though, the vendor has already compilednetwork services to use the libwrap library. In this case therelevant daemon will enforce the tcp_wrappers restrictionswhen accepting connections.

The main configuration file for tcp_wrappers is /etc/hosts.allowExplicitly list host IPs which are allowed access to the services in thisfile. At the bottom of the file put all:all:deny to deny all other IPaddresses. 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 longerrequired.If /etc/hosts.deny is present, put all:all in this file.

HP-UX

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 networkinterface, configure them to listen on only one specific IP addresswhere possible.

If the service is only required for use on the local host, then it shouldlisten only on the loopback interface where possible, with address127.0.0.1

F.3.2 Adding SSL to existing services

If this UNIX or Linux system provides services that involve sensitivedata, but the built-in encryption or authentication of the software isinadequate, 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 andserver that uses TCP. For example, it can be used to secure accessto POP3, or to secure an existing in-house application thatcommunicates using TCP.

If required, client access to the wrapped service can also beauthenticated using client-side certificates.
https://www.auscert.org.au/5819#F.2https://www.auscert.org.au/5819#F.2


30/59

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

F.4 SSH

Do not log in via SSH from an insecure workstation. Contrary topopular belief, public key cryptography will not protect you in doingthis. Where SSH is used, a trust relationship is implied - the SSHserver computer trusts the security of the SSH client computer.

Be aware that when doing X-forwarding through SSH, the trustrelationship is also reversed - the workstation running the X displaymust also trust the computer running each X program. This is due tothe cross-client X attacks described below in F.9.3

Suggested configuration options for the OpenSSH sshdimplementation:

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 noListen 222 (consider using an alternate port)PermitEmptyPasswords noAllowUsers one two@host1 three

Disable other authentication options. In particular, do not use:

RhostsAuthenticationHostBasedAuthenticationRhostsRSAAuthentication (not good for accountability)

Where SSH is used by scripts, configure SSH on the server side toallow execution of a certain single command only. This is achievedusing a command= directive in the authorized_keys file.

Many UNIX and Linux systems are compromised by attackersthrough SSH, by simply using a dictionary attack on passwords.It is strongly recommended to use public key authentication insteadof passwords. If password authentication must be used with SSH,verify that a strong password policy is in effect, as described in

E.3.1.
http://www.stunnel.org/http://www.stunnel.org/


31/59

F.5 Printing

There are several different default printing systems supplied with

UNIX and Linux systems. The three most common of these are BSDstyle lpr (also found on AIX), LPRng and CUPS.

In general, prevent the printing service from listening to the networkunless necessary for this computer's role.

If a network printing service is part of this computer's role, then donot rely solely on IP addresses for authentication (for instance thehosts.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 forsecuring RPC access with authentication and/or encryption. Thesecurity features available vary greatly between UNIX variants.

Be aware that some older portmapper/rpcbind daemons mayforward RPC requests from remote hosts, and make them appear tocome 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 thelocal subnet from accessing file systems exported by this host.

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

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

Consider tunnelling NFS over SSH or stunnel to provideauthentication and encryption.


32/59

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 NFSimplementations, and may be set by the 'secure' option on exportsin others.

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

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

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

Check that any important exported files that clients should not beable to modify are owned by root, and not owned by bin or anyother 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 toaccess the server as root.

Confirm that no file systems are exported unintentionally to theworld. Invoke showmount -e to verify what is currently being

exported. If required, add -access=192.168.50.3 option orequivalent in /etc/exports to restrict access by IP. If you must specifyhostnames instead of IPs, then export to fully qualified domainnames only (i.e. use 'machinename.domainname.com' rather thanabbreviating it to 'machinename').

Solaris

F.7.2 Samba

The Samba service provides filesystem and printer shares using theCIFS protocol that is also used in Microsoft Windows.
https://www.auscert.org.au/5818#F.7.1https://www.auscert.org.au/5818#F.7.1


33/59

If users in your environment authenticate to Active Directory forother services, then consider pointing to the same AD server forSamba authentication, settingsecurity = ADS

See the Samba HOWTO for further details on implementing this:HOWTO

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

Require at least NTLM2 authentication as a bare minimum, withlanman auth = nontlm auth = norestrict anonymous = 2guest ok = no

Consider using stronger client authentication methods. Sambasupports better authentication through Kerberos or PluggableAuthentication 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 notbe accessed from hosts outside the local network. Samba uses ports137 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 helpsto prevent your mail server from being misused to send bulk spam. The open relay testing page at http://www.abuse.net/relay.html canassist in testing this.

F.8.1 Sendmail

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

other MTAs.
http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/domain-member.html#ads-memberhttp://www.abuse.net/relay.htmlhttp://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/domain-member.html#ads-memberhttp://www.abuse.net/relay.html


34/59

If this computer is not a mail server, then:

Disable SMTP connections from other computers by addingAddr=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 removingthe -bd option from the startup script. This will still allow mostlocal Mail User Agents to invoke the sendmail binary to sendmail. In this case, do use a -q30m option to ensure queuedoutbound messages are still processed.

If this IS a mail server, then:

Ensure familiarity with Sendmail access control and anti-spamcontrol features. Seehttp://www.sendmail.org/m4/anti_spam.html for an overview.

If it is really necessary to relay mail from roaming usersoutside your local address range, then configure Sendmail torequire 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 withMODIFY_MAILER_FLAGS(`LOCAL', `-|')

If you do require piping email to programs, use smrsh to limitthe programs that can be executed to only those programs

linked in the smrsh configuration directory. This can be turnedon with
http://www.sendmail.org/m4/anti_spam.htmlhttp://www.sendmail.org/m4/anti_spam.html


35/59

FEATURE(`smrsh', `/usr/libexec/smrsh')(The location of the smrsh binary may vary on differentsystems.)

Consider setting sendmail logging to a minimum log level of 10.

This will help detect attempted exploitation of sendmailvulnerabilities as well as logging each connection and theusername used in each SMTP AUTH. To do this use:define (`confLOG_LEVEL', 10')

/etc/mail/aliasescheck that any programs executed from this file are owned byroot, have permissions 755 and are stored in the smrshconfiguration directory, e.g. /etc/smrsh

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

F.8.2 Mail server MTA choices

Sendmail is the most fully featured MTA software. On the other handit is also a large and complex program. The complexity leaves morescope for security vulnerabilities through misconfiguration orsoftware flaws.

If this computer accepts email from other systems, and Sendmail'sextra functionality is not required, then consider the benefits andcosts of using an alternative to Sendmail with a more simple and

privilege-separated design.qmail is a replacement for sendmail designed with security andcorrectness as a primary goal, but implementing a more limited setof features. It is available at: http://cr.yp.to/qmail.html

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

F.9 The X Window System
http://cr.yp.to/qmail.htmlhttp://www.postfix.org/http://cr.yp.to/qmail.htmlhttp://www.postfix.org/


36/59


37/59

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

xdm may bypass the normal getty and login functions, which meansthat quotas for the user, ownership of /dev/console and possiblyother preventive measures put in place by you may be ignored.

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

Ensure familiarity with the man pages for xauth and Xsecurity. Thisinformation will be useful in configuring the security you require.

The chapter on X Window System security in the X Window SystemAdministrator'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 nameserver software provided.

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

Consider applying the security practices detailed in the followingdocuments:

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

Securing an Internet Name Server By Cricket Liuhttp://www.linuxsecurity.com/resource_files/server_security/securing

_an_internet_name_server.pdf

Chroot-BIND HOWTO By Scott Wunschhttp://www.losurs.org/docs/howto/Chroot-BIND.html for BIND version9.x or http://www.losurs.org/docs/howto/Chroot-BIND8.html for BINDversion 8.x.

F.10.2 DNS server choices
http://www.auscert.org.au/5816#ref2http://www.auscert.org.au/5816#ref2http://www.cymru.com/Documents/secure-bind-template.htmlhttp://www.linuxsecurity.com/resource_files/server_security/securing_an_internet_name_server.pdfhttp://www.linuxsecurity.com/resource_files/server_security/securing_an_internet_name_server.pdfhttp://www.losurs.org/docs/howto/Chroot-BIND.htmlhttp://www.losurs.org/docs/howto/Chroot-BIND8.htmlhttp://www.auscert.org.au/5816#ref2http://www.auscert.org.au/5816#ref2http://www.cymru.com/Documents/secure-bind-template.htmlhttp://www.linuxsecurity.com/resource_files/server_security/securing_an_internet_name_server.pdfhttp://www.linuxsecurity.com/resource_files/server_security/securing_an_internet_name_server.pdfhttp://www.losurs.org/docs/howto/Chroot-BIND.htmlhttp://www.losurs.org/docs/howto/Chroot-BIND8.html


38/59

BIND is the DNS server software that provides the mostcomprehensive set of DNS features. On the other hand it is also alarge and complex piece of software. The complexity leaves morescope for security vulnerabilities through misconfiguration or

software flaws.

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

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

F.11 WWW service

F.11.1 General configuration

Apache is the most common web server on Unix systems. If you areusing Apache, implement the security recommendations outlined inhttp://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 bydefault. Example steps for chrooting Apache on Linux and Solariscan be found at http://penguin.triumf.ca/chroot.html . A simpler wayto chroot Apache is now provided by the mod_security'sSecChrootDir option, as described here .

Consider configuring the web server to disallow automatic directorylisting 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 treefrom making other documents, outside the tree, available viasymbolic links.

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

F.11.2 Web applications
http://cr.yp.to/djbdns.htmlhttp://httpd.apache.org/docs/misc/security_tips.htmlhttp://penguin.triumf.ca/chroot.htmlhttp://www.modsecurity.org/documentation/modsecurity-apache/1.9.3/html-multipage/06-special_features.html#N108DChttp://cr.yp.to/djbdns.htmlhttp://httpd.apache.org/docs/misc/security_tips.htmlhttp://penguin.triumf.ca/chroot.htmlhttp://www.modsecurity.org/documentation/modsecurity-apache/1.9.3/html-multipage/06-special_features.html#N108DC


39/59

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

If using ready-made web applications such as content managementsystems, portals or discussion forums, be careful in choosing highquality software and be especially vigilant in keeping these up todate. Known vulnerabilities in PHP web applications are some of themost common ways that UNIX and Linux web servers arecompromised.

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

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

For any web site developed in-house or by contract, ensure alldevelopers doing web programming understand the specific issuesof secure web programming. In particular the OWASP Guide toBuilding Secure Web Applications , available athttp://www.owasp.org/index.php/OWASP_Guide_Project isindispensible.

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 directoriescontaining scripts. The permissions required by differentapplications and frameworks vary. Preferably the unprivilegedaccount running the httpd should not have permission to write tothe script area.

F.11.3 TLS / SSL

Use TLS (Transport Layer Security) or its predecessor SSL (SecureSocket Layer) to provide authentication and encryption whereappropriate.

Confirm that sensitive form data is not submitted unencrypted.

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

SSL version 2.0 is insecure and should be disallowed.
http://www.owasp.org/index.php/OWASP_Guide_Projecthttp://www.owasp.org/index.php/OWASP_Top_Ten_Projecthttp://www.owasp.org/index.php/OWASP_Guide_Projecthttp://www.owasp.org/index.php/OWASP_Top_Ten_Project


40/59

For logon pages, it is recommended to use SSL not only for the formsubmission, but also for the logon page itself, as this makes it easierto instruct users not to submit their password to an unauthenticatedsite.

F.11.4 Static-only webserver

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

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

F.12 Squid proxy

Avoid providing an open proxyConfigure access controls so that only authorised clients can makerequests 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 unintendedaccess it is best to put a catch-all deny rule last:http_access deny all

Listen on a single interfaceIf this computer has more than one network interface, specify theinterface's IP address with a configuration line:http_port 192.168.0.7:8080to cause squid to only listen on that interface.

Disable unused protocolsIf you are not using the inter-cache and management protocols,then turn them off by setting the port to 0, as in the followingconfiguration lines:snmp_port 0htcp_port 0icp_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
http://cr.yp.to/publicfile.htmlhttp://cr.yp.to/publicfile.html


41/59

to the following:acl to_localhost dst 127.0.0.1/8deny to_localhost

Secure squid filesCheck that squid logs and cache files are not world readable. Thesecan 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 limittheir SSH session so it is only able execute the command "cvsserver".

Why this provides better security than cvs pserver:

1. cvs does not need to run as root2. Access control is enforced by the operating system, not by

cvs.

Be aware that CVS access control is per-directory, rather than per-file. (The CVS manual in section 2-2-2 describes the access controlmodel.)

Use LockDir in CVSROOT/config to have read only directories whereappropriate.

F.14 Web browsers

Do not allow external programs to spawn automatically for any typeof downloaded content. This includes not allowing browsers toautomatically launch multimedia viewers, shells, script interpretersor macro processors.

Instead configure the browser to prompt before opening externalprograms. This can be achieved using the helper applicationpreferences for the browser.

Consider disabling Java and JavaScript in the web browser.


42/59

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 publicaccess it is better to use a simple HTTP server such aspublicfile (see section F.11.4).

If authenticated access is required, it is better to use sftp. Ansftp server is included as part of OpenSSH, which is availableeither as packages from your OS vendor, or as source fromhttp://openssh.com/ . Several free graphical clients areavailable 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 21USER usernamePASS passwordSITE EXEC

If it is correctly disabled, you should receive an error response like500 '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 arenot

allowed to connect to your ftpd. This shouldinclude, 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 allversions of ftp daemons are configurable. If you have a configurableversion 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.
http://openssh.com/http://winscp.net/http://openssh.com/http://winscp.net/


43/59

Ensure there are no shells, interpreters or system commands in~ftp/bin, ~ftp/usr/bin, ~ftp/sbin or similar directories. It may benecessary to keep some commands, such as uncompress, in theselocations. Consider the inclusion of each command on a case by

case basis and be aware that the presence of such commands maymake it possible for local users to gain unauthorised access. Bewary of including commands that can execute arbitrary commands.For example, some versions of tar may allow you to execute anarbitrary file.

Ensure that you use an invalid password and user shell for the ftpentry in the system password file and the shadow password file (if you have one). It should look something like:ftp:*:400:400:Anonymousftp:/home/ftp:/bin/falsewhere /home/ftp is the anonymous FTP area.

Set the permissions of the FTP home directory ~ftp/ to 555 (readnowrite 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 fileas ~ftp/etc/passwd. Create one from scratch with permissions 444,

owned by root. It should not contain the names of any accounts inyour real password file. It should contain only root and ftp. Theseshould 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 mappingfor 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 suchas /bin/false.

Ensure no files or directories are owned by the ftp account or havethe same group as the ftp account. If they are, it may be possible for

an intruder to replace them with a trojan version.


44/59

Ensure no files or directories in the FTP area are world writable.

Ensure that the directories ~ftp/etc and ~ftp/bin are owned by rootwith permissions 111.

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

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 byroot 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 unlessthey are mounted read-only.

HP-UX

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 wellformed email address as the password.

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

Ensure that if you want to use anonymous FTP you have configuredyour server correctly. In general, anonymous users should not beallowed to create directories, delete anything, change the filesystem in any way (for instance change the permissions of a file) orupload 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 thenumber of times a single IP can be logged in at once. Anonymoususers 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 ordirectories in ANY directory unless required.
https://www.auscert.org.au/5819#F.15.1https://www.auscert.org.au/5819#F.15.1


45/59

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

F.15.3 Upload directories

Preferably, check that you do not have any writable directories asthis 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. Directoriesthat 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 willhelp to prevent denial of service through disk exhaustion.

G. Add Monitoring Capability

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

G.1 syslog configuration

Consider using syslog's remote logging feature to send logs to aseparate logging computer.Remote logging ensures that even if the UNIX system iscompromised, attackers cannot simply modify the log files to covertheir tracks.

Consider protecting the network logging stream with authenticationand encryption, for example by tunnelling it over SSH with netcat.

If logging over the network, do log to local files as well.

Unless this computer is a log server, ensure that syslog will not accept incoming log packets over the network. On some systemsthis is the default. On others it may be implemented by starting

syslog with the -t option (nolisten).


46/59

Consider increasing the level of logging provided by syslog.

Make sure that the messages of the LOG_AUTH facility at levelLOG_INFO and above get logged.

For email, enable a minimum level of "info" for mail messagesto be logged by syslog.

Check that there is a reliable mechanism for log rotation. If there isnot, you may need to replace an existing logging daemon with amore secure or full-featured one.

Check that all login attempts are logged, both successful andunsuccessful. There may be several different ways to log in, such asat 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 areactively monitoring them. Decide on a specific time period withinwhich people will monitor the logs.

Consider automatically emailing logs or log extracts to the internalemail addresses of the relevant people. Check that the sensitivity of information contained in the logs is appropriate to distribute thisway.

G.2.2 Automated log monitoring tools

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

Automating to some degree is highly recommended as otherwise itis unlikely that the human component of the log monitoring task will

actually be done.
https://www.auscert.org.au/5821#G.1https://www.auscert.org.au/5822#G.1https://www.auscert.org.au/5821#G.1https://www.auscert.org.au/5822#G.1


47/59

Two example programs are swatch and logsentry. Furtherinformation on log monitoring and available tools is available athttp://loganalysis.org

Ensure any automated reporting facilities provided by youroperating system are turned on, and are sending output to anappropriate 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

On many platforms a more comprehensive audit subsystem isoptionally available. The benefit is to allow more dependable andconfigurable logging of a wider range of security events.

Enable the trusted system audit features if available for yourplatform.

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 yourmachines - tools are available that make it possible to do thisremotely. 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 monitoringtools 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
http://loganalysis.org/https://www.auscert.org.au/5817#G.3https://www.auscert.org.au/5818#G.3https://www.auscert.org.au/5819#G.3https://www.auscert.org.au/5822#G.3http://argus.tcp4me.com/http://www.bb4.org/http://www.nagios.org/http://loganalysis.org/https://www.auscert.org.au/5817#G.3https://www.auscert.org.au/5818#G.3https://www.auscert.org.au/5819#G.3https://www.auscert.org.au/5822#G.3http://argus.tcp4me.com/http://www.bb4.org/http://www.nagios.org/


48/59


49/59

AIX, Solaris

G.5.2 Antivirus / malware detection

Antivirus products that run on UNIX systems are often aimed atdetecting Windows malware that passes through a UNIX email or fileserver. However several companies also produce antivirus softwarespecifically targeting known UNIX malware.

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

Depending on the operating system, free tools may also be

available to check for known trojaned binaries or malicious kernelmodules that may be installed by an attacker after compromisingthe system. The chkrootkit tools available from www.chkrootkit.org are able to detect some of the most common rootkits. Chkrootkitruns 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 intrusiondetection system, aimed at detecting attempted and successfulnetwork attacks.

Snort is one open source network IDS which performs real-timetraffic analysis and packet logging. It can use protocol analysis andcontent 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 protocolanalyser in promiscuous mode on the server itself. Instead use aseparate computer/device. This protects your server and networkfrom vulnerabilities in the IDS software itself.

Consider connecting the IDS to the network to be monitored via aread-only network tap or a spanning port on the switch.
https://www.auscert.org.au/5822#G.5.1https://www.auscert.org.au/5818#G.5.1http://www.chkrootkit.org/https://www.auscert.org.au/5819#G.5http://www.snort.org/https://www.auscert.org.au/5822#G.5.1https://www.auscert.org.au/5818#G.5.1http://www.chkrootkit.org/https://www.auscert.org.au/5819#G.5http://www.snort.org/


50/59


51/59

computer is compromised, this can make it more difficult for (theless sophisticated) malicious software to connect back out to anattacker to receive instructions.

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

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

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 verifythat the firewall rules correctly handle IPv6 packets coming from thelocal LAN. Some firewall configurations ignore IPv6. Even on an IPv4network this may give unintended access if the attacker alreadycontrols another point on the LAN.

Packet filtering can be difficult to implement correctly. For moreinformation on firewalls and packet filtering, the following referencesmay be of use:

Internet Firewalls FAQhttp://www.interhack.net/pubs/fwfaq/

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 networkinterface, even if a service only binds to the IP address of oneinterface, this will not protect it from packets that are received on adifferent interface but addressed to that IP.

This is particularly important where second network cards are usedto provide a separate management network.
http://www.interhack.net/pubs/fwfaq/http://www.auscert.org.au/5816#ref5http://www.interhack.net/pubs/fwfaq/http://www.auscert.org.au/5816#ref5


52/59


53/59


54/59


55/59

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

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

It is usually important to determine how the attacker broke in, sinceif you clean and restore the system without knowing this then theattacker 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 lawenforcement involvement is desired, then it is recommended toleave the disk imaging to law enforcement, and to avoid altering thesystem in any way before this is done.

In other cases, consider having the capability to make a forensicallysound image of an affected hard disk, using dd or similar tools on asecond, clean system. This will require having spare hard disksavailable 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 inthe document Collecting Electronic Evidence After a SystemCompromise

Autopsy is one free forensic filesystem analysis tool for UNIXsystems. It may be used to examine images of storage devices froma compromised system, and generate a timeline of recent fileaccess.

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

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

Solaris

I.5.3 Malware detection tools
http://www.auscert.org.au/1974http://www.auscert.org.au/2247http://www.auscert.org.au/2247http://www.sleuthkit.org/autopsy/desc.phphttps://www.auscert.org.au/5818#I.5.2http://www.auscert.org.au/1974http://www.auscert.org.au/2247http://www.auscert.org.au/2247http://www.sleuthkit.org/autopsy/desc.phphttps://www.auscert.org.au/5818#I.5.2


56/59

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

J. Maintain

J.1 Mailing lists

Notifications of patch releases and security updates are generallydone via mailing lists.

Subscribe to the vendor "announce" list as well as any securitymailing lists for your specific operating system.

Subscribe to the appropriate security/updates mailing list for eachthird party software package installed.

Also subscribe to security advisory mailing lists from your localincident response team (if you have one available).

AusCERT Security Bulletins are available athttp://www.auscert.org.au/1

US-CERT Vulnerability Notes are available athttp://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 pieceof third party software.

This is significant, as when a vulnerability advisory is released, it iseasy to check whether the versions on your systems are affected.

J.3 Rapid patching

The window of time between vulnerabilities being publiclyannounced and widespread exploitation is now very short. Design
http://www.auscert.org.au/1http://www.kb.cert.org/vuls/http://www.auscert.org.au/1http://www.kb.cert.org/vuls/


57/59

your patching and update process aiming to allow critical patches tobe 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-enableservices that you have disabled.

J.4 Secure administrative access

J.4.1 Strongly authenticated access only