Date: 08 October 2001
Introduction
This document has been published jointly by The Australian
Computer Emergency Response Team (AusCERT) and the CERT®
Coordination Center (CERT/CC) and details steps to improve the security
of Unix Operating Systems. We encourage system administrators to review
all sections of this document and if appropriate modify their
systems accordingly to fix potential weaknesses.
The most current version of this document is available from:
http://www.auscert.org.au/render.html?cid=1920
While this document details security procedures for UNIX based systems,
it should not be used as a tool for recovering from a system compromise.
For information regarding recovering from a system we encourage you to
review the "Steps for Recovering from a UNIX or NT System Compromise"
document, available from:
http://www.auscert.org.au/render.html?it=1974
It is our intention to continue to update this checklist. Any
comments should be directed via email to auscert@auscert.org.au
and cert@cert.org. Before using this document, ensure you have
the latest version. New versions of this checklist will be placed
in the same area and should be checked for periodically.
If possible, apply this checklist to a system before attaching
it to a network. In addition, we recommend that you use the
checklist on a regular basis as well as after you install any
patches or new versions of the operating system, with consideration
given to the appropriateness of each action to your particular
situation.
Disclaimer
AusCERT and CERT/CC advise that this information is provided
without warranty - sites should ensure that actions and procedures
taken from information in this document are verified and in accordance
with security policies that are in place within their organisation.
Listing of an application program or tool within this document does
not constitute endorsement by AusCERT, The University of Queensland,
or CERT/CC.
Table of Contents:
- Retrieve the latest patch list for your specific operating
system, as well as any applications (i.e. web server, DNS, etc...)
from the appropriate vendors. Install any security patches not yet
installed that are recommended for your system. Be aware that some
patches may re-enable default configurations. For this reason, it
is important to go through this checklist AFTER installing ANY new
patches or software packages.
- Details on obtaining patches for particular operating
systems may be found in Section IV.
- Verify the digital signature of any signed files.
Encryption tools like PGP and GnuPG may be used to sign files and
to verify those signatures. Refer to A.2.10
for PGP and GnuPG access information.
- If a digital signature is not supplied but an MD5
checksum is, then verify the checksum information to
confirm that you have retrieved a valid copy. Refer to
A.2.6 for information on obtaining MD5 tools.
- If only a generic sum(1) checksum is provided, then check
that. Be aware that the sum(1) checksum will only detect modifications
during transfer (e.g. download) and won't detect malicious changes
prior to download. For this reason, it is always preferable to verify
files with either PGP/GnuPG or MD5.
- Keep your software and patches up to date. Notifications of
patch releases are generally done via mailing lists.
- Subscribe to the vendor's security update
mailing list for your particular operating system.
Refer to Section IV for
individual operating system vendors.
- Subscribe to security advisory mailing lists
from your local incident response team (if you have
one). These mailing lists are typically low volume
and provide invaluable information for system and
security administrators. Refer to
B.2.3 for information on
subscribing to related mailing lists.
2.1 /etc/inetd.conf
- ENSURE that the permissions on this file are set to 600.
- ENSURE that the owner is root.
- DO disable any services which you do not require.
- To do this we suggest that you comment out ALL
services by placing a "#" at the beginning of each line.
Even seemingly innocuous services such as echo and
chargen may be used in a DoS attack.
- Enable the ones you NEED by removing the "#" from
the beginning of the line. In particular, it is best to
avoid "r" commands (e.g. rsh, rlogin) and tftp, as they
have been major sources of insecurities.
- For changes to take effect, you need to restart
the inetd process. Do this by issuing the commands in
C.1. For some systems (including AIX),
these commands are not sufficient. Refer to vendor
documentation for more information.
- Verify that you have disabled any unnecessary
startup scripts. This may be done by removing the executable
bit, or renaming the files so they do not start with K or S
under /etc/init.d or startup script directory for
your system. See your vendor's documentation for specific
details.
- DO use tcp_wrappers to provide greater access and logging
on any enabled network services (see 2.2).
- DO enable access controls and logging for inetd if your
version supports it.
- CONSIDER alternatives to inetd. Xinetd is claimed to have
enhanced access control and logging capabilities as well as
resistance to DoS attacks. It is included in the Red Hat Linux 7
distribution and the source code is available for other systems from:
http://www.xinetd.org/
2.2 tcp_wrapper
- ENSURE that you are using this package as it allows you
to monitor and filter incoming requests for common network services.
- See A.1.13 for instructions to obtain
tcp_wrapper.
- Customise and install it for your system.
- Enable PARANOID mode.
- CONSIDER running with the RFC931 (ident) option.
- Explicitly list trusted hosts which are allowed access to
services on your machine in /etc/hosts.allow.
- Deny all other hosts by putting all:all:deny in
/etc/hosts.allow. Please note that the rules in this file
work on a "First match wins" basis, so be sure to allow any
required hosts/services before you deny all other connections.
- Put all:all in /etc/hosts.deny to
protect services that still use this file.
- DO wrap all TCP services that you have enabled in
/etc/inetd.conf.
- CONSIDER wrapping any UDP services you have enabled. If
you wrap them, then you will need to enable the nowait option in
the /etc/inetd.conf file.
2.3 fingerd
- CONSIDER disabling the finger service if it is not
considered essential.
- ENSURE that you have an up-to-date version of fingerd. Do
not use a version of fingerd that is older than 16 October,
2000. Refer to the AusCERT ESB:
ESB-2000.286
- Fingerd can provide a would-be intruder with a lot of
information about your host. CONSIDER the finger information
you provide and think about reducing the content by disabling
finger or by replacing it with a version that only offers
restricted information. [NOTE: Other services such as rusers
and netstat may give out similar information.]
- DO NOT enable reverse finger as this can create a 'finger war'
DoS loop with other systems also configured for reverse finger.
- ENSURE that you configure fingerd to deny indirect finger
requests. (i.e. finger user@some_host@your_host)
2.4 "r" Commands
- If you don't NEED to use the "r" commands (e.g. rlogin,
rsh, rcp)...
- DO disable all "r" commands unless specifically
required, as they may increase your risk of password exposure
in network sniffer attacks. Also, "r" commands have been a
regular source of insecurities and attacks. Disabling them
is by far the lesser of the two evils (Refer to
2.1).
- If you must run the "r" commands...
- CONSIDER replacing the "r" command functionality
with more secure utilities, for example ssh and scp.
Ssh is a vastly superior program over rsh, telnet, etc...
because it encrypts your password as well as all data
transmitted in the session.
Refer to A.2.13 for information on where
you can obtain ssh.
- DO NOT allow the use of $HOME/.rhosts
(See 2.6).
- DO use more secure versions of the "r" commands
for cases where there is a specific need. Wietse Venema's
logdaemon package contains a more secure version of the
"r" command daemons. These versions can be configured to
consult only /etc/hosts.equiv and not
$HOME/.rhosts. There is also an option to disable the
use of wildcards ('+'). Refer to A.2.4
for access information for the logdaemon package.
- DO filter ports 512, 513, and 514 (TCP) at your
network border router to prevent access to them by people
outside of your network. To limit access by people inside
your network, these commands must either be disabled
completely or restricted to certain hosts only by the
configuration of the hosts.allow and
hosts.deny files.
2.5 /etc/hosts.equiv
- It is recommended that the following actions be taken
whether or not the "r" commands are in use on your system.
- CHECK if the file /etc/hosts.equiv is
required. If you are running "r" commands, this file
allows other hosts to be trusted by your system. Programs
such as rlogin can then be used to log on to the same
account name on your machine from a trusted machine without
supplying a password. If you are not running "r" commands
or you do not wish to explicitly trust other systems, you
should have no use for this file and it should be removed
or emptied. Creating /etc/hosts.equiv as a
zero-length file enables it to be monitored by utilities
such as Tripwire (A.1.15) for
modification. If it does not exist or is empty, it cannot
cause you any problems if any of the "r" commands are
accidentally re-enabled.
- If you must use a /etc/hosts.equiv file
- ENSURE that you keep only a small number of
TRUSTED hosts listed.
- DO use netgroups for easier management if you run
NIS (also known as YP) or NIS+.
- DO only trust hosts within your domain or under
your management.
- ENSURE that your /etc/host.conf (or
equivalent) is set to the order hosts,
bind. Specify in /etc/hosts.equiv
the hosts for which you wish to allow "r" commands.
- ENSURE that you use fully qualified hostnames
(i.e. hostname.domainname.au).
- DO specify usernames in /etc/hosts.equiv
if access is only required for specific users.
- ENSURE that you do NOT have a '+' entry by itself
anywhere in the file as this may allow users access to the
system.
- ENSURE that the permissions are set to 600.
- ENSURE that the owner is set to root.
- CHECK it again after each patch or operating
system installation.
2.6 $HOME/.rhosts
- It is recommended that the following action be taken
whether or not the "r" commands are in use on your system.
- ENSURE that no user has a .rhosts file in
their home directory. These files pose a greater security risk
than /etc/hosts.equiv, as one can be created by
each user. There are some genuine needs for these files, (e.g.
running unattended backups over a network) so consider each
one on a case-by-case basis.
- DO use cron to periodically check for, report the
contents of and delete (or clear) $HOME/.rhosts
files. Users should be made aware that you regularly
perform this type of audit, as directed by your internal
policy.
- If you must have such a file:
- ENSURE that you do NOT have the symbol "-" as the
first character in this file, or the symbol "+" on any
line, as these may allow users access to the system.
- ENSURE that the permissions are set to 600.
- ENSURE that you use fully qualified hostnames
(i.e. hostname.domainname.au).
- ENSURE that your /etc/host.conf (or
equivalent) is set to the order hosts,
bind and specify in it the hosts for which you
wish to allow "r" commands.
- ENSURE that the owner of the file is the
account's owner.
- ENSURE that usernames are specified.
- ENSURE that usage of netgroups within
.rhosts does not allow unintended access to this
account. This is best achieved by specifying individual
users and hosts you want to have access.
- REMEMBER that you can also use logdaemon to
restrict the use of $HOME/.rhosts (Refer to
A.2.4).
2.7 /etc/netgroup
- If you require the functionality of NIS, CONSIDER using NIS+
due to the inherent insecurity of NIS (YP).
- If you are using NIS (YP) or NIS+, DO define each
netgroup to contain only usernames or only hostnames. All
utilities parse /etc/netgroup for either hosts or
usernames, but never both. Using separate netgroups makes it
easier to remember the function of each netgroup. The added time
required to administer these extra netgroups is a small cost to
ensure that strange permission combinations have not left your
machine in an insecure state. Refer to the manual pages for
more information.
- ENSURE that the permissions on this file are set to 600.
- ENSURE that the owner is set to root.
2.8 /etc/services
- ENSURE that the permissions on this file are set to 644.
- ENSURE that the owner is root.
2.9 /etc/hosts.lpd
- ENSURE that the owner is set to root.
- ENSURE that the permissions on this file are set to 600.
- ENSURE that you use fully qualified hostnames (i.e.
hostname.domainname.au).
- CONSIDER preventing lpd from listening to the network
unless necessary. It may be possible to accomplish this with
command-line arguments - refer to your vendor documentation or man
pages.
- DO filter the printer port (515/tcp) on your routers.
Many of the recent worms exploit buffer overflows in lpd.
2.10 /etc/login.access
- CONSIDER using this file as it provides finer control over
user access. Please refer to your vendor documentation for more
details. [NOTE: This file may not exist on all versions of Unix.]
- CONSIDER modifying this file to disallow remote access to
privileged accounts. An example to disallow non-local logins to
privileged accounts (group wheel):
-:wheel:ALL EXCEPT LOCAL
- ENSURE that the owner is set to root.
- ENSURE that the permissions on this file are set to 600.
- ENSURE that you use fully qualified hostnames or domains
(i.e. hostname.domainname.au or .domainname.au)
2.11 /etc/login.conf
- This file is used by default on some BSD systems, users
that are not created with a specified class are in the 'default'
class.
- DO use this file to set up user environment and to set
policy and accounting restrictions.
- ENSURE that the owner is set to root.
- ENSURE that the permissions on this file are set to 600.
- CONSIDER creating specific user classes to enable finer
control of users.
2.12 /etc/login.defs
- This file is used by some Linux systems.
- DO use this file to provide centralised control over user
environment settings.
- ENSURE that the owner is set to root.
- ENSURE that the permissions on this file are set to 600.
2.13 PAM (Pluggable Authentication
Modules)
2.14 cron
- ENSURE that the permissions for root's crontab are set to
600.
- ENSURE that the owner is set to root.
- CONSIDER disallowing cron for regular users.
2.15 Secure terminals
- This file may be called /etc/ttys,
/etc/default/login, /etc/security or
/etc/securetty depending on the operating system. See
the manual pages for file format and usage information.
- ENSURE that this file is owned by root.
- ENSURE that the permissions on this file are 600.
- DO NOT allow remote root access.
- ENSURE that the secure option is removed from all local
entries that don't need root login capabilities. The secure
option should be removed from console if you do not want users
to be able to reboot in single user mode. [NOTE: This does not
affect usability of the su(1) command.]
2.16 RPC
- ENSURE that your system is not running a vulnerable
rpc.statd. Refer to the AusCERT ESB:
ESB-2000.222
- DO use secure RPC for the running services where possible.
- DO filter port 111 (tcp) on your router to disable access
to RPC services from outside your network.
- 2.16.1 portmapper/rpcbind
- DON'T enable the portmap service unless
necessary. A machine that doesn't use the sunrpc
services (i.e. NFS or NIS) doesn't need portmap.
- DO disable any non-required services that are
registered with the portmapper on start up. See
C.2 for a command to help check for
registered services.
- CONSIDER replacing portmapper/rpcbind with a
more secure version which can restrict local forwarding
of rpc calls (indirect calls) and provides enhanced
logging. See A.2.11 for more info.
2.17 Trivial FTP (tftp)
- DO disable tftp if not needed, comment it out from the file
/etc/inetd.conf and restart the inetd process.
(Refer to C.1)
- If required, DO create a separate partition to store the
files to be served by tftp and limit the tftp daemon to the
directory where this partition is mounted.
- ENSURE that the files in the tftp area are not writable.
2.18 Majordomo
2.19 UUCP
- DO disable the uucp account, including it's login shell,
if it is not used at your site. Remember, uucp may be shipped in
a dangerous state.
- REMOVE any .rhosts file at the uucp home directory.
- ENSURE that the file L.cmds is owned by root.
- ENSURE that no uucp owned files or directories are world
writable.
- ENSURE that you have assigned a different uucp login for
each site that needs uucp access to your machine.
- ENSURE that you have limited the number of commands that
each uucp login can execute to a bare minimum.
- CONSIDER deleting the whole uucp subsystem if it is not
required.
- ENSURE there are no vendor-supplied uucp or root crontab
entries.
2.20 REXD
- DO disable this service. Comment this out in the
inetd.conf file. Refer to 2.1 for details
on how to do this. rexd servers have little or no security in
their design or implementation. Intruders can exploit this
service to execute commands as any user.
3.1 Packet Filtering
3.2 Denial of Service Attacks
- DO take steps to prevent your site being used to launch
denial of service attacks against other Internet sites.
- DO disable IP directed broadcasts for subnetworks within
your domain to prevent your network from being an intermediary
in certain types of denial of service attacks.
- For more information about IP directed broadcast and
associated denial of service attacks, see:
AusCERT Alert AL-98.01 - multiscan ('mscan') Tool
AL-98.01
CERT/CC Advisory CA-1998-01 - Smurf IP
Denial-of-Service Attacks
http://www.cert.org/advisories/CA-1998-01.html
AusCERT Alert AL-1999.001 - "sscan" scanning tool
AL-1999.001
RFC2644/BCP34 - Changing the Default for Directed
Broadcasts in Routers
http://rfc.net/rfc2644.html
UNIX IP Stack Tuning Guide v2.7 (Rob Thomas)
http://www.cymru.com/~robt/Docs/Articles/ip-stack-tuning.html
- DO use packet filters to allow ONLY packets with a
legitimate source IP address to originate (or transit) your
network. Many denial of service attacks depend on the ability for
an intruder to generate false, or spoofed, source IP addresses in
packets. For more information on anti-spoofing filters, see:
CERT/CC Advisory CA-1998-01 - Smurf IP Denial of Service
Attacks
http://www.cert.org/advisories/CA-1998-01.html
RFC2827/BCP38 - Network Ingress Filtering: Defeating Denial
of Service Attacks which employ IP Source Address Spoofing
http://rfc.net/rfc2827.html
- DO use packet filters to block incoming packets with
source IP addresses that are in well-known reserved address
space. The authoritative list of assigned and reserved address
space can be found at:
http://www.iana.org/assignments/ipv4-address-space
More information about address space allocated to private use can
be found at:
RFC1918 - Address Allocation for Private Internets
http://rfc.net/rfc1918.html
- DO take steps to prepare for responding to network-based
denial of service attacks, particularly attacks based on
distributed intruder tools.
Results of the Distributed-Systems Intruder Tools
Workshop:
http://www.cert.org/reports/dsit_workshop-final.html
3.3 Encryption and Strong
Authentication
- DO use encryption technologies when administrating
hosts and network equipment in your domain to prevent administrator
passwords and other sensitive information from crossing your
network in clear-text. Information on various methods is available
from:
http://www.sans.org/infosecFAQ/encryption/encryption_list.htm
- DO use strong authentication when accessing hosts in
your domain to reduce the risk of a security breach due to false
credentials.
- The SSH protocol employs public key cryptography and
provides both encryption and strong authentication. Refer to
A.2.13 for information on where you can
obtain ssh.
4.1 General
- DO consider using the EXINIT environment variable to
disable .exrc file functionality. These files may
inadvertently perform commands that may compromise the security of
your system if you happen to start either vi(1) or
ex(1) in a directory which contains such a file. See
C.11 for example commands to find .exrc
files.
- ENSURE that there are no .exrc files on your system
that have no legitimate purpose.
- ENSURE that any .forward files in user home directories
do not execute an unauthorised command or program. The mailer
may be fooled into allowing a normal user privileged access.
Authorised programs may be restricted through use of smrsh
(8.1 Sendmail). See C.12 for
example commands to find .forward files.
- ENSURE user or directories shared amongst users are not
specified before system directories in executable search paths
(allows installation of Trojan programs).
- DO consider using mount options, such as nosuid,
nodev and noexec for user home partitions,
/var and /tmp in your /etc/fstab or
vfstab file. (please refer to your specific operating
system's documentation for the exact file and location)
- DO consider setting filesystem limits. For example, by
enabling quota support for individual users or by using the
resource-limits PAM module.
4.2 Startup and Shutdown Scripts
- ENSURE that the default umask for all programs is 022.
4.3 External File Systems/Devices
- DO mount external file systems non-setuid and read-only
where practical. For more information, refer to
11.1.
4.4 File Permissions
- ENSURE that the permissions of /etc/utmp and
/var/adm/wtmp are set to 644.
- ENSURE that the permissions of /etc/motd and
/etc/mtab are set to 644.
- ENSURE that the permissions of /etc/syslog.pid
(/var/run/syslog.pid on some systems) are set to 644.
[NOTE: This may be reset each time you restart syslog.]
- CONSIDER removing read access to system configuration files
that users do not need to access, for example rc.* startup
files and authentication files like /etc/hosts.allow.
- ENSURE that logfiles (usually in /var/log/) are
only writable by root.
- CONSIDER using filesystem security features if your
operating system supports them - system binaries may be made
immutable, log files append-only.
- ENSURE that the kernel (e.g., /vmunix) is owned
by root, has group set to 0 (wheel on SunOS) and permissions set
to 644.
- ENSURE that /etc, /usr/etc, /bin,
/usr/bin, /sbin, /usr/sbin,
/tmp and /var/tmp are owned by root and that
the sticky-bit is set on /tmp and on /var/tmp
(see C.14) Refer to the AusCERT Advisory:
AA-95.07
- ENSURE that there are no unexpected world writable files
or directories on your system. See C.15 for
example commands to find group and world writable files and
directories.
- ENSURE that files which have the SUID or SGID bit set, need
to have it that way (see C.16). Remove this
bit from programs that do not require elevated privileges to
function successfully.
- ENSURE the umask value for each user is set to something
sensible like 027 or 077. (Refer to C.4
for a shell script to check this).
- ENSURE all files in /dev are special files.
Special files are identified with a letter (usually c for
'character' or b for 'block') in the first position of the
permissions bits. See C.17 for a command to
find files in /dev which are not special files or
directories. [NOTE: Some systems have directories and a shell
script in /dev which may be legitimate.] Please check
the manual pages for more information.
- ENSURE that there are no unexpected special files outside
/dev. See C.18 for a command to find
any block special or character special files.
4.5 Files Run by root
We recommend that any script or binary to be
executed by root should be owned by root and should not be world
or group writable. Additionally, this file should only be located
in a directory for which every parent directory is owned by root
and is not group or world writable.
- CHECK the contents of the following files for the root
account. Any programs or scripts referenced in these files should
meet the above requirements:
- ~/.login, ~/.profile and similar login
initialisation files
- ~/.exrc and similar program initialisation files
- ~/.logout and similar session cleanup files
- crontab and at entries
- files on NFS partitions
- /etc/rc* and similar system startup and shutdown files
- If any programs or scripts referenced in these files source
further programs or scripts they also need to be verified.
4.6 Bin Ownership
Many systems ship files and directories owned by bin (or sys).
This varies from system to system and may have serious security
implications.
- CHANGE all non-setuid files and all non-setgid files
and directories that are world readable but not world or
group writable and that are owned by bin to ownership of
root, with group id 0. - Please note that under Solaris
2.x changing ownership of system files can cause warning
messages during installation of patches and system packages.
One utility available to help Solaris administrators avoid
this problem is fix-modes (A.2.3).
Anything else should be verified with the vendor.
4.7 Tiger
- DO run Tiger or a similar program that can automatically
parse log files or check for vulnerable files. Many of the checks
in this section can be automated by using this type of program.
- To obtain this program, see A.1.14
4.8 Tripwire
- Tripwire is a file integrity checker, it is used for
intrusion detection by monitoring for file-system changes.
- DO run the statically linked binary.
- DO store the binary, the database and the configuration
file on hardware write-protected media.
- To obtain this program, see A.1.15
4.9 The Coroner's Toolkit
- A forensic analysis tool, written by Wietse Venema and Dan
Farmer. It may be used to statically examine storage devices from
a compromised system, or to monitor a running system for unusual
files or processes.
- DO run this tool for compromise recovery and analysis on
a non-networked machine.
- To obtain this program, see A.1.8
5.1 Policy
- ENSURE that you have a password policy for your site. See
the AusCERT Advisory:
SA-93.04
for guidelines on developing password policies.
- ENSURE you have a User Registration Form for each user on
each system. Make sure that this form includes a section that
the intending applicant signs, stating that they have read your
account usage policy and what the consequences are if they misuse
their account.
- DO use anlpasswd or a similar utility to proactively screen
passwords as they are entered. This program runs a series of
checks on passwords when they are set, which assists in avoiding
poor passwords. It works with normal, shadow and NIS (or yp)
password systems. (Refer to A.1.2
for how to obtain it)
- DO apply and enforce password aging.
- It is possible to implement both proactive password
screening and aging with Pluggable Authentication Modules (PAM).
This facility provides for other forms of access control - consult
the documentation if it is available for your system. Similar
functionality is available in the /etc/login.defs file
on some Linux systems.
- CONSIDER checking passwords periodically with Crack or
"John the Ripper" or other password cracking program. (Refer to
A.2.2 for how to obtain these programs).
Organisations may wish to incorporate this procedure into a
published security policy.
- DO implement the use of sudo in installations where
multiple users require the ability to run processes as root.
sudo allows for greater security by providing configurable
limitations on the use of the root account. sudo will also
log all attempts to use it via syslog or to a specified file.
sudo is available from:
http://www.courtesan.com/sudo/
http://www.stikman.com/sudo/
- CONSIDER implementing a Role Based Access Control mechanism
such as RBAC which was developed by the National Institute of Standards
and Technology (NIST). (Refer to A.2.12
for additional information)
5.2 Administration
- ENSURE that you regularly audit your system for
dormant accounts and disable any that have not been used
for a specified period of time, in accordance with your
site's security policy. Send out account renewal notices
by post and delete any accounts of users that do not respond.
[NOTE: Do not email renewal notices because any accounts
being used illegitimately will reply as expected and hence
will not be discovered.]
- ENSURE that all accounts have passwords. Check shadow, NIS,
and NIS+ passwords too, if you have them. (i.e. the password field
is not empty)
- ENSURE that any user area is adequately backed up and
archived.
- DO regularly monitor logs for successful and unsuccessful
su(1) attempts.
- DO regularly check for repeated login failures.
- DO regularly check for LOGIN REFUSED messages.
- Consider quotas on user accounts if you do not have them.
- Consider requiring that users physically identify
themselves before granting any requests regarding accounts
(e.g., before creating a user account).
5.3 Special Accounts
- ENSURE that there are no shared accounts other than root
in accordance with site security policy. (i.e. more than one
person should not know the password to an account)
- Disable guest accounts. Better yet, do not create guest
accounts! [NOTE: Some systems come preconfigured with guest
accounts.]
- DO use special groups (such as the "wheel" group under
FreeBSD) to restrict which users can use su to become root.
- DISABLE ALL default vendor accounts shipped with the
Operating System. This should be checked after each upgrade or
installation.
- DO disable accounts that have no password which execute a
command, for example "sync". Delete or change ownership of any
files owned by these accounts. Ensure that these accounts do
not have any cron or at jobs. It is best to remove these
accounts entirely.
- DO assign non-functional shells (such as /bin/false)
to system accounts such as bin and daemon and to the sync account
if it is not needed.
- DO put system accounts in the /etc/ftpusers file
so they cannot use ftp. This should include, as a MINIMUM, the
entries: root, bin, uucp, ingres, daemon, news, nobody and ALL vendor
supplied accounts.
5.4 root Account
- DO restrict the number of people who know the root
password. These should be the same users registered with
groupid 0. Typically this is limited to at most 3 or 4 people.
- DO NOT log in as root over the network, in accordance
with site security policy.
- DO su from user accounts rather than logging in
as root. This provides greater accountability.
- ENSURE root does not have a ~/.rhosts file.
- ENSURE "." is not in root's search path.
- ENSURE root's login files do not source any other files
not owned by root or which are group or world writable.
- ENSURE root cron job files do not source any other files
not owned by root or which are group or world writable.
- DO use absolute path names when root. (e.g.
/bin/su, /bin/find, /bin/passwd.) This
is to stop the possibility of root accidentally executing a trojan
horse. To execute commands in the current directory, root should
prefix the command with "./" (e.g. ./command)
5.5 .netrc Files
- DO NOT use .netrc files unless it is absolutely
necessary.
- If .netrc files must be used, DO NOT store
password information in them.
5.6 GCOS Field
- DO include information in the GCOS field of the password
file which can be used to identify your site if the password
file is stolen. e.g., joe:*:10:10:Joe Bloggs, Organisation
X:/home/joe:/bin/sh
5.7 Authentication
- 5.7.1 NIS, NIS+ and
/etc/passwd Entries
- DO NOT run NIS or NIS+ if you don't really need
it.
- If NIS functionality is required, DO use NIS+ if
possible due to the additional security features provided.
- ENSURE that the only machines that have a '+'
entry in the /etc/passwd files are NIS (YP) clients;
(i.e. NOT the NIS master server!) There appears to be
conflicting documentation and implementations regarding
the '+' entry format and so a generic solution is not
available here. It would be best to consult your
vendor's documentation. Some of the available
documentation suggests placing a '*' in the password
field, which is NOT consistent across all
implementations of NIS. We recommend testing your
systems on a case-by-case basis to see if they correctly
implement the '*' in the password field. See
C.10 for instructions.
- ENSURE that /etc/rc.local or the equivalent
startup procedure is set up to start ypbind with the -s
option. This may not be applicable on all systems.
Check your documentation.
- DO use secure RPC if available for your platform.
This is also known as DES authentication and is a Sun
Microsystems secure authentication mechanism for RPC. It
depends on synchronised clocks and a shared DES key.
See the manpage for nisaddcred for more info.
- 5.7.2 Password Shadowing
- DO enable vendor supplied password shadowing or a
third party product. Password shadowing restricts access
to users' encrypted passwords.
- DO periodically audit your password and shadow
password files for unauthorised additions or
inconsistencies.
- 5.7.3 One-Time Passwords
- CONSIDER using One-Time Passwords if users log
into your machine via an insecure connection or protocol
(such as telnet or ftp).
- NEVER generate the master key or password lists
over an insecure connection or protocol - these should
be done locally on a secure (preferably not networked)
machine.
- ENSURE your users do not store password lists on
or near their computer.
- Minimise the number of passwords given to each
user.
- CONSIDER imposing a limit to the number of sequential
failed logins. [NOTE: This has the possibilities of creating
a DoS situation.]
- A commonly used free version is Secure Key
(S/KEY). This is implemented by default in the FreeBSD
operating system. See A.2.8.
- One-Time Passwords in Everything (OPIE) is
another free implementation of non-replayable passwords.
See A.2.8.
- 5.7.4 Lightweight Directory
Access Protocol (LDAP)
- LDAP is a protocol for accessing online directory
services.
- LDAP supports encryption and access control lists.
- ENSURE that you provide access controls for services
provided by an LDAP server.
- An open-source implementation of LDAP is available from:
http://www.openldap.org/
- A historical reference page for LDAP is at:
http://www.umich.edu/~dirsvcs/ldap/
DISCLAIMER: We recommend you consult your organisation's
security and privacy polices, as well as any laws for your area before
implementing any of the suggestions in this section.
6.1 Account Security
- DO regularly expire user passwords.
- CONSIDER performing periodic checks of password security
by running a cracking tool - for example, Crack or "John the
Ripper" (See A.2.2) - against your password file.
- CONSIDER enabling auditing capabilities if available for
your system - Solaris for example has a C2 auditing facility.
- DO actively monitor processes on your machines - tools
are available that make it possible to do this remotely, like
Big Brother (See A.1.3)
- DO run process accounting.
- CONSIDER logging all login attempts, both successful and
unsuccessful.
- DO examine accounting logfiles for activity, for example
for su attempts.
- CONSIDER disabling accounts after a number of failed
login attempts. [NOTE: This has the possibilities of creating a DoS
situation.]
6.2 Log Files
- DO make use of facilities provided with your operating
system to assist with disseminating log files e.g. FreeBSD emails
a summary of important system and security information to root
as part of its pre-configured crontab.
- DO use a reliable mechanism for log rotation. This may
include replacing an existing logging daemon with a more secure
or full-featured one.
- DO use network and system daemons that have more
comprehensive logging features, such as logdaemon
(See A.2.4) and tcp wrappers (See
A.1.13).
- DO make use of syslog facilities for network logging and
log to more than one host if possible.
- CONSIDER protecting your logfiles with filesystem security
if possible, for example FreeBSD and Linux support flags to make
files append-only.
6.3 Network Security
- DO use utilities to enable output profiling of log data,
such as ISS (See A.3.1.3) or SAINT (See
A.3.2.2).
- CONSIDER implementing automated reporting facilities so
that scans of your network are reported to the administrators of
their originating domains.
- DO check system files for modification regularly, using
tools like Tripwire (See A.1.15).
- DO keep a logbook of all sysadmin activity on each host
on your network.
- lsof (See A.2.5) is a tool for monitoring open
system files and may be used to check for any suspicious activity.
- DO thoroughly document any procedures associated with
system modifications or upgrades.
7.1 BIND
7.2 Alternatives
8.1 Sendmail
- DO use the latest version of Eric Allman's sendmail.
The latest version is available via anonymous FTP from:
http://www.sendmail.org/
NOTE: If you don't already run the current version of sendmail,
then it may take you some time to build, install, and configure
the system to your needs. For example, other sendmail configuration
files may not be compatible with the latest version of sendmail.
- If you use a vendor version of sendmail, ENSURE that you
have installed the latest patches as sendmail has been a
source of several security vulnerabilities.
- DO use smrsh if you require progmailer functionality to
limit sendmail's scope of program execution to programs in smrsh
configuration only. smrsh is a restricted shell utility that may
be configured to execute a specific list of programs. smrsh is
included with recent versions of sendmail.
- If you do not require progmailer functionality then DO
disable mail to programs by setting this field to
/bin/false in the sendmail configuration file.
- ENSURE sendmail is configured to deny relaying from
unknown hosts. This helps to prevent your mail server from
being used inappropriately. (e.g. for spam/UCE)
- DO increase sendmail logging to a minimum log level
of 9. This will help detect attempted exploitation of the
sendmail vulnerabilities. See C.5 for
example commands.
- DO increase the level of logging provided by syslog.
Enable a minimum level of "info" for mail messages to be logged
to the console and/or the syslog file. See C.6
for example code and instructions.
- CONSIDER disabling the daemon mode on client hosts. This
will still allow clients to use sendmail for mail delivery. If
this is implemented, CONSIDER adding sendmail -q to your
crontab to ensure delayed messages are delivered.
- REMEMBER that you will need to restart sendmail for any
changes to take effect. If you are running a frozen
configuration file (sendmail.fc), you will need to rebuild it
before restarting sendmail (C.7). Note
that sendmail v8.x no longer supports frozen configuration files.
- 8.1.1 /etc/aliases
- ENSURE that all programs executable by an alias
are owned by root, have permissions 755 and are stored in
a directory specified by smrsh configuration e.g.,
/usr/libexec/sm.bin. Refer to your
sendmail documentation for more details (8.1
Sendmail).
8.2 Alternatives (qmail and postfix)
- 8.2.1 qmail by D. J.
Bernstein
- DO use the latest version of qmail.
It is available at:
http://cr.yp.to/qmail.html
- Make sure you read all the documentation before you
even begin to install and compile it.
- It is recommended that qmail be used with
tcpserver instead of inetd. It is available at:
http://cr.yp.to/ucspi-tcp.html
- qmail contains a sendmail 'dropin' to make
conversion between the two transparent to users.
- 8.2.2 postfix by Wietse
Venema
- DO use the latest version of postfix. To find your
nearest anonymous FTP site for download, see:
http://www.postfix.org/ftp-sites.html
- ENSURE you have installed the relevant patches.
See postfix's download page (above) for more information.
- postfix's homepage can be found at:
http://www.postfix.org
- postfix has been designed to avoid common
security problems such as shell access, set-uid, buffer
overruns and DoS.
- If you are thinking of using postfix instead of
sendmail, read the documentation found on the postfix
website and the mailing lists.
8.3 POP/IMAP
- ENSURE that you have the latest version of your POP/IMAP
software - there are known vulnerabilities in some previous and
some obsolete POP/IMAP implementations. Ask your vendor for details
if you are unsure.
9.1 General Configuration
- 9.1.1 chroot
- DO consider running the web server as a chrooted
process. Changing the root environment so that the http
service runs in a properly restricted area can minimise
damage resulting from a compromised web server.
- CONSIDER placing static files onto a read-only
media, such as a hardware write-protected hard disk or
CD-ROM.
- 9.1.2 CGI Programming
- ENSURE the server is configured to execute only
those CGI scripts which reside in the CGI binary directory,
e.g., /cgi-bin. Set the ownership and permissions
on this directory to 755 or 751. Consider monitoring
changes to these scripts with such programs as Tripwire.
- ENSURE that all default or example CGI scripts
are backed up and removed if not needed or thoroughly
tested for signs of bad programming practices (refer
point below).
- DO audit CGI scripts for bad programming
practices, for example, the use of:
- within perl - eval, exec, open() to a pipe,
backticks, and the regular expression modifier
/e all may fork a process. These can
potentially be subverted to allow an attacker to
run an arbitrary command
- within C and C++ - popen() and system() are
at risk in a similar manner as perl above and
can be subverted easily to allow shell access.
- DO test for untrustworthy user input. For example:
- unexpected input values - may cause the
script to perform actions which were not
intended by the author;
- special characters - may allow unauthorised
access. A preferred alternative to checking for
a list of dangerous/special characters is to
specify a list of allowable characters;
- unexpectedly large input - may cause buffer
overflow or inappropriate actions;
- any other potential abuses.
- DO use the tainting feature of Perl. CGI scripts
written in Perl should be invoked with perl -T.
- DO consider implementing CGI wrappers. Wrappers
can be used to perform security checks on the script, e.g.
- change the ownership of the CGI process, or use chroot
as discussed above.
- CONSIDER reading available documents on the Internet
regarding secure programming. See B.2.5
- 9.1.3 daemon non-root uid
- ENSURE that you DO NOT run your web service as
root. The UID and GID of the service should be changed,
after it has been started, to a user and group that has
no privileged access on the server. The most popular Unix
web server, Apache, lowers its ownership level immediately
after starting - it still must be invoked as root to allow
it to bind to a privileged port. This avoids the risk of
any scripts the web service executes running as root.
- DO set up script directories (e.g cgi-bin) to be
owned by root and set permissions to 751. This prevents
users from viewing contents of the directory whilst
allowing the daemon to run the scripts within it.
Additionally, if the server is compromised by sending
unexpected input to a CGI script, the user that is running
the server has no permission to edit or remove files from
the script area.
- DO set up the web server directory with root
ownership.
- ENSURE configuration, log, and binary files for the
web server are owned by root and set permissions to 755.
- 9.1.4 Command Interpreters
- ENSURE that shells and command interpreters are
removed from the web documents path.
- CONSIDER running the web server machine solely for
the purpose of being a web server (e.g. - do not run any
other services such as mail, DNS etc) For such a server
also remove all unnecessary accounts, unnecessary
utilities, programs, compilers etc. and do not export any
directories.
- 9.1.5 SSL
- DO consider using SSL (Secure Socket Layer) for
encrypting any TCP/IP protocols in use. SSL can be used
for server authentication, client authentication, and
transmitting encrypted data.
- DO consider using SHTTP (Secure HTTP).
- 9.1.6 Additional Configuration
Matters
- DO consider configuring the web server to not
allow automatic directory listing if an index.html file
is not present in the directory.
- DO consider configuring the web server to not
follow symbolic links. This prevents a user with access
to the web server's document tree from making other
documents, outside the tree, available via symbolic
links.
- DO consider preventing or limiting use of
server-side includes. Some web servers can be
configured to limit processing of server-side includes
to specific directories.
- ENSURE that the directory of the documents served
by the web server is not also available via anonymous
FTP. Any restrictions to access to the documents set by
the web server would be circumvented by anonymous FTP.
9.2 Freely Available Servers
9.3 Client Configuration
- DO NOT allow external programs to spawn for any downloaded
files or content that contain executable material.
- ENSURE web browsers are NOT configured to automatically
run files when downloaded from the Internet. This includes not
allowing browsers to automatically launch command line shells,
interpreters, macro processors, and scripting language processors.
This may be achieved using the application preferences for the
browser.
- DO consider terminating connections to secure pages if the
web browser alerts that the host name in site certificate does
not match the host name of the server the certificate came from.
- DO consider rejecting site certificates signed by an unknown
certifying authority.
- ENSURE Java, JavaScript ActiveX are disabled in the web
browser and built-in email readers that may come with the
browser.
- If you MUST enable Java, JavaScript, or ActiveX ENSURE you
are running the latest version of your browser and respective
run-time environments. This includes all related security patches.
- DO NOT run a web browser as root.
- CONSIDER removing cookies on a periodic basis.
Alternatively consider making a symbolic link between the cookies
file (e.g. ~/.netscape/cookies) and /dev/null.
- DO consider utilising anti-virus software.
- ENSURE web browsers are patched against the latest known
security vulnerabilities.
10.1 General Server Configuration
10.2 Incoming Directories
- ENSURE that you don't have any writable directories. It
is safest not to have any writable directories. If you do have
any, we recommend that you limit the number to one, for instance
an 'upload' directory.
- ENSURE that writable directories are not also readable.
Directories that are both writable and readable may be used in an
unauthorised manner.
- ENSURE that any writable directories are owned by root
and have permissions 1733.
- DO put writable directories on a separate partition if
possible. This will help to prevent denial of service attacks.
10.3 Freely Available Servers
- 10.3.1 WU-FTP
- Make sure you are using the latest version of
WU-FTPD and have applied all recommended patches. Versions of
WU-FTPD prior to 2.6.1 have known security vulnerabilities.
- WU-FTPD can be found at:
http://www.wu-ftpd.org
- 10.3.2 ProFTPD
- ProFTPD does not support the SITE EXEC command.
- ProFTPD can use mySQL password databases instead
of password files, although at the time of writing there
are a few known bugs, and compilation of ProFTPD with
mySQL support can be difficult.
- There are several mailing lists for ProFTPD,
including development and help lists.
- DO install the latest version of ProFTPD - previous
versions are known to have bugs that may lead to security
problems (but are more likely to cause problems in use.)
- ProFTPD can be found at:
http://www.proftpd.net/
- 10.3.3 Publicfile
10.4 Anonymous FTP Only
- To ascertain whether you are running anonymous FTP, try
to connect to the localhost using anonymous FTP. Be sure to give
an RFC822 compliant username as the password (See
C.9).
- To disable anonymous FTP, move or delete all files in
~ftp/ and then remove the user ftp from your password file.
- If you are running distributed passwords (e.g. NIS, NIS+)
then you will need to check the password entries served to your
machine as well as those in your local password file.
- ENSURE that if you want to use anonymous FTP you have
configured your server correctly. In general, anonymous users
should not be allowed to create directories, delete anything,
change the file system in any way (for instance change the
permissions of a file) or upload files. If you do want anonymous
users to upload files, follow the instructions above about general
server configuration.
- Limit the number of anonymous connections allowed, and
also the number of times a single IP can be logged in at once.
Anonymous should only be allowed to have one session active at a
time - otherwise you leave yourself open to a DoS attack.
11.1 NFS
When using NFS, you implicitly trust the security of the NFS server
to maintain the integrity of the mounted files.
- DO filter NFS traffic at the router. Filter TCP/UDP on
port 111 TCP/UDP on port 2049 This will prevent machines not on
your subnet from accessing file systems exported by your
machines.
- DO apply all available patches. NFS has had a number of
security vulnerabilities.
- DO disable NFS if you do not need it. See your vendor
supplied documentation for detailed instructions.
- DO enable NFS port monitoring. Calls to mount a file
system will then be accepted from ports < 1024 only. This will
provide added security in some circumstances. See your vendor's
documentation to determine whether this is an option for your
version of UNIX (see also 15.4).
- DO use /etc/exports or /etc/dfs/dfstab to
export ONLY the file systems you need to export. If you aren't
certain that a system needs to be exported, then it probably shouldn't
be exported.
- DO NOT self-reference an NFS server in its own exports
file (i.e. the exports file should not export the NFS server
to itself in part or in total). In particular, ensure the NFS
server is not contained in any netgroups listed in its exports
file.
- DO NOT allow the exports file to contain a 'localhost' entry.
- DO export to fully qualified hostnames only (i.e. use
the full machine address 'machinename.domainname.au' and do not
abbreviate it to 'machinename').
- ENSURE that you never export file systems unintentionally
to the world. Use a -access=host.domainname.au option or
equivalent in /etc/exports.
- DO export file systems read-only (-ro) whenever possible.
See the manual page for exports or dfstab for more
information.
- If NFS is required in your situation, then DO use the
secure option in the exports file and mount requests (if the
secure option is available).
- DO use showmount -e to see what you currently have
exported.
- ENSURE that the permissions of /etc/exports are set
to 644.
- ENSURE that /etc/exports is owned by root.
- ENSURE that you run a portmapper or rpcbind that does not
forward mount requests from clients. A malicious NFS client can
ask the server's portmapper daemon to forward requests to the
mount daemon. The mount daemon processes the request as if it
came directly from the portmapper. If the file system is
self-mounted this gives the client unauthorised permissions to
the file system. Refer to A.2.11 for how to
obtain an alternate portmapper or rpcbind that disallow proxy access.
- REMEMBER that changes in /etc/exports will take effect
only after you run /usr/etc/exportfs or equivalent.
- You may wish to test your NFS implementation with NFSbug, a
program which scans for known NFS holes. It is available from:
ftp://ftp.cs.vu.nl/pub/leendert/nfsbug.shar
NOTE: A "web of trust" is created between hosts connected to
each other via NFS. That is, you are trusting the security of
any NFS server you use.
11.2 Alternatives
- 11.2.1 Samba
The Samba service provides filesystem shares to clients that
are running other operating systems, usually a version of Microsoft
Windows.
- DO enable encrypted passwords for Samba using
smbpasswd.
- DO configure your shares for user-level security
using the
security = user
parameter in smb.conf.
- DO restrict access to your Samba service with the
parameters:
hosts allow =
hosts deny =
- DO protect your Samba services with firewall
rules - Samba file services use NetBIOS over TCP/IP
(also referred to as NBT and NetBT), so ports 135, 137,
138, and 139 (TCP) should be filtered.
- CONSIDER using stronger authentication methods.
Samba supports alternative authentication models,
including Kerberos and Pluggable Authentication Modules
(PAM).
- CONSIDER encrypting your Samba traffic. Samba
supports the Secure Sockets Layer (SSL) protocol.
Samba sources and documentation are available from:
http://www.samba.org/
- 11.2.2 Andrew File System
(AFS)
AFS is a distributed filesystem that makes use of Kerberos to
authenticate users. It allows the use of access control lists
(ACLs). It is available from the Transarc Corporation.
- CONSIDER using AFS if it is available for your
platform and appropriate for your needs.
Information is available from:
ftp://ftp.transarc.com/pub/afs-contrib/doc/faq/afs-faq.html
http://www.transarc.ibm.com/Product/EFS/AFS/index.html
- 11.2.3 DFS
DFS is a distributed filesystem, also available from the
Transarc Corporation. Information is available from:
http://www.transarc.ibm.com/Product/EFS/DFS/index.html
Access to your X server may be controlled through either a
host-based or user-based method. The former is left to the
discretion of the Systems Administrator at your site and is
useful as long as all hosts registered in the
/etc/Xn.hosts file have users that can be trusted,
where "n" represents your X server's number.
This may not be possible at every site, so a better method is
to educate each and every user about the security implications
(see references below). Better still, when setting up a user,
give them a set of X security related template files, such as
.xserverrc and .xinitrc. These are located in the users home
directory.
You are strongly advised to read the section on X window system
security referred to in the X Window System Administrators Guide
(B.1.4).
12.1 X Security - General
- DO read the man pages for xauth and Xsecurity. Use this
information to set up the security level you require.
- ENSURE that the permissions on /tmp are set to 1777.
(i.e. the sticky bit should be set) The owner MUST always be root
and group ownership should be set to group-id 0 or "system".
If the sticky bit is set, no one other than the owner
can delete the file /tmp/.X11-unix/X0, which is a socket
for your X server. Once this file is deleted, your X server will no
longer be accessible. See C.14 for example commands
to set the correct permissions and ownership for /tmp.
- DO use the X magic cookie mechanism MIT-MAGIC-COOKIE-1 or
better. With logins under the control of xdm (see
12.2), you can turn on authentication by editing the xdm-config
file and setting the DisplayManager*authorize attribute to
true. When granting access to the screen from another machine, use
the xauth command in preference to the xhost command.
- DO not permit access from arbitrary hosts. Remove all
instances of the xhost + command from the system-wide Xsession
file, from user .xsession files, and from any application
programs or shell scripts that use the X window system.
- CONSIDER encrypting your X network traffic, especially if
you run remote clients locally. Ssh is a useful method.
- CONSIDER configuring workstations to disable listening
for incoming X sessions over the network. This is done on some
operating systems by using the -nolisten tcp option.
You should consult your specific operating system's documentation
for specific instructions.
12.2 Problems with xdm
DO not use any version of X11 prior to release 6 as it resolved
security problems that existed in earlier versions. If
necessary, obtain the source for X11R6 and compile and install
it on your system. This may be obtained from:
http://www.x11.org
- xdm bypasses the normal getty and login
functions, which means that quotas for the user, ownership of
/dev/console and possibly other preventive measures put in
place by you may be ignored.
- You should consult your vendor and ask about potential
security holes in xdm and what fixes are available.
- Newer window managers that are available for Unix and
Unix clones are provided with different X display managers (e.g. gdm,
the Gnome project item) so you should check that there are no
vulnerabilities specific to the instance of display manager that you
choose.
13.1 BSD/OS
13.2 FreeBSD
13.3 NetBSD
13.4 OpenBSD
14.1 Caldera OpenLinux
14.2 Debian GNU/Linux
Security information for Debian GNU/Linux, including links to
security bulletins, patches and updates can be found at:
http://www.debian.org/security/
14.3 Mandrake Linux
14.4 RedHat Linux
14.5 Slackware Linux
14.6 SuSE Linux
Security information for SuSE Linux, including links to advisories,
patches, and updates can be found at:
http://www.suse.com/us/support/security/index.html
14.7 TurboLinux
Security information for TurboLinux, including links to advisories,
patches, and updates can be found at:
http://www.turbolinux.com/security/
14.8 Others
For other distributions of Linux, please refer to your
vendor's website. A useful starting point for finding Linux
distribution vendor's sites is:
http://www.linux.org/dist/index.html
15.1 Patches
15.2 IP Forwarding and Source Routing
This is particularly relevant if you are using your Sun server
as a bastion host or dual homed system.
15.3 Stack Execution
15.4 NFS Port Monitoring
- DO enable NFS port monitoring. To do this add the following line to
/etc/system:
set nfs:nfs_portmon = 1
set nfssrv:nfs_portmon = 1
See also 11.1.
15.5 Framebuffers /dev/fbs
- Solaris versions 2.3 and above have a protection
facility for framebuffers which is a superset of the
functionality provided by /etc/fbtab in SunOS 4.1.x.
- Under Solaris, /dev/fbs is a directory that contains
links to the framebuffer devices. The /etc/logindevperm file
contains information that is used by login(1) and
ttymon(1M) to change the owner, group, and permissions of
devices upon logging into or out of a console device. By default,
this file contains lines for the keyboard, mouse, audio, and
frame buffer devices.
A sample /etc/logindevperm file:
#
# File: /etc/logindevperm
# Purpose: Specifies that upon login to /dev/console, the
# owner, group and permissions of all supported
# devices, including the framebuffer, will be set to
# the user's username, the user's group and 0600.
# Comments: SunOS specific.
# Note: You cannot use to continue a line.
#
# Format:
# Device Permission Colon separated device list.
#
/dev/console 0600 /dev/kbd:/dev/mouse
/dev/console 0600 /dev/sound/* # audio devices
/dev/console 0600 /dev/fbs/* # frame buffers
Read the man page for logindevperm(4) for more information.
15.6 Security Bulletins
15.7 Sun BluePrints
15.8 Solaris Security Toolkit (JASS)
- The Solaris Security Toolkit, informally known as the JumpStart
Architecture and Security Scripts (JASS) toolkit, provides a
flexible and extensible mechanism to minimise, harden, and secure
Solaris Operating Environment systems. The primary goal behind the
development of this toolkit is to simplify and automate the process of
securing Solaris systems. Additional information and downloads are
available from:
http://www.sun.com/security/jass/
16.1 Patches
16.2 Default Account Security
16.3 Security Advisories
17.1 Patches
18.1 Patches
19.1 Patches
19.2 Security Advisories
There are many freely available tools that provide a good
mechanism for checking the security of your system.
The list below is not a complete list, and you should NOT rely on
these to do ALL of your work for you. They are intended to be only
a guide. It is envisaged that you may write some site specific tools
to supplement these. It is also envisaged that you may look around
on HTTP or FTP servers for other useful tools.
AusCERT and CERT/CC have not formally reviewed, evaluated or
endorsed the tools described herein. The decision to use these
tools is the responsibility of each user or organisation.
- A.2.1 chrootuid
Allows chroot functionality.
It is available from:
ftp://ftp.porcupine.org/pub/security/
- A.2.2 Crack and "John the Ripper"
Crack is a fast password cracking program
designed to assist site administrators in ensuring that
users use effective passwords. Available via anonymous
FTP from:
ftp://coast.cs.purdue.edu/pub/tools/unix/pwdutils/
John the Ripper is a password cracker, designed to
detect weak Unix passwords. It is available from:
http://www.openwall.com/john/
- A.2.3 FixModes
The FixModes scripts run on Solaris and remove group and world
write permissions on specific system files and directories.
The new permissions make it harder for non-root users to become root,
and for non-root users to modify system files. FixModes is available
from:
http://www.sun.com/blueprints/tools/
- A.2.4 logdaemon
Written by Wietse Venema, this package includes replacements
for rsh and rlogin daemons. By default these versions do not
accept wild cards in host.equiv or .rhost files.
They also have an option to disable user .rhost files. logdaemon is
available via anonymous FTP from:
ftp://ftp.porcupine.org/pub/security/
- A.2.5 lsof
lsof reports files open by a process, files open on a partition
as well as processes listening on a port/socket and processes which
have a file open. Available via anonymous FTP from:
ftp://coast.cs.purdue.edu/pub/tools/unix/sysutils/lsof/
- A.2.6 MD5
MD5 is a message digest algorithm. Tools to verify MD5 checksums
are included with many current operating systems, for example
md5(1) (FreeBSD) or md5sum (Linux). Otherwise, an
implementation of MD5 is available via anonymous FTP from:
ftp://coast.cs.purdue.edu/pub/tools/unix/crypto/md5/
- A.2.7 noshell
This program
is designed to provide the system administrator with additional
information about who is logging into disabled accounts. It is used
as a replacement shell, to be specified in the login shell entry for
the account in the unix password file. It is available from:
http://www.fish.com/titan/src1/noshell.c
Detailed instructions on installing and usage of noshell are
available from:
http://www.cert.org/security-improvement/implementations/i049.02.html
- A.2.8 OPIE and S/KEY
The S/KEY one-time password system provides authentication
over networks that are subject to eavesdropping/reply
attacks. This system has several advantages compared with
other one-time or multi-use authentication systems. The
user's secret password never crosses the network during
login. This directory contains information, the latest
version and patches.
It is available via anonymous FTP from:
ftp://ftp.cert.dfn.de/pub/tools/password/SKey/
OPIE is an implementation of the One-Time Password (OTP) standard
specified in RFC 1938. Available via anonymous FTP from:
http://www.inner.net/pub/opie/
- A.2.9 overflow_wrapper
AusCERT designed this wrapper to limit exploitation of programs
which have command line argument buffer overflow vulnerabilities.
It is available from:
http://www.auscert.org.au/render.html?it=2016
- A.2.10 PGP/GnuPG
PGP Pretty
Good Privacy implements encryption and authentication. GnuPG is a
similar utility released under the GNU public licence.
PGP is available from:
http://www.pgpi.org/
GnuPG is available from:
http://www.gnupg.org/
- A.2.11 portmapper/rpcbind
These are portmapper/rpcbind replacements written by Wietse
Venema that disallow proxy access to the mount daemon via the
portmapper. Choose the one suitable for your system. They are
available via anonymous FTP from:
ftp://ftp.porcupine.org/pub/security/
- A.2.12 RBAC
Role Based Access Control (RBAC) allows each user to be assigned
one or more roles and each role is assigned one or more privileges
that are permitted to users in that role. Security administration
with RBAC consists of determining the operations that must be
executed by persons in particular jobs, and assigning employees to
the proper roles. Complexities introduced by mutually exclusive roles
or role hierarchies are handled by the RBAC software, making security
administration easier. Additional information and downloads are
available from:
http://csrc.nist.gov/rbac/
- A.2.13 ssh
Secure Shell (ssh) provides for encrypted remote communications
between hosts. It can replace rsh, rlogin, and others. It is
available from:
http://www.ssh.fi/
http://www.openssh.com/
http://www.ssh.com/
- A.3.1 Intrusion Detection Systems (IDS)
- A.3.2 Vulnerability Scanning Tools
- A.3.2.1 Nessus
Nessus is a free, programmable graphical vulnerability
assessment and scanning tool. It offers a number of features,
such as a modular architecture, and its own scripting language.
Nessus is available at:
http://www.nessus.org/
- A.3.2.2 SAINT
SAINT is a vulnerability assessment tool, similar to SATAN,
which allows network administrators to scan their networks for
known vulnerabilities in specific software packages. More
information is available at:
http://www.wwdsi.com/saint
- A.3.2.3 SARA
The Security Auditor's Research Assistant (SARA) is another
vulnerability assessment and scanning tool. It supports the
use of CVE nomenclature among other things. More information
is available at:
http://www-arc.com/sara/
- A.3.2.4 bv-Control
bv-Control from BindView is a cross-platform package
that provides vulnerability assessments as well as
assiting in routine system administration. More information
is available at:
http://www.bindview.com/products/control/
- A.3.3 Other Useful Tools
- A.3.3.1 Argus
Argus is an advanced IP network transaction auditing tool.
Classified as a Real Time IP Flow Monitor, Argus generates a
persistent audit of all network transactions and their
performance, without the need for configuration.
The data that Argus generates can be used for a wide range
of tasks that are traditionally benefited from audit, of
particular interest are Network Security and Network Assurance
and Performance Management. Argus is available at:
ftp://ftp.andrew.cmu.edu/pub/argus/
- A.3.3.2 Ethereal
Ethereal is a free network protocol analyzer for Unix and
Windows. It allows you to examine data from a live network
or from a capture file on disk. You can interactively browse
the capture data, viewing summary and detail information
for each packet. Ethereal has several powerful features,
including a rich display filter language and the ability to
view the reconstructed stream of a TCP session. More
information is available from:
http://www.ethereal.com/
- A.3.3.3 ifstatus
ifstaus can be run on a UNIX system to check the network
interfaces for any that are in debug or promiscuous mode. This
may be the sign of an intruder performing network monitoring
to steal passwords and the like (see CERT/CC Advisory CA-1994-01).
ifstatus is available from:
ftp://coast.cs.purdue.edu/pub/tools/unix/sysutils/ifstatus/
- A.3.3.4 AntiSniff
AntiSniff is a tool which can scan a network and detect
whether or not the network interfaces on any computers are in
promiscuous mode, since this is often a sign that a computer
has been compromised.
Antisniff was designed to detect compromised machines with
IP stacks that a remote attacker could utilize to sniff
network traffic. It was not designed to detect hardware based
network probes or special purpose network analysers which an
attacker would need physical access to install.
More information is available from:
http://www.securitysoftwaretech.com/antisniff/
- A.3.3.5 Network Operations
Center On-Line (NOCOL)
Network Operation Center On-Line (NOCOL) is a network
monitoring package that runs on Unix platforms. It can monitor
various network variables such as ICMP or RPC reachability,
nameservers, ethernet load, port reachability, host
performance, SNMP traps, modem line usage, appletalk &
novell routes and services, BGP peers, etc. The software is
extensible and allows new monitors to be added. NOCOL is
available from:
ftp://ftp.netplex-tech.com/pub/
Additional information is available from:
http://www.netplex-tech.com/software/nocol/
- A.3.3.6 Nmap
Nmap is an open-sourced tool for port scanning large
networks. It features a variety of modes of scanning and
remote operating system identification. More information
is available from:
http://www.nmap.org/
- A.4.1 Proxy Servers
Proxy servers can be used to authenticate and forward
specific service requests between networks. Typically, a
proxy server replaces a regular system service and then
arbitrates sessions between legitimate clients and servers.
Proxy servers are often used in conjunction with packet
filtering tools (See A.4.2) to enforce
network security policies. Many commercial and non-commercial
packages offer proxy server functionality. Below are pointers to
several non-commercial software packages that perform proxy
services.
- A.4.2 Packet Filtering Tools
Packet filtering tools provide the ability to selectively
control the forwarding TCP/IP packets through a device with two or
more network interfaces. Packet filtering can be used to enforce
network security policies through the construction and use of a
series of packet filtering rules. Many commercial and
non-commercial packages offer packet filtering functionality. Below
are pointers to several non-commercial software packages that perform
packet filtering.
- A.4.2.1 ipfw
ipfw is an older packet filtering tool distributed as a
part of some BSD-based operating systems, particularly FreeBSD.
Information about ipfw is available from the FreeBSD
Handbook.
http://www.freebsd.org/handbook/firewalls.html
- A.4.2.2 ipfwadm
Ipfwadm is a packet filtering tool distributed as a
part of some older Linux distributions. It is designed
for use with older (e.g., prior to version
2.2.x) Linux kernels. Information about ipfwadm
is available from the author's website:
http://www.xos.nl/linux/ipfwadm/
- A.4.2.3 IP Filter (ipf)
IP Filter, or ipf, is a packet filtering tool
distributed as a part of BSD-based operating
systems such as FreeBSD, OpenBSD, and NetBSD. It
is also available for use on other platforms
such as Solaris, SunOS, IRIX, and HP-UX. More
information is available from:
http://coombs.anu.edu.au/~avalon/
- A.4.2.4 ipchains
Ipchains is a packet filtering tool distributed as a
part of many current Linux distributions. It is
designed for use with newer (e.g., version
2.2.x) kernels. Information about ipchains is
available from one of several locations:
http://netfilter.filewatcher.org/ipchains/
http://www.samba.org/netfilter/ipchains/
http://netfilter.kernelnotes.org/ipchains/
- A.4.2.5 netfilter/iptables
Netfilter and iptables are packet filtering tools
being developed in conjunction with newer (e.g., 2.3.x)
Linux kernels for use in the 2.4.x series of Linux
kernels. Information about netfilter and iptables is
available from one of several locations.
http://netfilter.filewatcher.org/
http://netfilter.samba.org/
http://netfilter.kernelnotes.org/
- A.4.2.6 SunScreen Lite
SunScreen Lite offers high-speed, dynamic, stateful packet
screening, and is designed to protect individual servers or
small workgroups. It is available for no additional cost
to users of Solaris 8. More information is available at:
http://www.sun.com/software/securenet/lite/
- B.1.1 Practical UNIX & Internet Security, 2nd Edition
By Simson Garfinkel & Gene Spafford
2nd Edition April 1996
(C) 1996, 1991 O'Reilly & Associates, Inc.
ISBN: 1565921488
- B.1.2 Solaris Security
By Peter H. Gregory
(C) 1999 Prentice Hall PTR/Sun Microsystems Press
ISBN: 0130960535
- B.1.3 UNIX system security: A Guide for Users and System Administrators
By David A. Curry
(C) 1992 Addison-Wesley Professional Computing Series
ISBN: 0201606402
- B.1.4 Volume 8: X Window System Administrator's Guide
By Linda Mui & Eric Pearce
1st Edition October 1992
(C) 1992 O'Reilly & Associates, Inc.
ISBN: 0937175838
- B.1.5 Hacking Exposed: Network Security Secrets and Solutions
By Joel Scambray, Stuart McClure and George Kurtz
(C) 2000 McGraw-Hill Professional Publishing
ISBN: 0072127481
- B.1.6 Firewalls and Internet Security
By William R. Cheswick & Steven M. Bellovin
(C) 1994 AT&T Bell Laboratories, Inc.
Addison-Wesley Professional Computing Series
ISBN: 0201633574
- B.1.7 Building Internet Firewalls, Second Edition
By Elizabeth D. Zwicky, Simon Cooper, & D. Brent Chapman
(C) 1995 O'Reilly & Associates, Inc.
ISBN: 1565928717
- B.1.8 Maximum Security - A Hacker's Guide to Protecting Your Internet Site and Network
By Anonymous
(C) 1998 SAMS Publishing
ISBN: 0672313413
- B.1.9 UNIX System Administration Handbook (third edition)
Evi Nemeth, Garth Snyder, Trent R. Hein and Scott Seebass
(C) 2001 Prentice-Hall PTR
ISBN: 0130206016
- B.1.10 Essential System Administration, 2nd Edition
By Aeleen Frisch
2nd Edition September 1995
(C) 1995 O'Reilly & Associates, Inc.
ISBN: 1565921275
- B.1.11 Real World Linux Security: Intrusion Prevention, Detection and Recovery
By Bob Toxen
(C) 2000 Prentice Hall PTR/Sun Microsystems Press
ISBN: 0130281875
- B.1.12 Managing NFS and NIS, 2nd Edition
By Hal Stern
2nd Edition June 2001
(C) 2001 O'Reilly & Associates, Inc.
ISBN: 1565925106
- B.1.13 Unix Secure Shell (McGraw-Hill Tools Series)
By Anne H. Carasik
(C) 1999 Osborne McGraw-Hill
ISBN: 0071349332
- B.1.14 Hack Proofing Your Network -
Internet Tradecraft
By Ryan Russell
(C) 2000 Syngress
ISBN: 1928994156
- B.1.15 Applied Cryptography, 2nd Edition
By Bruce Schneier
(C) 1995 John Wiley & Sons
ISBN: 0471117099
- B.1.16 TCP/IP Illustrated Volumes 1, 2, 3
By Gary R. Wright and W. Richard Stevens
(C) 1994, 1995, 1996 Addison-Wesley
ISBN: 0201633469 (Vol 1 - The Protocols)
ISBN: 020163354X (Vol 2 - The Implementation)
ISBN: 0201634953 (Vol 3 - TCP for Transactions, HTTP,
NNTP, and the UNIX(R) Domain Protocols)
Notes:
- The commands given here are examples only. Please consult the manual pages
for your system if you are unsure of the consequence of any command.
- BSD-style commands are marked as BSD commands, similarly for SVR4. Commands
which are not labelled are expected to work for both.
- Full directory paths and program options may vary for different flavours
of UNIX. If in doubt, consult your vendor documentation.
C.1
Restart inetd
BSD commands
# /bin/ps -aux | /bin/grep -E "inetd|^USER" | /bin/grep -v grep
# /bin/kill -HUP <inetd-PID>
SVR4 commands
# /bin/ps -ef | /bin/grep inetd | /bin/grep -v grep
# /bin/kill -HUP <inetd-PID>
C.2 Ascertain which services are registered with the portmapper
# /usr/bin/rpcinfo -p
C.3 Rebuild alias maps
# /usr/bin/newaliases
If you run NIS (YP), you will then need to rebuild your maps to have the
change take effect over all clients:
# (cd /var/yp; /usr/bin/make aliases)
C.4 Printing the umask value for each user
Use the following shell script:
#!/bin/sh
PATH=/bin:/usr/bin:/usr/etc:/usr/ucb
HOMEDIRS=`cat /etc/passwd | awk -F":" 'length($6) > 0 {print $6}' | sort -u`
FILES=".cshrc .login .profile"
for dir in $HOMEDIRS
do
for file in $FILES
do
grep -s umask /dev/null $dir/$file
done
done
C.5 Set sendmail log level to 9
Include lines describing the log level (similar to the following two)
in the options part of the general configuration information section of
the sendmail configuration file:
# log level
OL9
The log level syntax changed in sendmail 8.7 to:
# log level
O LogLevel=9
C.6 Set syslog log level for mail messages
Include lines describing the logging required (similar to the following
two) in the syslog.conf file:
mail.info /dev/console
mail.info /var/adm/messages
For the change to take effect, you must then instruct syslog to reread
the configuration file.
BSD commands
Get the current PID of syslog:
# /bin/ps -aux | /bin/grep syslogd | /bin/grep -v grep
Then tell syslog to reread its configuration file:
# /bin/kill -HUP <syslog-PID>
SVR4 commands
Get the current PID of syslog:
# /bin/ps -ef | /bin/grep syslogd | /bin/grep -v grep
Then tell syslog to reread its configuration file:
# /bin/kill -HUP <syslog-PID>
NOTE: In the logs, look for error messages like:
- mail to or from a single pipe ("|")
- mail to or from an obviously invalid user (e.g., bounce or blah)
C.7 (Rebuilding and) restarting sendmail(8)
To rebuild the frozen configuration file, firstly do:
# /usr/lib/sendmail -bz
NOTE: The above process does not apply to sendmail v8.x which does not
support frozen configuration files.
To restart sendmail(8), you should kill *all* existing sendmail(8)
processes by sending them a TERM signal using kill, then restart sendmail(8).
BSD commands
Get the pid of every running sendmail process:
# /bin/ps -aux | /bin/grep sendmail | /bin/grep -v grep
Kill every running sendmail process and restart sendmail:
# /bin/kill <pid> #pid of every running sendmail process
# /usr/lib/sendmail -bd -q1h
SVR4 commands
Get the pid of every running sendmail process:
# /bin/ps -ef | /bin/grep sendmail | /bin/grep -v grep
Kill every running sendmail process and restart sendmail:
# /bin/kill <pid> #pid of every running sendmail process
# /usr/lib/sendmail -bd -q1h
C.8 Test whether ftpd supports SITE EXEC
For normal users:
% ftp localhost 21
USER username
PASS password
SITE EXEC
For anonymous users:
% ftp localhost 21
USER ftp
PASS username@domainname.au
SITE EXEC
You should see the response "5nn error return" (e.g., "500 'SITE EXEC'
command not understood"). If your ftp daemon has SITE EXEC enabled, make
sure you have the most recent version of the daemon.
Older versions of ftpd allow any user to gain shell access using the SITE
EXEC command. Use QUIT to end the telnet session.
C.9 Ascertain whether anonymous FTP is enabled
% ftp localhost
Connected to localhost
220 hostname FTP server ready
Name (localhost:username): anonymous
331 Guest login ok, send username as password
Password: user@domain.au
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
C.10 Ensure that '*' in the password field is
correctly implemented
-
Try using NIS with the '*' in the password field for example: +:*:0:0:::
If NIS users cannot log in to that machine, remove the '*' and try the
next test.
-
With the '*' removed, try logging in again. If NIS users can log in
AND you can also log in unauthenticated as the user '+', then your
implementation is vulnerable. Contact the vendor for more information.
If NIS users can log in ANC you cannot log in as the user '+', your
implementation should not be vulnerable to this problem.
C.11 Find .exrc files
# /bin/find / -name '.exrc' -exec /bin/cat {} ; -print
See also C.19.
C.12 Find .forward files
# /bin/find / -name '.forward' -exec /bin/cat {} ; -print
See also C.19.
C.13 Remove execute permission on
/usr/lib/expreserve
# /bin/chmod 400 /usr/lib/expreserve
C.14 Set ownership and permissions for /tmp
correctly
# /bin/chown root /tmp
# /bin/chgrp 0 /tmp
# /bin/chmod 1777 /tmp
NOTE: This will NOT recursively set the sticky bit on sub-directories
below /tmp, such as /tmp/.X11-unix and
/tmp/.NeWS-unix; you may have to set these manually or through
the system startup files.
C.15 Find group and world writable files and
directories
# /bin/find / -type f ( -perm -2 -o -perm -20 ) -exec ls -lg {} ;
# /bin/find / -type d ( -perm -2 -o -perm -20 ) -exec ls -ldg {} ;
See also C.19.
C.16 Find files with the SUID or SGID bit
enabled
# /bin/find / -type f ( -perm -004000 -o -perm -002000 )
-exec ls -lg {} ;
See also C.19.
C.17 Find normal files in /dev
# /bin/find /dev -type f -exec ls -l {} ;
See also C.19.
C.18 Find block or character special files
# /bin/find / ( -type b -o -type c ) -print | grep -v '^/dev/'
See also C.19.
C.19 Avoid NFS mounted file systems when using /bin/find
# /bin/find / ( ! -fstype nfs -o -prune ) <expression>
As an example, <expression> could be
-type f ( -perm -004000 -o -perm -002000 ) -exec ls -lg {} ;
It is intended that this short version of the checklist be
used in conjunction with the full checklist as a progress guide
(mark off the sections as you go so that you remember what you
have done so far).
|