Notice: Undefined variable: files in /home/keeline/public_html/iteachphp/menu.php on line 32
E-MAIL
|
Notice: Undefined index: p in /home/keeline/public_html/iteachphp/index.php on line 109
Deprecated: Function eregi() is deprecated in /home/keeline/public_html/iteachphp/index.php on line 124
Deprecated: Function eregi() is deprecated in /home/keeline/public_html/iteachphp/index.php on line 124
UnixSecurity2.0.html
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 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:
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)
-
Be aware that PAM may be operational
by default on your system.
-
To find out if a given executable
uses PAM, execute the command ldd [path to executable file]. For
example, the resulting output for /usr/bin/login on a FreeBSD
4.x system:
/usr/bin/login:
libutil.so.3 => /usr/lib/libutil.so.3 (0x28068000)
libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x28072000)
libpam.so.1 => /usr/lib/libpam.so.1 (0x28074000)
libc.so.4 => /usr/lib/libc.so.4 (0x2807d000)
Note the libpam.so.1, this
is a PAM module.
Depending on the system, PAM may
be configured with the file /etc/pam.conf or with individual configuration
files in /etc/pam.d/.
ENSURE that PAM is configured to
be secure by default - a misconfigured service may result in an attempt
to authenticate using a less secure mechanism, which should be always denied.
CONSIDER disabling unneeded services
under PAM, either by renaming/deleting the individual files or by editing
/etc/pam.conf.
More information about PAM is available
from:
http://www.kernel.org/pub/linux/libs/pam/
http://www.sun.com/solaris/pam/
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
-
DO use packet filtering at network
or administrative borders to enforce security policies by restricting network
traffic entering and leaving your domain.
-
DO use multi-layer firewalls, such
as a host-based firewall in addition to network packet filtering.
-
DO use protocol type, destination
address, and destination port information to construct packet filters to
enforce security policies for inbound traffic.
-
ENSURE that ONLY packets for those
services which require access across your network or administrative border
are allowed to enter and leave your domain.
-
In particular, if external traffic
to and from the following services is not required at your site, use packet
filters to block traffic to and from the following services. Inbound filters
should block based on protocol type and destination port. Outbound filters
should block based on protocol type and source port.
NAME PORT/PROTOCOL NAME PORT/PROTOCOL
tcpmux 1/tcp netbios-ns 137/udp
echo 7/tcp netbios-dgm 138/tcp
echo 7/udp netbios-dgm 138/udp
discard 9/tcp netbios-ssn 139/tcp
discard 9/udp netbios-ssn 139/udp
systat 11/tcp imap 143/tcp
daytime 13/tcp snmp 161/udp
daytime 13/udp snmp-trap 162/udp
netstat 15/tcp xdmcp 177/udp
chargen 19/tcp exec 512/tcp
chargen 19/udp biff 512/udp
ftp 21/tcp login 513/tcp
ssh 22/tcp who 513/udp
telnet 23/tcp shell 514/tcp
smtp 25/tcp syslog 514/udp
domain (DNS) 53/tcp printer 515/tcp
domain (DNS) 53/udp talk 517/udp
bootps 67/tcp ntalk 518/udp
bootps 67/udp route 520/udp
bootpc 68/tcp klogind 543/tcp
bootpc 68/udp socks 1080/tcp
tftp 69/udp nfs 2049/tcp
finger 79/tcp nfs 2049/udp
http 80/tcp X11 6000 to 6000+n/tcp
pop2 109/tcp
pop3 110/tcp (n = maximum number of X servers)
sunrpc 111/tcp
netbios-ns 137/tcp
ENSURE that ONLY hosts in your domain
exchanging legitimate traffic with external hosts are allowed to send and
receive packets for required services.
For inbound filters, use protocol
type, destination address, and destination port. For outbound filters,
use protocol type, source address, and source port.
Hosts not required to route TCP/IP
packets should have this facility disabled. An example of disabling this
for a Linux system:
echo 0 > /proc/sys/net/ipv4/ip_forward
Filtering can be difficult to implement
correctly. For more information on packet filtering and firewalls, please
see:
Firewalls and Internet
Security B.1.6
Building Internet Firewalls B.1.7
Deploying Firewalls
http://www.cert.org/security-improvement/modules/m08.html
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
-
ENSURE that you are using the most
recent version of the FTP daemon of your choice.
-
CHECK all default configuration options
on your FTP server.
-
ENSURE that your FTP server does
not have the SITE EXEC command (see C.8 for command details),
or that this command is disabled correctly.
-
ENSURE that you have set up a file
/etc/ftpusers which specifies those users that are NOT allowed
to connect to your ftpd. This should include, as a MINIMUM, the entries:
root, bin, uucp, ingres, daemon, news, nobody and ALL vendor supplied accounts.
-
CHECK all default configuration options
on your FTP server. Not all versions of ftp daemons are configurable. If
you have a configurable version of ftp (e.g., WU-FTP) then make sure that
all delete, overwrite, rename, chmod and umask options (there may be others)
are NOT allowed for guests and anonymous users. In general, anonymous users
should not have any unnecessary privileges.
-
ENSURE that you DO NOT include a
command interpreter (such as a shell or tools like perl) in ~ftp/bin,
~ftp/usr/bin, ~ftp/sbin or similar directory configurations
that can be executed by SITE EXEC. For an example of a previous vulnerability,
refer to AusCERT advisory:
ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-2000.02
-
DO NOT keep system commands in ~ftp/bin,
~ftp/usr/bin, ~ftp/sbin or similar directory configurations
that can be executed by SITE EXEC. It may be necessary to keep some commands,
such as uncompress, in these locations. Consider the inclusion of each
command on a case by case basis and be aware that the presence of such
commands may make it possible for local users to gain unauthorised access.
Be wary of including commands that can execute arbitrary commands. For
example, some versions of tar may allow you to execute an arbitrary file.
-
ENSURE that you use an invalid password
and user shell for the ftp entry in the system password file and the shadow
password file (if you have one). It should look something like:
ftp:*:400:400:Anonymous
FTP:/home/ftp:/bin/false
where /home/ftp is the anonymous
FTP area.
-
ENSURE that the permissions of the
FTP home directory ~ftp/ are set to 555 (read nowrite execute),
owner set to root (NOT ftp).
-
ENSURE that you DO NOT have a copy
of your real /etc/passwd file as ~ftp/etc/passwd. Create
one from scratch with permissions 444, owned by root. It should not contain
the names of any accounts in your real password file. It should contain
only root and ftp. These should be dummy entries with disabled passwords
e.g.:
root:*:0:0:Ftp maintainer::
ftp:*:400:400:Anonymous ftp::
The password file is used only to
provide uid to username mapping for ls(1) listings.
-
ENSURE that you DO NOT have a copy
of your real /etc/group file as ~ftp/etc/group. Create
one from scratch with permissions 444, owned by root.
-
ENSURE the files ~ftp/.rhosts
and ~ftp/.forward do not exist.
-
DO set the login shell of the ftp
account to a non-functional shell such as /bin/false.
-
ENSURE NO files or directories are
owned by the ftp account or have the same group as the ftp account. If
they are, it may be possible for an intruder to replace them with a trojan
version.
-
ENSURE NO files or directories in
the FTP area are world writable.
-
ENSURE that the anonymous ftp user
cannot create files or directories in ANY directory unless required (Refer
to 10.1)
-
ENSURE that the anonymous ftp user
can only read information in public areas.
-
ENSURE that the system subdirectories
~ftp/etc and ~ftp/bin have the permissions 111 only,
owner set to root.
-
ENSURE that the permissions of files
in ~ftp/bin have the permissions 111 only, owner set to root.
-
ENSURE that the permissions of files
in ~ftp/etc are set to 444, owner set to root.
-
ENSURE that there is a mail alias
for ftp to avoid mail bounces.
-
ENSURE /usr/spool/mail/ftp
is owned by root with permissions 400.
-
NEVER mount disks from other machines
to the ~ftp hierarchy unless they are set read-only in the mount command.
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.
-
DO disable IP forwarding and source
routing. To do this you will need to edit the file /etc/rc2.d/S69.inet
and set the options ip_forwarding and ip_ip_forward_src_routed
to zero as illustrated below:
ndd -set /dev/ip
ip_forwarding 0
ndd -set /dev/ip ip_ip_forward_src_routed
0
For the changes to take effect you
will then need to reboot.
15.3
Stack Execution
-
DO Disable executable stacks by default
to stop "stack smashing" attacks based on buffer overflow exploits. To
do this, you will need to edit the file /etc/system and add the
following lines:
set noexec_user_stack=1
set noexec_user_stack_log=1
Note that this may go against the
SPARC and Intel ABIs and can be bypassed as required in programs with mprotect(2).
For the changes to take effect you will then need to reboot.
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
-
DO review the state of accounts that
are installed by default in the IRIX operating system. Several of these
accounts are installed with widely-known or empty passwords. Refer to 5.2
for information about checking for password-less accounts. Some of the
accounts that may be installed with empty passwords are:
-
guest
-
demos
-
EZsetup
-
OutOfBox
-
4Dgifts
-
lp
-
root
Other accounts may be added with
known passwords. Here is a partial list of accounts known to have easily
guessed passwords.
-
lp
-
field
-
tutor
-
tour
-
4Dgifts
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 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).
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
-
For more detailed information, refer
to the USC at
2.0 Network Services
-
Disable any services which you do
not absolutely require, by commenting out individual lines in /etc/inetd.conf
with a "#" character, then reenabling essential services only. See 2.1
/etc/inetd.conf.
-
Unless "r" commands (i.e. rsh, rlogin)
are required, remove or empty the file /etc/hosts.equiv.
-
If "r" commands are required, consider
replacing them with secure alternatives, such as ssh. See A.2.13
ssh in the USC for more information.
-
Configure tcp_wrappers in /etc/inetd.conf
to provide greater access and logging on enabled services if using the
inetd daemon. See 2.2 tcp_wrapper. If using Xinetd,
ensure that it is correctly configured in
/etc/xinetd.conf. See
2.1 /etc/inetd.conf.
-
Edit /etc/hosts.allow to
include this entry as the first uncommented line AFTER any configuration
lines allowing connections for any specific services required:
ALL:ALL:deny
-
Edit /etc/hosts.deny to
include this entry as the first uncommented line in the file:
ALL:ALL
-
Verify that you have disabled any
unnecessary startup scripts under /etc, /etc/rc.d or
/etc/init.d
(or startup script directory for your system) and disabled any unneeded
services from starting in these scripts.
-
Remove unneeded accounts/groups and
disable interactive login access to system accounts.
-
After restarting the machine, check
for running network services by issuing the command netstat -a.
Ensure that only required services are running and listening for connections.
This helps in preventing security compromises on possibly unknown and unpatches
services.
-
On systems that implement the /etc/login.access
file, 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
See also 2.10 /etc/login.access
-
Ensure that the terminal security
file (for example,
/etc/securetty or /etc/ttys) is configured
to deny privileged (root) access from any external connections. See
2.15
Secure Terminals.
-
Check that the configuration files
for PAM (/etc/pam.conf, /etc/pam.d/*) are secure. See
2.13
PAM (Pluggable Authentication Modules)
-
Ensure that the file /etc/ftpusers
contains the names of all system accounts, as well as root. See
5.3
Special accounts
-
Prevent lpd and syslogd from listening
for network connections if possible. Caution should be exercised to ensure
outbound connections are still allowed if required for your system configuration.
This may be accomplished with command-line arguments and/or tcp_wrappers
- refer to your system's info or man pages.
-
Clear /etc/hosts.lpd if
not required. If the host is a print server, ensure that only fully qualified
domain names are specified ie. hostname.domainname. See
2.9
/etc/hosts.lpd
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.
Revision History |
Oct
8, 2001 |
Initial
Release |
Questions
or comments regarding this page?
auscert@auscert.org.au
Disclaimer
- Copyright © 2001, AusCERT
http://www.auscert.org.au/
Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /home/keeline/public_html/iteachphp/index.php on line 130
|