AusCERT - AusCERT UNIX and Linux Security = Checklist v3.0

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

Introduction

This document has been published by = the=20 Australian Computer Emergency Response = Team=20 (AusCERT). It provides a checklist of = steps to=20 improve the security of UNIX and Linux = systems.=20 We encourage system administrators to = review all=20 sections of this document and if = appropriate=20 modify their systems to fix potential=20 weaknesses.

The checklist is structured to follow = the=20 lifecycle of a system, from planning and = installation to recovery and = maintenance.=20 Sections A to G of the checklist are = best=20 applied to a system before it is = connected to=20 the network for the first time. In = addition, the=20 checklist can be reapplied on a regular = basis,=20 to audit conformance.

No two organisations are the same, so = in=20 applying the checklist consideration = should be=20 given to the appropriateness of each = action to=20 your particular situation. Rather than = enforcing=20 a single configuration, this checklist = will=20 identify the specific choices and = possible=20 security controls that should be = considered at=20 each stage.

Operating system specific footnotes=20 throughout the document offer some = additional=20 information to help with applying these = steps on=20 specific UNIX and Linux variants.

The most current version of this = document is=20 available at http://www.auscert.org.au/1935
We=20 will continue to update this checklist. = Any=20 comments should be directed via email to = auscert@auscert.org.au.

Before using this document, please = ensure you=20 have the latest version. New versions of = this=20 checklist will be available via the URL = listed=20 above and should be checked for=20 periodically.

Disclaimer
AusCERT=20 advises that this information is = provided=20 without warranty - sites should ensure = that=20 actions and procedures taken from = information in=20 this document are verified and in = accordance=20 with security policies that are in place = within=20 their organisation. Listing of software = products=20 or tools within this document does not=20 constitute endorsement by AusCERT or The = University of Queensland.

References

A. Determine Appropriate = Security

Apply your organisation's information = security policy to guide the decisions = made in=20 this section.

A.1 Computer role

First decide on and document the role = of this=20 computer. This means specifying exactly = which=20 services the computer will provide.

Example computer roles are:=20

email server and email = virus/spam=20 scanner=20
user workstation for = word=20 processing, email and web browsing=20
combined web server / = database=20 server

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

The security measures appropriate for = this=20 computer will depend greatly on what = information=20 will be stored on it, or pass through = it.

For Internet connected computers, = even for=20 unimportant data, a certain baseline = level of=20 security will be required, to stop this = computer=20 being used as a platform to attack = further into=20 the network or other external networks. =

The following steps will help to = determine=20 the security needs of this system:

1. Data on = this system=20

Considering the computer role, = identify each=20 kind of information that will be handled = by this=20 computer. Examples are:=20

office emails=20
client personal data=20
private keys and = certificates=20
source code being = developed=20 in-house

The list should also = identify=20 information such as user passwords, = which may be=20 typed into this computer but which also = give=20 access to other systems that use the = same=20 password.

2. Threats=20

Consider the potential threats to = each kind=20 of information identified above. Which = classes=20 of attacker will be motivated to read, = modify or=20 disable each of these kinds of data?

Consideration of the threat should = include=20 both targeted and indiscriminate = attacks.

Targeted = attacks:
Targeted=20 attacks refer to those where attackers = may=20 specifically target your business or = your=20 customers. Depending on the kind of = information=20 processed, threats may include malicious = changes=20 by a disgruntled insider, a denial of = service=20 attack for the purpose of extortion, or=20 industrial espionage or sabotage.

Indiscriminate = attacks:
All=20 computers on the Internet are subject to = these=20 threats. Some organisations believe that = their=20 systems will not be of interest to = attackers;=20 this is incorrect. Attackers are = interested in=20 controlling your computers for a number = of=20 reasons, including to launch attacks on = other=20 organisations, to send spam, or to = capture=20 users' authentication = credentials.

3.=20 Impacts if threats are realised =

For each of the threat scenarios, = estimate=20 the impact on your organisation if the = attack is=20 realised.
The cost may be measured in = money /=20 time / reputation

4. = Determine=20 acceptable risk=20

Based on the potential impacts, = determine=20 what level of risk can be accepted. Such = determination of risk acceptance levels = should=20 be done in conjunction with senior=20 management.

Making explicit the threats and = impacts in=20 this way will highlight what the = priorities=20 should be for protecting each kind of=20 information on the system.

For organisations with little = dependence on=20 IT and no critical data these steps can = be done=20 informally. Otherwise, consider doing = the=20 assessment in writing, integrated with = the risk=20 assessment for the overall network.

