auscert - auscert unix and linux security checklist v3

AusCERT UNIX and Linux Security Checklist v3.0Date: 13 February 2007

Original URL: http://www.auscert.org.au/render.html?cid=1937&it=5816

UNIX and Linux Security Checklist

v3.0AusCERT public release 2007-07-25

Introduction

This document has been published by the Australian Computer Emergency Response Team

(AusCERT). It provides a checklist of steps to improve the security of UNIX and Linux

systems. We encourage system administrators to review all sections of this document and if

appropriate modify their systems to fix potential weaknesses.

The checklist is structured to follow the lifecycle of a system, from planning and installation

to recovery and maintenance. Sections A to G of the checklist are best applied to a system

before it is connected to the network for the first time. In addition, the checklist can be

reapplied on a regular basis, to audit conformance.

No two organisations are the same, so in applying the checklist consideration should be

given to the appropriateness of each action to your particular situation. Rather than

enforcing a single configuration, this checklist will identify the specific choices and possible

security controls that should be considered at each stage.

Operating system specific footnotes throughout the document offer some additional

information to help with applying these steps on specific UNIX and Linux variants.

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

We will continue to update this checklist. Any comments should be directed via email to

[email protected].

Before using this document, please ensure you have the latest version. New versions of this

checklist will be available via the URL listed above and should be checked for periodically.

Disclaimer

AusCERT advises that this information is provided without warranty - sites should ensure

that actions and procedures taken from information in this document are verified and in

accordance with security policies that are in place within their organisation. Listing of

software products or tools within this document does not constitute endorsement by

AusCERT or The University of Queensland.

Contents

A. Determine Appropriate Security

B. Installation

C. Patch and Update

D. Minimise

AusCERT - AusCERT UNIX and Linux Security Checklist v3.0 http://www.auscert.org.au/render.html?it=5816&template=1

1 of 41 27-05-2013 09:32 PM

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:

from a CD containing the patches, or1.

on a trusted staging network disconnected from the Internet.2.

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 find / -perm

+6000 -ls

Preferably uninstall them if not needed

Otherwise disable the SUID or SGID bit, so that the program is only given the

privileges of the user running it. Note that in 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:

For accountability. This is particularly important if there is more

than one person who logs on to this computer.

1.

It also makes an attacker do more work to get to root.2.

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 aredisabled.

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 world-

writable 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, usingfind / -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, Solaris, HP-UX, AIX


17 of 41 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, settingsecurity = ADS

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

Otherwise, configure your shares for user-level security using thesecurity = user

parameter. In current versions of Samba this is the default.

Require at least NTLM2 authentication as a bare minimum, withlanman 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

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 withFEATURE(`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.


24 of 41 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 lineDisplayManager*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

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:

cvs does not need to run as root1.

Access control is enforced by the operating system, not by cvs.2.


28 of 41 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 like500 'SITE EXEC' command not understood

Then type QUIT to end the session.

Ensure that you have set up the file /etc/ftpusers. This file specifies those

users that 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:

Turn off weak ES behaviour (see OS specific footnotes) or,1.

add explicit host firewall rules to block packets coming into one

interface but addressed to the IP address of another interface.

2.

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