| Message |
Visit
wap.cert.org for wireless advisories.
|
|
 |
UNIX Security Checklist v2.0
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/Information/Auscert_info/papers.html
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/Information/Auscert_info/Papers/win-UNIX-system_compromise.html
It is our intention to continue to update this checklist. Any comments
should be directed via email to [email protected] and [email protected].
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:
ftp://ftp.auscert.org.au/pub/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:
ftp://ftp.auscert.org.au/pub/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
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:
ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-95.07.Incorrect.Permissions.on.tmp.may.allow.root.access
- 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:
ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-93.04.Password.Policy.Guidelines
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 via anonymous FTP from:
ftp://ftp.auscert.org.au/pub/auscert/tools/overflow_wrapper/overflow_wrapper.c
- 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 [email protected]
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: [email protected]
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).
Before You Begin
- Don't attach the machine to an insecure network until all steps in
this document have been addressed - preferably, perform all
installations on the machine while it is completely isolated from any
network. This may be facilitated by the use of patches stored on a CD
or file server located within an isolated staging network.
- Retrieve the latest patch list from your vendor and retrieve any
recommended security patches not included with your system. Some
patches may re-enable default configurations so it is important to go
through this checklist after installing
any new patches or packages. Information about where
to obtain operating system patches or packages is available in the USC
at Section
IV. Patches for software applications not supplied by the
operating system vendor should be obtained directly from the software
vendor's web site.
- Ensure that software patches and packages are only downloaded from
a reliable source (i.e. direct from the vendor or a trusted mirror).
This also applies to the operating system if it is publicly-available
or open-source.
- Verify the cryptographic digital signature of any signed
downloaded files to ensure integrity. Don't use a file whose signature
doesn't match its contents! Information about PGP/GnuPG is available
in the USC at A.2.10
PGP/GnuPG.
- Verify the md5 checksum, when possible, of any downloaded patches
with a utility like md5(1) or md5sum(1). Information
about obtaining an MD5 utility is available in the USC at A.2.6
MD5.
- Subscribe to the vendor's security update mailing list for your
particular operating system. Information for individual vendors is
available in the USC at Section
IV.
- 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. Information on subscribing to mailing lists
is available in the USC at B.2.3 Mailing
Lists.
Before the System is "Live"
Step One - Patches
- Check for last-minute updates for your system that need to be
performed subsequent to installation.
- Install security patches retrieved before installation.
- Check for the availability of a hardening script package for your
particular system. Information on hardening scripts is available in
the USC at Section IV
- Specific Operating Systems.
Step Two - System Configuration
Step Three - Network Options
- At a minimum, make use of any built-in firewalling utility that
the operating system provides. For example: Linux has ipchains and
iptables (See A.4.2.4
and A.4.2.5),
BSD has ipfw (See A.4.2.1),
Sun Solaris includes a "light" version of their SunScreen product with
Solaris 8 (See A.4.2.6).
- Ensure that the host is configured against IP spoofing and attacks
with kernel and firewall rules. See 3.1 Packet
Filtering and 3.2 Denial of
Service Attacks.
- If you wish to remotely administer your host, don't use
unencrypted channels to do so (like telnet). Configure your host to
use encrypted communications with a utility like SSH. See 3.3
Encryption and Strong Authentication
Step Four - System Monitoring and Additional Tools
- Implement and maintain utilities for intrusion detection. At a
minimum, implement a file integrity checker to monitor file-system
changes. More information is available in the USC at 4.0 File
System Security
- Additional information on security and monitoring tools is
available in the USC at Appendix A
Step Five - Final Updates
- Ensure you implement a procedure to regularly parse and check
system log outputs for unusual activity.
- Make a backup of the completed system before putting it on a
production network. This allows you a clear path to restore the system
to an operational state. You should also implement a continuing backup
policy.
- Create and maintain a logbook for each system. This allows you to
document any changes made to system configurations.
Questions or comments regarding this page? [email protected]
Disclaimer -
Copyright © 2001, AusCERT
http://www.auscert.org.au/
|