More formal risk management = frameworks are=20 available to assist with this, such as = OCTAVE=20 (http://www.cert.org/octave/).In=20 the Australian context, guidelines for=20 information security risk management are = provided by HB 231:2004, available = from=20 Standards Australia.

A.3 Trust = relationships

Identifying trust relationships will=20 determine whether the security of this = computer=20 is appropriate relative to other = computers. For=20 example, a secure configuration is = useless if a=20 UNIX server is managed from day to day = using a=20 workstation controlled by an = attacker.

Below are three questions to ask to = determine=20 the trust relationships:

1. Which systems does this = computer=20 trust?
These will include = the=20 following:=20

Workstations used to = administer=20 this computer e.g. by SSH or web = interface;=20
Authentication servers = (e.g.=20 kerberos or LDAP servers);=20
Backup servers (e.g. = during a=20 restore).

Those systems must be made at least = as secure=20 as this computer.

2. Which computers trust = integrity of=20 data served up by this = computer?
For=20 example:=20

Authentication clients, = if this is=20 an authentication server;=20
Computers that may be = administered=20 from this computer;=20
Workstations, if this is = a file=20 server.

This computer must be made at least = as secure=20 as those systems.

3. Which computers trust this = computer to maintain confidentiality of=20 data?
These may include:=20

Peer VPN endpoints;=20
Database clients. =

This computer must be made at least = as secure=20 as those systems.

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

Consider how reliable this computer = is=20 expected to be, and what the impact will = be if=20 these uptime requirements are not = met.

This can include issues such as the=20 following:=20

Will work in the = organisation be=20 affected if this computer fails?=20
Are specific service = levels=20 required by contract?=20
Will business be lost if = customers=20 cannot access a web site?

These uptime requirements will also = influence=20 the Backup/Rebuild Strategy chosen later = in=20 section I.

A.5 Determine minimal = software=20 packages required for role

From the role determined in A.1, = document=20 which programs are needed to fully = implement=20 this role. This includes any extra = libraries or=20 support software that the main software=20 needs.

Later in this checklist, installed = software=20 will be minimised to just the software=20 determined here.

A.6 Determine minimal = net access=20 required for role

Document which TCP and UDP port = numbers this=20 computer will need to communicate on to = perform=20 its role, including the direction (in or = outbound).

Where appropriate, also record which = specific=20 computers this one will be communicating = with=20 for each service.

Later in this checklist, network = access will=20 be restricted to only this required=20 access.

B. Installation

B.1 Install from trusted = media

If installing the operating system = from=20 downloaded ISO images, Use a trustworthy = computer to check the integrity of the = install=20 CDs after they are burnt, using a hash=20 (MD5/SHA1/other) or detached PGP = signature. An=20 example command to check the MD5 hash of = a CD=20 under Linux would be:
dd=20 if=3D/dev/cdrom bs=3D64k | = md5sum

If using MD5 or SHA1 hashes, make = sure that=20 the list of hashes itself comes from a = trusted=20 source (either digitally signed = (preferably) or=20 from a trusted SSL authenticated web=20 site).

B.2 Install while not = connected to=20 the Internet

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

B.3 Use separate = partitions

Creating separate partitions for = different=20 parts of the filesystem allows:

more flexibility in = applying=20 different mount options to different = parts of=20 the hierarchy, to restrict the use of = files (as=20 described below in E.5.2);=20
avoiding denial of = service by disk=20 space exhaustion (e.g. log files);=20
hard links are prevented = from=20 crossing partition boundaries. =

Use separate partitions for /, /usr, /var, /tmp = and /home. Good planning = of the=20 partition scheme is essential.

B.4 Install minimal = software

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

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

C. Apply all Patches and = Updates

Ensuring the latest patches and = updates are=20 applied is crucial to security as UNIX = systems=20 with unpatched public vulnerabilities = are=20 quickly compromised by attackers.

C.1 Initially apply = patches while=20 offline

After the first install, consider = applying=20 patches and updates while disconnected = from the=20 network, either:=20

from a CD containing the = patches,=20 or=20
on a trusted staging = network=20 disconnected from the = Internet.

If updating directly over the = Internet is=20 really necessary, then first install and = configure a restrictive host firewall = (see H.1)=20 on the new system, allowing only the = connections=20 required for updating. (Often DNS plus = one of=20 HTTP, HTTPS or SSH outbound is all that = is=20 required.) In this case, after the = initial=20 updating is complete, the host can then = be=20 disconnected from the network until the=20 remaining steps in sections D to H have = been=20 completed to bring the system to the = appropriate=20 level of security.

Do also patch and update any third = party=20 software installed.

C.2 Verify integrity of = all=20 patches and updates

Before installing any patches or = updates that=20 have been downloaded, check that they = have not=20 been modified.

On some systems, digital signatures = on=20 patches or updates may be verified = automatically=20 by the package tool.
Patches or updates for = some other=20 systems may be PGP signed. These = signatures can=20 be verified using GnuPG, available with = your=20 system or from http://www.gnupg.org/=20
If a digital signature is not = available but=20 an MD5 or SHA hash is, then use this to = verify=20 the integrity of the patch/update.

For those operating systems that do = not come=20 with an MD5 tool, a free implementation = is=20 available at http://www.fourmilab.ch/md5/

Red=20 Hat / Fedora, Solaris=20

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

Ensure that you are subscribed to the = "announce" and "security" mailing lists = for each=20 vendor of software that you use to = ensure that=20 you have rapid notification of future = patches=20 and security updates (see J.1).

If automatic update checks and/or = automatic=20 application of updates are available, = also=20 consider whether using this is = appropriate for=20 your situation.

Some other steps recommended to be = ready for=20 future patching are described in section = J=20 (Maintain).

Patching - general notes:=20 HP-UX=20

D. Minimise

After the initial installation is = complete,=20 minimise the amount of software that is = present=20 by uninstalling or disabling the = unneeded=20 software packages, leaving a minimal set = of=20 software. Ideally, only the software = that will=20 be used in performing the computer's = role, as=20 decided in A.1 above, should remain.

Check the dependencies between = software=20 packages to determine which libraries = and helper=20 software are also required for the = role.

D.1 Minimise network = services

D.1.1 Locate services = and remove=20 or disable

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

FreeBSD,=20 AIX=20

D.1.2 Minimise = inetd/xinetd

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

Solaris,=20 HP-UX=20

D.1.3 Minimise = portmapper and RPC=20 services

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

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

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

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

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

D.1.4 Notes on = particular network=20 services

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

Note the special case of rsync, which is not = one of the=20 traditional "r" commands. rsync is useful and = while by=20 default it provides authentication of=20 connections and transferred data, its = native=20 authentication is not strong so where = rsync is required it = is=20 recommended to run it over SSH.
Remove or disable=20 fingerd
Remove or disable = fingerd if=20 present. Apart from the possibility of a = software vulnerability, fingerd allows = an=20 attacker to enumerate usernames on the = system=20 and to determine the timing and = frequency of=20 system administrator logins.
Remove or disable=20 tftpd
Do not use tftpd = (trivial file=20 transfer protocol) unless = unavoidable.

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

Ensure that the files in the tftp = area are=20 not writable, unless this is required = for the=20 system's role.

TFTP is not authenticated, so to = protect=20 devices using TFTP, it is highly = recommended=20 only to allow it over a trusted network, = such as=20 a trusted management network for = configuring=20 network devices and not over the main = LAN.
Disable SNMP = daemon
If=20 present by default, disable any SNMP = daemon=20 unless this is really required for the = role of=20 the computer.

Solaris,=20 AIX=20

D.2 Disable all = unnecessary=20 startup scripts

The way startup scripts are used to = start=20 services when the system boots is = different on=20 different variants of UNIX. See your = vendor's=20 documentation for specific details.=20

On BSD style systems, the file rc.conf or rc.conf.local can be = edited to=20 change which services will be started. = Some=20 systems have further startup scripts = located in=20 /usr/local/etc/rc.d/

On System V style systems, the = services to be=20 started each have a script with an entry = under=20 /etc/init.d or = /etc/rc.d/init.d

Use ps at = this stage=20 to view the processes running by = default.=20 Understand the purpose of each process = and=20 disable it in the startup scripts if it = is not=20 needed.

Solaris,=20 AIX=20

D.3 Minimise = SetUID/SetGID=20 programs

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

Locate SetUID/SetGID = programs=20 using a command such as find / -perm +6000 = -ls=20
Preferably uninstall = them if not=20 needed=20
Otherwise disable the = SUID or SGID=20 bit, so that the program is only given = the=20 privileges of the user running it. Note = that in=20 some cases this can mean that the = program will=20 then only work when run by = root.

If SetUID/SetGID programs really need = to be=20 used by other users, then consider = restricting=20 who can run them by group membership:=20

create a new group for = this=20 program=20
change the group = ownership of the=20 binary to this new group=20
change the permissions = of the=20 binary to deny execute permission for = Others=20 (chmod o-rx)=20
add the users who must = use this=20 program to the new group.

Never allow SetUID shell = scripts.

Debian,=20 Solaris=20 OpenBSD=20

D.4 Other = minimisation

If a graphical user interface is not = required=20 on this computer then consider not = installing=20 the X window system, as well as desktop=20 environments such as CDE, Gnome and = KDE.

The reason is that these are large, = complex=20 software systems with components that = must run=20 with privileged access to the computer's = hardware.

If IPv6 is not being used, then = consider also=20 turning off the IPv6 stack.

OpenBSD=20

Minimise = - general=20 notes: Solaris,=20 HP-UX,=20 AIX=20

E. Secure Base = OS

E.1=20 Physical, console and boot security

Check that physical access to the = computer is=20 restricted appropriately. Regardless of = what=20 configuration is used, an attacker with = physical=20 access to the computer can in most cases = take=20 full control of the system.

That = said, the=20 following controls should be considered = to=20 increase the difficulty of the walk-in = attack:=20

Disable booting from any = removable=20 media by configuring the BIOS or EEPROM. =
Set a password to = prevent changes=20 to these BIOS or EEPROM settings.=20
Ensure the boot loader = does not=20 allow booting to single user mode = without a=20 password.=20
Consider disabling any = special=20 hotkeys that drop the console into a = debugging=20 mode.

For situations where access is = public, such=20 as an internet cafe or shared computer = lab,=20 these measures are essential. For other=20 situations these measures can be = considered=20 based on physical security.

Solaris,=20 HP-UX,=20 FreeBSD,=20 OpenBSD=20

E.2 User=20 Logons

E.2.1 Account = Administration

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

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

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

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

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

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

E.2.2 Special = accounts

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

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

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

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

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

IRIX=20

E.2.3 Root account

E.2.3.1 Root = password

Restrict the number of people who = know the=20 root password.

E.2.3.2 No direct root = logins

Consider not allowing root to = directly log in=20 over the network. Instead, require first = to log=20 on as an ordinary user, then use sudo or = else su=20 to root.

Reasons:

For accountability. This = is=20 particularly important if there is more = than one=20 person who logs on to this computer.=20
It also makes an = attacker do more=20 work to get to root.

Secure terminals:
The relevant=20 configuration file may be called /etc/ttys, /etc/default/login, = /etc/security or = /etc/securetty = depending on=20 the system. See the manual pages for = file format=20 and usage information.

Check that the secure option is = removed from=20 any local entries that don't need root = login=20 capabilities. The secure option should = be=20 removed from console if you do not want = users to=20 be able to reboot in single user mode. = [Note:=20 This does not affect usability of the = su command.]

If it is not already the default, = consider=20 using a special group (such as the wheel group on BSD = systems) to=20 restrict which users can use su to become=20 root.

E.2.4 PATH advice

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

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

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

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

E.2.5 User session = controls

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

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

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

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

HP-UX,=20 FreeBSD,=20 AIX=20

E.3=20 Authentication

E.3.1 Password = authentication

E.3.1.1 Evaluate = two-factor=20 authentication

Consider the benefit and cost of = using=20 one-time password sheets, security = tokens or=20 smart cards instead of relying on = reusable=20 passwords alone.

Passwords do not scale well in a = network=20 because lack of trust between domains = requires=20 different passwords. In practice this = results in=20 users either choosing bad passwords, = reusing=20 passwords with multiple systems or = companies, or=20 writing them down. The various forms of=20 two-factor authentication offer an = answer to=20 this.

E.3.1.2 Shadow = passwords

Most UNIX systems now use a shadow = password=20 scheme by default. A few may not - see = notes=20 below. Using the shadow password scheme = is=20 important because it ensures that the = password=20 hashes are not world readable. This = prevents=20 simple dictionary and brute force = attacks being=20 applied to get the passwords from the=20 hashes.

Enable password shadowing if it is = not on by=20 default. See OS specific footnotes for=20 details.

HP-UX,=20 AIX,=20 IRIX=20

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

Verify that all accounts have = passwords.=20 (i.e. the password field is not empty) = Check=20 NIS+ passwords too, if you have them. =

Debian=20

E.3.1.4 Password = Policy

Have a clear password policy for your = organisation. See the AusCERT Advisory = SA-93.04=20 for guidelines on developing password=20 policies.

E.3.1.5 Enforce password = complexity

Check if your operating system has a = built-in=20 way to configure requirements on = password=20 complexity, such as minimum password = lengths,=20 requirements for numbers and symbols, = etc.

For PAM systems this can be done by a = PAM=20 module. If your PAM enabled system does = not have=20 such a module, you can use the = pam_passwdqc=20 module available from http://www.openwall.com/passwd= qc/=20 which supports Linux, Solaris, FreeBSD = and=20 HP-UX.

For a multi-user system which does = not have=20 any mechanism for enforcing difficult = passwords,=20 password auditing is discussed in = section=20 J.7.3

HP-UX=20 AIX=20

E.3.1.6 Password ageing = and=20 password history

Consider enforcing password aging, so = that=20 users will need to change passwords = after a=20 certain maximum period of time.

Be aware that using too = short a=20 change period will probably just result = in users=20 circumventing policy by writing = passwords down.=20
Consider enforcing a = password=20 history, so that users do not re-use = recently=20 used passwords.=20
Note that if using a = history, a=20 minimum period between password = changes=20 may also be necessary, so that people do = not=20 rapidly cycle through passwords to get = around=20 the history/ageing restrictions. =

HP-UX=20

E.3.2 One-time = passwords

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

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

Notes if using one-time = passwords:

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

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

E.3.3 PAM Pluggable = Authentication=20 Modules

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

To find out if a given executable = uses PAM,=20 execute the command ldd=20 <path to executable file>. = For=20 example, the resulting output for /usr/bin/login on a = FreeBSD=20 6.x system:

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

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

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

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

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

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

Linux,=20 Solaris,=20 OpenBSD=20

E.3.4 NIS / NIS+

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

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

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

E.3.5 LDAP

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

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

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

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

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

E.4=20 Access Control

E.4.1 File = Permissions

E.4.1.1 Permissions for = key files=20 and directories

Ensure that system configuration and = runtime=20 files are owned by root and are not = writable by=20 other users. A few examples of such = files are:=20

startup scripts (rc.* and = init.d files),=20
any firewall = configuration files,=20
/etc/profile,=20 /etc/hosts.allow, /etc/mtab,=20
/etc/utmp,=20 /var/adm/wtmp (or /var/log/wtmp),=20
/etc/syslog.pid=20 (or /var/run/syslog.pid)

Ensure that log files (usually = located in=20 /var/log/ or = /var/adm) are only = writable by=20 root.

Ensure that the files holding the = kernel and=20 any kernel modules are owned by root, = have group=20 ownership set to group id 0 and = permissions that=20 prevent them being written to by any = non-root=20 users.

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

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

Make a list of the non-root-owned = directories=20 outside of the user home area, = using
find / -path /home -prune = -o -type d=20 ! -uid 0 -ls
and ensure that = there is=20 nothing unexpected. In particular /etc, /usr/etc, /bin, = /usr/bin,=20 /sbin, /usr/sbin, /tmp and /var/tmp should all = be owned=20 by root.

Some systems ship files and = directories owned=20 by user "bin" (or "sys"). This varies = from=20 system to system and may have security=20 implications, especially if filesystems = are=20 exported with NFS. Change all non-setuid = files=20 and all non-setgid files and directories = owned=20 by "bin" that are world readable but not = world=20 or group writable to be owned by root = instead,=20 with group ownership by group id 0. =

Solaris=20

E.4.1.2 Protect programs = used by=20 root

Any binary that might get run as = root, as=20 well as all parent directories of that = binary,=20 must be owned by root and also not be = writable=20 by any other user or group. This = means:

any program used by = system startup=20 scripts=20
any program used by = daemons=20
any program used in root = cron jobs=20
any program in root's = PATH=20
any program used in = root's shell=20 startup scripts=20
any program executed in = turn by=20 the programs above.=20
- as well as all parent = directories=20 of these programs.

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

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

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

Check the contents of the following = files for=20 the root account. Any programs or = scripts=20 referenced in these files should have = the=20 permissions recommended above:=20

~/.login,=20 ~/.profile, ~/.bashrc, ~/.cshrc = and=20 similar shell initialization files;=20
~/.logout=20 and similar session cleanup files;=20
Program configuration = files in the=20 home directory such as .vimrc and .exrc;=20
crontab=20 and at = entries;=20
scripts and programs on = NFS=20 partitions;=20
/etc/rc*=20 and similar system startup and shutdown = scripts.=20

If any programs or scripts run by = these files=20 use further programs or scripts then = those also=20 need to be secure.

Do not allow any shell scripts to be=20 SetUID.

E.4.1.3 Protect = directories=20 written to by root

The advice in this = section=20 also applies to protecting other daemon = or=20 server accounts.=20

Any predictably named files created = by=20 scripts, daemons, server processes, or = cron jobs=20 MUST be in a directory that is = non-writable by=20 less privileged users and groups. This = includes=20 directories used for logging.

Otherwise, a symlink attack may be = used to=20 escalate privileges from unprivileged = user to a=20 more privileged one, such as root.

Scripts and programs that need to = create=20 files in a directory writable by others, = such as=20 /tmp, must = take special=20 precautions to create the file = atomically. If=20 your organisation's system = administration=20 scripts need to use temporary files, = refer to=20 the Secure=20 Programming for Linux and Unix HOWTO = for a=20 discussion on doing this securely in = shell=20 scripts, Perl and C.

E.4.1.4 Group = membership

There are two different schemes in = use for=20 arranging UNIX groups, and these lead to = different recommendations for home = directory=20 permissions and umask.

1. Traditional group=20 scheme
In this scheme most = users=20 belong to a common group by default, = such as the=20 group "users". This is the default on = OpenBSD,=20 Slackware, ...

2. User Private Group=20 scheme
In this scheme a = separate=20 group is created in /etc/groups for each = user. The=20 user should be the only member of that = group.=20 This scheme makes working on group = projects=20 easier, as users do not need to use the = umask=20 command when working in a common project = directory. This is the default on = FreeBSD, Red=20 Hat, Debian, ...

Do not use the legacy = feature of=20 password protected groups. It is = insecure=20 because the /etc/group=20 file is not shadowed, so hashes are = world=20 readable.

HP-UX=20

E.4.1.5 umask for users =

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

Ensure the umask for each user is set = to a=20 restrictive value within the user's = shell=20 startup scripts. The appropriate umask = will=20 depend on whether a User Private Group = scheme is=20 used. If the traditional group scheme is = being=20 used, ensure a umask of 077 or 027 is = set in the=20 users' shell startup scripts.

A weaker umask of 007 is acceptable = if the=20 User Private Group scheme is being used. =

E.4.1.6 Permissions for = user home=20 directories

Ensure user home directories are = owned by the=20 user, and are not writable by any other = user or=20 group.

If the traditional group scheme is in = use,=20 the group ownership on home directories = may be=20 set to the common group, so ensure that = the=20 directory is not group-writable.

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

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

E.4.2 Filesystem = attributes

Consider using file attributes if = your=20 operating system supports them.=20

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

Linux,=20 FreeBSD=20

E.4.3 Role Based Access=20 Control

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

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

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

Linux,=20 Solaris,=20 HP-UX,=20 AIX=20

E.4.4 sudo

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

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

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

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

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

E.4.5 Consider mandatory = access=20 control features

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

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

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

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

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

Linux=20

E.5=20 Other

E.5.1 Cron

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

Consider not allowing regular users = to add=20 cron jobs.

E.5.2 Mount options

Choosing to use separate partitions = as=20 recommended in section B.3 now allows=20 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.=20

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

AIX=20

E.5.3 Non-execute memory = protection

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

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

Solaris,=20 HP-UX,=20 AIX=20

E.5.4 Umask for startup=20 scripts

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

E.5.5 .netrc files

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

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

Secure Base OS - general = notes:=20 Linux,=20 Solaris,=20 HP-UX,=20 FreeBSD,=20 OpenBSD,=20 AIX=20

F. Secure Major = Services

F.1 Confinement

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

F.1.1 Running under an=20 unprivileged account

Ensure that services run under = unprivileged=20 accounts where possible.

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

F.1.2 using chroot = jails

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

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

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

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

F.1.3 Other confinement=20 mechanisms

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

Linux,=20 Solaris,=20 FreeBSD=20

F.2 tcp_wrappers

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

tcp_wrappers does provide some extra=20 flexibility if needed; it can be = configured to=20 require reverse DNS lookups or ident = (RFC931)=20 lookups, allows automatic execution of = scripts=20 when conditions are met, and can also = provide=20 improved logging for services that do = not have=20 adequate access logs of their own.

There are two ways that tcp_wrappers = may be=20 used on the system:=20

It is possible to = explicitly=20 "wrap" a service, by running the program = tcpd to accept = connections=20 which are then passed to the actual = network=20 service.=20
More commonly though, = the vendor=20 has already compiled network services to = use the=20 libwrap = library. In this=20 case the relevant daemon will enforce = the=20 tcp_wrappers restrictions when accepting = connections.

The main configuration file for = tcp_wrappers=20 is /etc/hosts.allow
Explicitly=20 list host IPs which are allowed access = to the=20 services in this file. At the bottom of = the file=20 put all:all:deny to deny=20 all other IP addresses. The rules in = this file=20 work on a "first match wins" basis.

The file /etc/hosts.deny may = also be=20 used, though this is no longer = required.
If=20 /etc/hosts.deny is=20 present, put all:all in=20 this file.

HP-UX=20

F.3 Other general advice = for=20 services

F.3.1 Configure services = to listen=20 on one interface only.

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

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

F.3.2 Adding SSL to = existing=20 services

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

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

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

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

F.4 SSH

Do not log in via SSH from an = insecure=20 workstation. Contrary to popular belief, = public=20 key cryptography will not protect you in = doing=20 this. Where SSH is used, a trust = relationship is=20 implied - the SSH server computer trusts = the=20 security of the SSH client computer.

Be aware that when doing X-forwarding = through=20 SSH, the trust relationship is also = reversed -=20 the workstation running the X display = must also=20 trust the computer running each X = program. This=20 is due to the cross-client X attacks = described=20 below in F.9.3

Suggested configuration options for = the=20 OpenSSH sshd implementation:

In the configuration file sshd_config=20 do use:=20

Protocol=20 2 (the SSH 1 protocol had=20 weaknesses)
ListenAddress=20 192.168.45.3 (bind to one address = only)
PermitRootLogin=20 no
Listen = 222=20 (consider using an alternate = port)
PermitEmptyPasswords=20 no
AllowUsers one=20 two@host1 three

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

RhostsAuthentication
HostBasedAuthentication
RhostsRSAAuthentication (not=20 good for accountability)

Where SSH is used by scripts, = configure SSH=20 on the server side to allow execution of = a=20 certain single command only. This is = achieved=20 using a command=3D=20 directive in the authorized_keys = file.

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

F.5 Printing

There are several different default = printing=20 systems supplied with UNIX and Linux = systems.=20 The three most common of these are BSD = style=20 lpr (also = found on AIX),=20 LPRng and CUPS.

In general, prevent the printing = service from=20 listening to the network unless = necessary for=20 this computer's role.

If a network printing service = is=20 part of this computer's role, then do = not rely=20 solely on IP addresses for = authentication (for=20 instance the hosts.lpd=20 file with lpd or LPRng is based only on = IP=20 address.)

F.6 RPC/portmapper

Look for the specific facilities = provided by=20 your operating system for securing RPC = access=20 with authentication and/or encryption. = The=20 security features available vary greatly = between=20 UNIX variants.

Be aware that some older = portmapper/rpcbind=20 daemons may forward RPC requests from = remote=20 hosts, and make them appear to come from = the=20 localhost.

F.7 File services=20 NFS/AFS/Samba

F.7.1 NFS

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

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

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

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

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

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

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

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

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

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

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

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

Solaris=20

F.7.2 Samba

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

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

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

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

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

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

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

F.8 Email service

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

F.8.1 Sendmail

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

If this computer is not a mail = server, then:=20

Disable SMTP connections = from=20 other computers by adding
Addr=3D127.0.0.1 to = each DAEMON_OPTIONS macro = that is=20 in your config.
For = example:
DAEMON_OPTIONS(`Name=3DIPv4,=20 Family=3Dinet,=20 = Addr=3D127.0.0.1')
DAEMON_OPTIONS(`Name=3DIPv6,=20 Family=3Dinet6,=20 = Addr=3D::1')
FEATURE(`no_default_msa')
DAEMON_OPTIONS(`Name=3DMSA, = Port=3D587, = Address=3D127.0.0.1')
Consider disabling the = daemon mode=20 altogether by removing the -bd option from the = startup=20 script. This will still allow most local = Mail=20 User Agents to invoke the sendmail = binary to=20 send mail. In this case, do use a -q30m option to = ensure queued=20 outbound messages are still processed.=20

If this IS a mail server, then:

Ensure familiarity with = Sendmail=20 access control and anti-spam control = features.=20 See http://www.sendmail.or= g/m4/anti_spam.html=20 for an overview.
If it is really = necessary to relay=20 mail from roaming users outside your = local=20 address range, then configure Sendmail = to=20 require SMTP AUTH for these connections. =

In both cases:

If you do not require = emails to be=20 piped to other programs for processing = then=20 disable prog mailer functionality = with
MODIFY_MAILER_FLAGS(`LOCAL',=20 `-|')
If you do = require piping=20 email to programs, use smrsh to limit the = programs=20 that can be executed to only those = programs=20 linked in the smrsh configuration = directory.=20 This can be turned on with
FEATURE(`smrsh',=20 `/usr/libexec/smrsh')
(The = location=20 of the smrsh binary may vary on = different=20 systems.)
Consider setting = sendmail logging=20 to a minimum log level of 10.
This = will help=20 detect attempted exploitation of = sendmail=20 vulnerabilities as well as logging each=20 connection and the username used in each = SMTP=20 AUTH. To do this use:
define (`confLOG_LEVEL',=20 `10')
/etc/mail/aliases
check=20 that any programs executed from this = file are=20 owned by root, have permissions 755 and = are=20 stored in the smrsh configuration = directory,=20 e.g. /etc/smrsh=20

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

F.8.2 Mail server MTA = choices

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

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

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

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

F.9 The X Window = System

F.9.1 Restrict access to = the X=20 server

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

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

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

Do not use host based access control. = Remove=20 all instances of the xhost command from = the=20 system-wide Xsession=20 file, from user .xsession files, and = from any=20 application programs or shell scripts = that use=20 X.

F.9.2 Protect any X = traffic

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

F.9.3 Avoid cross-client = X=20 attacks

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

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

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

F.9.4 X display = managers

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

xdm may bypass the normal getty and = login=20 functions, which means that quotas for = the user,=20 ownership of /dev/console and = possibly=20 other preventive measures put in place = by you=20 may be ignored.

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

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

F.10 DNS service

F.10.1 BIND

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

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

Consider applying the security = practices=20 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=20 Liu http://www.linuxsecurity.com/resource_fi= les/server_security/securing_an_internet_name_server.pdf

Chroot-BIND HOWTO By Scott Wunsch http://www.los= urs.org/docs/howto/Chroot-BIND.html=20 for BIND version 9.x or http://www.lo= surs.org/docs/howto/Chroot-BIND8.html=20 for BIND version 8.x.

F.10.2 DNS server = choices

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

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

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

<= /DIV>

F.11 WWW service

F.11.1 General = configuration

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

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

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

Consider configuring the web server = to not=20 follow symbolic links. This prevents a = user with=20 access to the web server's document tree = from=20 making other documents, outside the = tree,=20 available via symbolic links.

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

F.11.2 Web = applications

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

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

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

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

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

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

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

F.11.3 TLS / SSL

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

Confirm that sensitive form data is = not=20 submitted unencrypted.

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

SSL version 2.0 is insecure and = should be=20 disallowed.

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

F.11.4 Static-only = webserver

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

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

F.12 Squid proxy

Avoid providing an open=20 proxy
Configure access = controls so=20 that only authorised clients can make = requests=20 through the proxy.

Note that Squid ACLs use the first = rule that=20 matches. If none match, the last rule = checked is=20 used inverted. So to avoid unintended = access it=20 is best to put a catch-all deny rule=20 last:
http_access = deny=20 all

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

Disable unused=20 protocols
If you are not = using the=20 inter-cache and management protocols, = then turn=20 them off by setting the port to 0, as in = the=20 following configuration lines:
snmp_port 0
htcp_port=20 0
icp_port 0

Deny proxy to=20 localhost
To ensure that a = remote=20 attacker cannot connect to other ports = on the=20 local computer via the Squid proxy, = include=20 access rules similar to the = following:
acl to_localhost dst=20 127.0.0.1/8
deny to_localhost =

Secure squid = files
Check=20 that squid logs and cache files are not = world=20 readable. These can contain data from = proxy=20 users that should remain = confidential.

F.13 CVS

Use SSH to authenticate and encrypt = all CVS=20 access.

Do not use CVS pserver = functionality.

Create a UNIX account on the computer = for=20 each CVS user, and limit their SSH = session so it=20 is only able execute the = command "cvs server".

Why this provides better security = than cvs=20 pserver:=20

cvs does not need to run = as root=20
Access control is = enforced by the=20 operating system, not by cvs.

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

Use LockDir = in CVSROOT/config to = have read=20 only directories where = appropriate.

F.14 Web browsers

Do not allow external programs to = spawn=20 automatically for any type of downloaded = content. This includes not allowing = browsers to=20 automatically launch multimedia viewers, = shells,=20 script interpreters or macro = processors.

Instead configure the browser to = prompt=20 before opening external programs. This = can be=20 achieved using the helper application=20 preferences for the browser.

Consider disabling Java and = JavaScript in the=20 web browser.

Do not run a web browser as = root.

F.15 FTP service

Do not run an FTP service unless = there is no=20 alternative.=20

If the purpose is to = provide=20 unauthenticated access or public access = it is=20 better to use a simple HTTP server such = as=20 publicfile (see section F.11.4).=20

If authenticated access = is=20 required, it is better to use sftp. An = sftp=20 server is included as part of OpenSSH, = which is=20 available either as packages from your = OS=20 vendor, or as source from http://openssh.com/.=20 Several free graphical clients are = available to=20 support Windows users, including WinSCP = (http://winscp.net/).=20

F.15.1 General = configuration

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

% = telnet=20 localhost 21
USER username
PASS=20 password
SITE EXEC

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

Ensure that you have set up the file = /etc/ftpusers. This = file=20 specifies those users that are = not=20 allowed to connect to your ftpd. This = should=20 include, as a minimum, the entries: = root, bin,=20 uucp, ingres, daemon, news, nobody and = ALL=20 vendor supplied accounts.

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

Check all default configuration = options on=20 your FTP server. Not all versions of ftp = daemons=20 are configurable. If you have a = configurable=20 version of ftp (e.g., WU-FTP) then make = sure=20 that all delete, overwrite, rename, = chmod and=20 umask options (there may be others) are=20 not allowed for guests and = anonymous=20 users. In general, anonymous users = should not=20 have any unnecessary privileges.

Ensure there are no shells, = interpreters or=20 system commands in ~ftp/bin,=20 ~ftp/usr/bin, ~ftp/sbin or = similar=20 directories. It may be necessary to keep = some=20 commands, such as uncompress, in these = locations. Consider the inclusion of = each=20 command on a case by case basis and be = aware=20 that the presence of such commands may = make it=20 possible for local users to gain = unauthorised=20 access. Be wary of including commands = that can=20 execute arbitrary commands. For example, = some=20 versions of tar may=20 allow you to execute an arbitrary=20 file.

Ensure that you use an invalid = password=20 and user shell for the ftp entry in the = system=20 password file and the shadow password = file (if=20 you have one). It should look something=20 like:

ftp:*:400:400:Anonymous
ftp:/home/ftp:/bin/falsewhere=20 /home/ftp is = the=20 anonymous FTP area.=20

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

Make sure that you do not = have a=20 copy of your real /etc/passwd file as = ~ftp/etc/passwd. = Create one=20 from scratch with permissions 444, owned = by=20 root. It should not contain the names of = any=20 accounts in your real password file. It = should=20 contain only root and=20 ftp. These = should be=20 dummy entries with disabled passwords = e.g.:=20

root:*:0:0:Ftp=20 maintainer::
ftp:*:400:400:Anonymous=20 ftp::

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

Make sure that you do not = have a=20 copy of your real /etc/group file as = ~ftp/etc/group. = Create one=20 from scratch with permissions 444, owned = by=20 root.

Ensure the files ~ftp/.rhosts and = ~ftp/.forward do not = exist.

Set the login shell of the ftp = account to a=20 non-functional shell such as /bin/false.

Ensure no files or directories are = owned by=20 the ftp = account or have=20 the same group as the ftp account. If they = are, it=20 may be possible for an intruder to = replace them=20 with a trojan version.

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

Ensure that the directories ~ftp/etc and ~ftp/bin are owned = by root=20 with permissions 111.

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

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

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

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

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

HP-UX=20

F.15.2 Anonymous FTP =

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

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

Ensure that if you want to use = anonymous FTP=20 you have configured your server = correctly. In=20 general, anonymous users should not be = allowed=20 to create directories, delete anything, = change=20 the file system in any way (for instance = change=20 the permissions of a file) or upload = files. If=20 you intend to allow anonymous users to = upload=20 files, read the section below about = upload=20 directories.

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

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

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

F.15.3 Upload = directories

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

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

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

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

G. Add Monitoring=20 Capability

DISCLAIMER: We recommend you = consult your=20 organisation's security and privacy = polices, as=20 well as any laws for your area before=20 implementing any of the suggestions in = this=20 section.

G.1 syslog = configuration

Consider using syslog's remote = logging=20 feature to send logs to a separate = logging=20 computer.
Remote logging ensures = that even=20 if the UNIX system is compromised, = attackers=20 cannot simply modify the log files to = cover=20 their tracks.

Consider protecting the network = logging=20 stream with authentication and = encryption, for=20 example by tunnelling it over SSH with = netcat.

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

Unless this computer is a log server, = ensure=20 that syslog will not accept = incoming=20 log packets over the network. On some = systems=20 this is the default. On others it may be = implemented by starting syslog with the = -t option = (nolisten).=20

Consider increasing the level of = logging=20 provided by syslog.=20

Make sure that the = messages of the=20 LOG_AUTH = facility at=20 level LOG_INFO = and above=20 get logged.=20
For email, enable a = minimum level=20 of "info" for mail messages to be logged = by=20 syslog.

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

Check that all login attempts are = logged,=20 both successful and unsuccessful. There = may be=20 several different ways to log in, such = as at the=20 console, through X and through SSH.

Consider protecting your log files = with=20 filesystem attributes if possible, to = make them=20 append-only. See section E.4.2 for=20 details.

OpenBSD,=20 AIX=20

G.2 Monitoring of = logs

G.2.1 Process for log = monitoring=20

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

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

G.2.2 Automated log = monitoring=20 tools

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

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

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

Ensure any = automated=20 reporting facilities provided by your = operating=20 system are turned on, and are sending = output to=20 an appropriate user for reading. (e.g. = FreeBSD /=20 OpenBSD daily scripts)

Regularly monitor logs for both = successful=20 and unsuccessful logins, and uses of = su and sudo.

Regularly check for repeated access=20 failures.

G.3 Enable trusted audit = subsystem=20 if available

On many platforms a more = comprehensive audit=20 subsystem is optionally available. The = benefit=20 is to allow more dependable and = configurable=20 logging of a wider range of security = events.

Enable the trusted system audit = features if=20 available for your platform.

Linux,=20 Solaris,=20 HP-UX,=20 AIX=20

G.4 Monitor running = processes

G.4.1 Availability of = servers

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

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

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

G.4.2 Process = accounting

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

Regularly monitor process accounting = log=20 files for activity of interest.

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

G.4.3 lsof

lsof is a = tool for=20 monitoring open system files that can be = useful=20 in checking current activity on the = system.=20 lsof may be = included=20 with your operating system, and is also=20 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=20 intrusion detection, providing = monitoring for=20 unexpected filesystem changes.

When using a file integrity = checker:

Have a system = administration=20 procedure in place to check and update = the=20 database at least weekly to reflect = legitimate=20 changes. Without this any real security = alerts=20 may be lost amidst the noise of = legitimate=20 changed files.
Consider storing the = integrity=20 checker binary, its database and = configuration=20 file on hardware write-protected media, = and=20 using a binary that is statically = linked.
Consider running the = integrity=20 checker from a bootable CD. This is the = most=20 tamper-proof option, but is not = appropriate in=20 many cases because it involves downtime = while=20 the check is run.

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

AIX,=20 Solaris=20

G.5.2 Antivirus / = malware=20 detection

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

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

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

Host-based intrusion = detection -=20 notes: HP-UX

G.6 Network intrusion=20 detection

G.6.1 Signature matching = IDS

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

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

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

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

G.6.2 ARP = monitoring

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

Monitoring - general notes:=20 OpenBSD=20

H. Connect to = Net

H.1 First put in place a = host=20 firewall.

H.1.1 Identify host = firewall=20 software

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

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

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

H.1.2 Design host = firewall

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

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

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

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

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

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

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

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

Internet Firewalls FAQ
http://www.interhack.net/pu= bs/fwfaq/

Building=20 Internet Firewalls, Second = Edition

H.1.3 Weak end system =

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

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

To address this, either:=20

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

Solaris,=20 FreeBSD=20

H.2 Position this = computer behind=20 a border firewall.

Position the UNIX system on a = protected=20 subnet, with at least a separate = firewall device=20 sitting between it and the open=20 Internet.

H.3 Network stack=20 hardening/sysctls

The kernel's network settings can be = tuned=20 and made more secure, usually using the = sysctl=20 command or configuration file. The = details of=20 how to do this are very specific to each = operating system. It is recommended to = check the=20 following settings:

Disable IP source = routing.=20
Disable ICMP redirects.=20
Disable = forwarding/routing of IP=20 packets unless this computer is a = router. See OS=20 specific footnotes for details.=20
If your OS provides = syncookies to=20 mitigate SYN-flood denial of service, = then=20 ensure that this feature is turned on.=20 Syncookies are available on Linux, = Solaris and=20 FreeBSD.=20
Consider configuring = shorter state=20 timeouts and increasing the size of = state tables=20 to make the system more resistant to = denial of=20 service.=20
For servers, consider = configuring=20 a static IP address on the host itself, = rather=20 than using a static IP allocation = through DHCP.=20
On critical computers, = consider=20 using a static ARP cache to prevent ARP = spoofing=20 attacks from the local LAN. =

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

Further information on adjusting = network=20 parameters is provided in the following=20 documents:

UNIX IP Stack Tuning Guide v2.7 (Rob = Thomas)=20 - covers AIX, Solaris, HP-UX, Linux, = FreeBSD and=20 IRIX.
http://www.c= ymru.com/Documents/ip-stack-tuning.html

TCP/IP Stack Hardening - covers AIX, = FreeBSD,=20 HP-UX, Linux, Solaris and IRIX.
http://www.cromwell-intl.com/security/security-stack-hardening.html

H.4 Connect to network = for the=20 first time

It is recommended to connect the = computer to=20 the network for the first time at this=20 stage.

I. Test Backup/Rebuild=20 Strategy

I.1 Backup/rebuild = strategy

When an intrusion or suspected = intrusion is=20 detected, your options in responding = will depend=20 critically on whether you have an = effective=20 backup/rebuild strategy in place = beforehand.

With a rebuild process that is = largely=20 automated, it is possible to either swap = in a=20 new hard disk and rebuild the server, or = rapidly=20 deploy a replacement server, allowing = the=20 compromised machine to be taken off the = network=20 quickly while maintaining uptime.

This ability to disconnect the = computer=20 rapidly reduces the risk of further = intrusion to=20 other systems, and at the same time = preserves=20 evidence on the hard disk at an early = stage. But=20 it depends on an effective restore and=20 rebuilding process already being in = place.

Implement a backup, restore and = rebuilding=20 process that satisfies your security = policy.

Depending on the uptime requirements=20 determined in section A.4 for this = system,=20 consider whether a replacement hard disk = or a=20 full replacement server is appropriate = for your=20 situation.

Protect the confidentiality and = integrity of=20 the backups themselves, as the = information in=20 the backups is usually as sensitive as = the=20 original system. For example, the = authentication=20 information in the backup is often = sufficient to=20 compromise the original system remotely. = For=20 integrity, the aim is that an attacker=20 compromising this system can only alter = future=20 backups, and not past backups.

I.2 TEST backup and = restore

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

I.3 Allow separate = restore of=20 software and data

Consider having business data backed = up and=20 restorable separately from executable=20 programs.

After a compromise, this allows more=20 flexibility, for example to restore = today's data=20 but with the system and software backup = from=20 three weeks ago.

I.4 Repatch after = restoring

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

I.5 Process for = intrusion=20 response

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

I.5.1 Documented = process

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

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

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

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

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

I.5.2 Forensic = tools

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

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

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

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

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

Autopsy is available at http://www.sleuthkit.o= rg/autopsy/desc.php

Solaris=20

I.5.3 Malware detection = tools

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

J. Maintain

J.1 Mailing lists

Notifications of patch releases and = security=20 updates are generally done via mailing = lists.=20

Subscribe to the vendor "announce" = list as=20 well as any security mailing lists for = your=20 specific operating system.

Subscribe to the appropriate = security/updates=20 mailing list for each third party = software=20 package installed.

Also subscribe to security advisory = mailing=20 lists from your local incident response = team (if=20 you have one available).

AusCERT Security Bulletins are = available at=20 http://www.auscert.org.au/1

US-CERT Vulnerability Notes are = available at=20 http://www.kb.cert.org/vuls/

J.2 Software = inventory

Maintain an up-to-date list of = software=20 installed on each system, with version = numbers.=20 This list includes the base OS and each = piece of=20 third party software.

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

J.3 Rapid patching

The window of time between = vulnerabilities=20 being publicly announced and widespread=20 exploitation is now very short. Design = your=20 patching and update process aiming to = allow=20 critical patches to be applied within 48 = hours=20 of patch release.

For important systems, maintain a = test=20 environment where patches can be = trialled first=20 before deploying to production = systems.

Be aware that installing = patches/updates can=20 sometimes re-enable services that you = have=20 disabled.

J.4 Secure = administrative=20 access

J.4.1 Strongly = authenticated=20 access only

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

J.4.2 Administer only = from a=20 secure workstation

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

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

J.5 Log book for all = sysadmin=20 work

Maintain a log book to record all = significant=20 system administration work on the=20 system.

J.6 Configuration change = control=20 with CVS

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

J.7 Regular audit

Design and put into action a process = to=20 re-assess the security of the system at = regular=20 intervals.

J.7.1 Re-apply this = checklist

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

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

J.7.2 Check for dormant=20 accounts

Regularly audit the system for = dormant=20 accounts and disable any that have not = been used=20 for a specified period of time, in = accordance=20 with your site's security policy.

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

J.7.3 Audit weak = passwords

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

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

J.7.4 Apply network = scan/audit=20 tools

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

nmap is a port scanning tool = available from:=20 http://www.insecure.org/nmap/<= /P>

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

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

Introduction

Contents

A. Determine Appropriate = Security

A.1 Computer role

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

A.3 Trust = relationships

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

A.5 Determine minimal = software=20 packages required for role

A.6 Determine minimal = net access=20 required for role

B. Installation

B.1 Install from trusted = media

B.2 Install while not = connected to=20 the Internet

B.3 Use separate = partitions

B.4 Install minimal = software

C. Apply all Patches and = Updates

C.1 Initially apply = patches while=20 offline

C.2 Verify integrity of = all=20 patches and updates

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

D. Minimise

D.1 Minimise network = services

D.1.1 Locate services = and remove=20 or disable

D.1.2 Minimise = inetd/xinetd

D.1.3 Minimise = portmapper and RPC=20 services

D.1.4 Notes on = particular network=20 services

D.2 Disable all = unnecessary=20 startup scripts

D.3 Minimise = SetUID/SetGID=20 programs

D.4 Other = minimisation

E. Secure Base = OS

E.1=20 Physical, console and boot security

E.2 User=20 Logons

E.2.1 Account = Administration

E.2.2 Special = accounts

E.2.3 Root account

E.2.3.1 Root = password

E.2.3.2 No direct root = logins

E.2.4 PATH advice

E.2.5 User session = controls

E.3=20 Authentication

E.3.1 Password = authentication

E.3.1.1 Evaluate = two-factor=20 authentication

E.3.1.2 Shadow = passwords

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

E.3.1.4 Password = Policy

E.3.1.5 Enforce password = complexity

E.3.1.6 Password ageing = and=20 password history

E.3.2 One-time = passwords

E.3.3 PAM Pluggable = Authentication=20 Modules

E.3.4 NIS / NIS+

E.3.5 LDAP

E.4=20 Access Control

E.4.1 File = Permissions

E.4.1.1 Permissions for = key files=20 and directories

E.4.1.2 Protect programs = used by=20 root

E.4.1.3 Protect = directories=20 written to by root

E.4.1.4 Group = membership

E.4.1.5 umask for users =

E.4.1.6 Permissions for = user home=20 directories

E.4.2 Filesystem = attributes

E.4.3 Role Based Access=20 Control

E.4.4 sudo

E.4.5 Consider mandatory = access=20 control features

E.5=20 Other

E.5.1 Cron

E.5.2 Mount options

E.5.3 Non-execute memory = protection

E.5.4 Umask for startup=20 scripts

E.5.5 .netrc files

F. Secure Major = Services

F.1 Confinement

F.1.1 Running under an=20 unprivileged account

F.1.2 using chroot = jails

F.1.3 Other confinement=20 mechanisms

F.2 tcp_wrappers

F.3 Other general advice = for=20 services

F.3.1 Configure services = to listen=20 on one interface only.

F.3.2 Adding SSL to = existing=20 services

F.4 SSH

F.5 Printing

F.6 RPC/portmapper

F.7 File services=20 NFS/AFS/Samba