AusCERT - AusCERT UNIX and Linux Security Checklist v3

AusCERT - AusCERT UNIX and Linux Security Checklist v3.
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
auscert@auscert.org.au.
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
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
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
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
(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
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
FreeBSD,
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
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
Debian,
Solaris
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
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
/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
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
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 <path
to executable file>. For example, the resulting output for /usr/bin/login
on a FreeBSD 6.x system:
% ldd /usr/bin/login
/usr/bin/login:
libutil.so.5 => /lib/libutil.so.5 (0x28077000)
libpam.so.3 => /usr/lib/libpam.so.3 (0x28083000)
13 of 41
27-05-2013 09:32 PM
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
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
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
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
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
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
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
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
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
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
24 of 41
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
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
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
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
28 of 41
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
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
~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
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
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
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
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
Monitoring - general notes:
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
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
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
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
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
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
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
Building Internet Firewalls, Second Edition
Elizabeth D. Zwicky, Simon Cooper, and D. Brent Chapman
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

AusCERT - AusCERT UNIX and Linux Security Checklist v3

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

AusCERT - AusCERT UNIX and Linux Security Checklist v3

Încărcat de

Drepturi de autor:

Formate disponibile

AusCERT - AusCERT UNIX and Linux Security Checklist v3.

AusCERT UNIX and Linux Security Checklist v3.0

UNIX and Linux Security Checklist

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

A. Determine Appropriate Security

A.1 Computer role

A.2 Assess security needs of each kind of data handled

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

A.3 Trust relationships

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

A.4 Uptime requirements and impact if these are not met

A.5 Determine minimal software packages required for role

A.6 Determine minimal net access required for role

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

(MD5/SHA1/other) or detached PGP signature. An example command to check the

B.2 Install while not connected to the Internet

B.3 Use separate partitions

B.4 Install minimal software

Installation - general notes:

Solaris, HP-UX, AIX

C. Apply all Patches and Updates

C.1 Initially apply patches while offline

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

C.2 Verify integrity of all patches and updates

Red Hat / Fedora,

C.3 Subscribe to mailing lists to keep up to date

Patching - general notes:

D.1 Minimise network services

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

D.1.2 Minimise inetd/xinetd

D.1.3 Minimise portmapper and RPC services

D.1.4 Notes on particular network services

Remove or disable fingerd

Remove or disable tftpd

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

required for the system's role.

Disable SNMP daemon

D.2 Disable all unnecessary startup scripts

D.3 Minimise SetUID/SetGID programs

Preferably uninstall them if not needed

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

D.4 Other minimisation

Minimise - general notes:

Solaris, HP-UX, AIX

E.2 User Logons

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

accounts can not occur.

E.2.2 Special accounts

E.2.3 Root account

E.2.3.2 No direct root logins

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

/etc/default/login, /etc/security or /etc/securetty depending

E.2.4 PATH advice

E.2.5 User session controls

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

For csh: set -r autologout=15 (15 minutes)

E.3.1.2 Shadow passwords

E.3.1.3 Ensure all accounts have passwords or are

E.3.1.4 Password Policy

E.3.1.5 Enforce password complexity

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0

E.3.1.6 Password ageing and password history

E.3.2 One-time passwords

E.3.3 PAM Pluggable Authentication Modules