![[EdCert previous]](/usail/edcert/images/prev.gif)
![[EdCert next]](/usail/edcert/images/next.gif)
![[EdCert top]](/usail/edcert/images/top.gif)
Note:to facilitate faster loading of EdCert documents, this page was borrowed from another source.
------------------------------------------------------------------------------
UNIX Computer Security Checklist (Version 1.0) Last Update 5-Mar-1995
------------------------------------------------------------------------------
The Australian Computer Emergency Response Team has developed a checklist
which covers common and known security holes under the UNIX Operating
System. It is based around recently discovered security vulnerabilities
and other checklists which are readily available. (see references in Appendix
C).
This document can be retrieved via anonymous ftp from the location
ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist_1.0
It is AUSCERT's intention to continue to update this checklist. Any
comments should be directed via email to auscert@auscert.org.au. This
document, once written is now a static article. Security issues are
considerably more fluid and change all the time. New versions of this
checklist will be placed in the same area on the ftp server and should be
checked for periodically.
In order to make effective use of this checklist, readers will need to have
a good grasp of basic UNIX system administration concepts. Refer to C.6 and
C.7 in Appendix C for books on UNIX system administration.
Follow the checklist closely and amend any problems that you encounter.
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.
Where applicable, references will be made to points under discussion that
relate to a specific vendor's operating system, such as SunOS.
In general, code examples have been written with SunOS 4.1.x in mind. Full
directory paths and program options may vary for different varieties of UNIX.
If in doubt consult your vendor documentation.
For ease of use, the checklist has been split into separate, logically
cohesive sections. All sections are important. An abbreviated version of
this checklist can be found in Appendix D.
CHECKLIST INDEX: 1.0 Patches
2.0 Network security
3.0 ftpd and anonymous ftp
4.0 Password and account security
5.0 File system security
6.0 SunOS specific security
7.0 IRIX specific security
8.0 X windows security
APPENDICES: Appendix A Other AUSCERT information sources
Appendix B Useful security tools
Appendix C References
Appendix D Checklist - abbreviated version
Appendix E Shell Scripts
------------------------------------------------------------------------------
1.0 Patches
------------------------------------------------------------------------------
* Retrieve the latest patch list from your vendor and install any
patches not yet installed that are recommended for your system.
Some patches may re-enable default configurations. For this
reason it is important to go through this checklist AFTER
installing ANY new packages.
NOTE: Be certain to verify the checksum information to confirm
that you have retrieved a valid copy. This is important
in any anonymous ftp transaction. If checksums are provided
- use them! That said, it should be noted that checksums
produced by /bin/sum should not be considered secure. Other
more cryptographically strong methods such as md5 should be
used. Refer to B.10 for md5 access information.
------------------------------------------------------------------------------
2.0 Network security
------------------------------------------------------------------------------
The following is a list of UNIX features that can be used to help
prevent attacks from external sources.
2.1 Filtering
* CHECK whether the following are required outside your domain. If
they are not required, then filter them out at the router.
NAME PORT PROTOCOL NAME PORT PROTOCOL
systat 11 TCP login 513 TCP
netstat 15 TCP shell 514 TCP
bootp 67 UDP printer 515 TCP
tftp 69 UDP biff 512 UDP
link 87 TCP who 513 UDP
supdup 95 TCP syslog 514 UDP
sunrpc 111 TCP/UDP uucp 540 TCP
NeWS 144 TCP route 520 UDP
snmp 161 UDP openwin 2000 TCP
xdmcp 177 UDP NFS 2049 UDP/TCP
exec 512 TCP X11 6000-6020 TCP
(Refer to C.6 Firewalls and Internet Security)
(Refer to the CERT advisory CA-95.01 (see C.7))
2.2 "r" commands
* DO disable all "r" commands (rlogin, rsh etc.) unless specifically
required.
This may increase your risk of password exposure in network
sniffer attacks, but "r" commands have been a regular source of
insecurities and attacks. Disabling them is by far the lesser
of the two evils.
Refer to section 2.8 for details on how to do this.
* DO filter ports 512,513 and 514 (TCP) at the router if you do use any
of the "r" commands.
This will stop people outside your domain from exploiting them
but will not stop people inside your domain from exploiting them.
To do this you will need to disable them (see above).
2.3 /etc/hosts.equiv
* CHECK that this file does not exist.
It 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 a trusted machine without supplying a password.
If you must have such a 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).
* DO only trust hosts within your domain or under your management.
* CHECK that you use fully qualified hostnames,
i.e. hostname.domainname.au
* ENSURE that you do NOT have a '+' entry by itself anywhere in the
file.
* ENSURE that the first character of the file is not '-'.
(Refer to the CERT advisory CA-91:12 (see C.7)).
* 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.4 $HOME/.rhosts
* CHECK that no user has a .rhosts file in their home directory.
They 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, so hear each one on a case-by-case basis; eg.
running backups over a network unattended.
* DO use cron to periodically check for, report the contents of
and delete $HOME/.rhosts files. Users should be made aware that you
regularly perform this type of audit.
If you must have such a file
* ENSURE the first character of the file is not '-'.
(Refer to the CERT advisory CA-91:12 (see C.7)).
* ENSURE that the permissions are set to 600.
* ENSURE that the owner is the same person who owns the account.
* ENSURE that the file does NOT contain the symbol "+" on any line.
2.5 NFS
* DO disable NFS if you do not need it.
Check your vendor supplied documentation for details on how to
do this.
* DO apply all available patches.
NFS has had a number of security vulnerabilities.
* 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 enable NFS port monitoring.
Calls to mount a file system will then only be accepted from
port < 1024(root access). You should check your vendor's
documentation to see if this is an option for your version of
UNIX. Under SunOS, to enable NFS port monitoring add the
following commands to /etc/rc.local
/bin/echo "nfs_portmon/W1" | /bin/adb -w /vmunix /dev/kmem > /dev/null 2>&1
rpc.mountd
* DO use /etc/exports to ONLY export file systems you need to export.
If you aren't certain that it needs to be exported, then it
probably doesn't.
* DO run fsirand for all your file systems.
Firstly, check that you have installed any patches for fsirand.
Then ensure the file system is unmounted and run fsirand.
Predictable root handles assist crackers in abusing NFS.
* CHECK that you never export file systems to the world.
Use a -access=host.domainname.au option in /etc/exports.
* DO export file systems read-only (option ro) whenever possible.
See the man page for "exports".
* DO use the secure option if it is available.
* DO use showmount -e to see what you currently have exported.
* REMEMBER that changes in /etc/exports will only take effect after
you run /usr/etc/exportfs.
* CHECK that the permissions of /etc/exports are set to 644.
* CHECK that /etc/exports is owned by root.
2.6 /etc/hosts.lpd
* ENSURE that the first character of the file is not '-'.
(Refer to the CERT advisory CA-91:12 (see C.7)).
* ENSURE that the permissions on this file are set to 600.
* ENSURE that the owner is set to root.
2.7 /etc/ttytab (BSD UNIX systems)
* CHECK that the secure option is removed from all entries that
don't need root login capabilities.
ie. all entries with the possible exception of console. It
should also be removed from console if you do not want users
to be able to reboot in single user mode.
* CHECK that this file is owned by root.
* CHECK that the permissions on this file are 644.
2.8 /etc/inetd.conf
* ENSURE that the permissions on this file are set to 644.
* 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. Then enable
the ones you NEED by removing the "#" from the beginning
of the line. In particular, it is best to avoid "r" commands
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 following commands.
# /bin/ps -aux | /usr/bin/grep inetd | /usr/bin/grep -v grep
# /bin/kill -HUP
2.9 Trivial ftp (tftp)
* Read the AUSCERT Advisory SA-93:05 (see A.1) and follow the
recommendations.
* If tftp is not needed, comment it out from the file
/etc/inetd.conf and restart the inetd process (as above).
2.10 /etc/services
* ENSURE that the permissions on this file are set to 644.
* ENSURE that the owner is root.
2.11 tcp_wrapper (also known as log_tcp)
* ENSURE that you are running this program.
- Refer to section A.5 on how to obtain tcp_wrapper.
- Customise and install it for your system.
- Deny all hosts by putting "all:all" in /etc/hosts.deny and
explicitly list trusted hosts who are allowed access to your
machine in /etc/hosts.allow.
* DO wrap all TCP services that you have enabled.
2.12 /etc/aliases
* Comment out the "decode" alias by placing a "#" at the beginning
of the line. For this change to take effect you will need to run
/usr/bin/newaliases.
# /usr/bin/newaliases
If you run NIS (YP), you will then need to rebuild your maps:
# (cd /var/yp; /usr/bin/make aliases)
* ENSURE that all programs executable by an alias are owned by root,
have permissions 755 and are stored in a systems directory
eg. /usr/local/bin.
2.13 /etc/sendmail.cf
* ENSURE the line starting with "OW" only has a "*" next to it.
* DO use Eric Allmans's sendmail v8.6.10 (or greater), as it
currently contains no KNOWN vulnerabilities.
This is available via anonymous FTP from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu
/ucb/sendmail/sendmail.8.6.10.*
Note: If you don't already run Eric Allman's sendmail.8.6.*,
then it may take you some time to build, install, and configure
the system to your needs. Other sendmail(8) configuration files
may not be compatible with sendmail(8) 8.6.10.
* CHECK that you have installed the latest patches.
This is VERY important as sendmail(8) has been a source of a
number of security vulnerabilities.
(Refer to AUSCERT Advisory SA-93:10 (see A.1)
and CERT Advisories CA-94:12 and CA-95:05 (see C.7))
* TRY the following tests:
% telnet hostname 25
wiz
debug
kill
quit
%
You should see the response "500 Command unrecognized" after
each of the commands 'wiz', 'debug' and 'kill'. If not, your
version of sendmail is vulnerable and should be updated.
* DO increase sendmail(8) logging to a minimum log level of 9.
This will help detect attempted exploitation of the sendmail(8)
vulnerabilities. To do this, include the following line in the
options part of the general configuration information section of
the sendmail configuration file:
# log level
OL9
* 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. For example,
include the following lines in the syslog.conf file:
mail.info /dev/console
mail.info /var/adm/messages
syslog will then need to be instructed to reread the configuration
file. This can be done by issuing the command
# /bin/kill -HUP `/bin/cat /etc/syslog.pid`
Sample error messages to look for include mail to or from a
single pipe ("|"), or mail to or from an obviously invalid user
(for example, bounce or blah).
* REMEMBER that if you are running a frozen configuration file -
sendmail.fc, you will need to rebuild it and restart sendmail(8)
before any changes will take effect. To rebuild the frozen
configuration file, the command is:
# /usr/lib/sendmail -bz
To restart sendmail(8) you should kill *all* existing sendmail(8)
processes by sending them a TERM signal using kill. Then startup
sendmail(8). Sample commands are:
# /usr/bin/ps -auxw | /bin/grep sendmail | /bin/grep -v grep
# /bin/kill #pid of every running sendmail process
# /usr/lib/sendmail -bd -q1h
2.14 majordomo
* Check that your version is greater than 1.91.
See AUSCERT Advisory SA-94.03 (see A.1) for more details.
2.15 fingerd
* If your version of fingerd is older than than 5 November 1988,
replace it with a newer version.
2.16 UUCP
* DO disable the uucp account, including the shell that it executes
for logging in, if it is not used at your site.
uucp may be shipped in a dangerous state.
* REMOVE any .rhosts file at the uucp home directory.
* CHECK that the file L.cmds is owned by root.
* ENSURE that no uucp owned files are world writable.
* CHECK that you have assigned a different uucp login for each site
that needs uucp access to your machine.
* CHECK that you have limited the number of commands that each uucp
login can execute to a bare minimum.
------------------------------------------------------------------------------
3.0 ftpd and Anonymous ftp
------------------------------------------------------------------------------
3.1 Versions
* ENSURE you are using the most recent version of the ftp daemon
that you use.
* DO consider installing the Washington University ftpd if you don't
already have it.
This can log all events and provide users with a login banner.
Do not install any versions prior to wu-ftp 2.4.
(Refer to the CERT advisory CA-94:07 (see C.7)).
It is available via anonymous ftp from
ftp://ftp.auscert.org.au/pub/mirrors/wuarchive.wustl.edu
/packages/wuarchive-ftpd/*
[Warning: versions of wu-ftp prior to 2.4 are extremely insecure
and in some cases have been trojaned.]
* For BSDI systems, patch 005 should be applied to version 1.1 of the
BSD/386 software. It is available via anonymous ftp from:
ftp://ftp.bsdi.com/bsdi/patches/README
ftp://ftp.bsdi.com/bsdi/patches/?U110-005
(? will be B or S for the Binary or Source version)
3.2 SITE EXEC
* CHECK to make sure your ftp server does not have the SITE EXEC command
Do this by telneting to port 21 and typing SITE EXEC. If your
ftp daemon has SITE EXEC make sure you have the most recent
version of the daemon (eg, wu-ftp 2.4). In older versions of ftpd
SITE EXEC allows anyone to gain shell via port 21.
* CHECK that any commands from ~ftp/bin, ~ftp/usr/bin, ~ftp/sbin or
similar directory configurations that can be executed by SITE EXEC
DO NOT contain system commands or include a shell
(eg., ~ftp/bin -> /bin) If they do contain system commands
it is possible for local users to gain root access.
(See AUSCERT advisory SA-94.01 (see A.1))
3.3 Configuration of your ftp server
* CHECK all default configuration options on your ftp server.
Not all versions of ftp are configurable. If you have a
configurable version of ftp (eg. 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.
* CHECK 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 that you use an invalid password and user shell for the ftp
entry in the system passwd file. It should look something like:
ftp:*:400:400:Anonymous FTP:/home/ftp:/bin/rubbish
where /home/ftp is the anonymous ftp area.
* CHECK 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 eg:
root:*:0:0:Ftp maintainer::
ftp:*:400:400:Anonymous ftp::
* Similarly, CHECK 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 are zero
length, have permissions 600 and are owned by root.
3.4 Permissions
* 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 that the anonymous ftp user cannot create files or directories
in ANY directory.
* ENSURE that the ftp user can only read information in public areas.
* 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 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 /usr/spool/mail/ftp is owned by root with permissions 400.
If you need email for the ftp admin (eg. for problem reporting)
use an alias.
3.5 Writable directories
* CHECK 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.
* CHECK that writable directories are not also readable.
Directories that are both writable and readable may be used by
unauthorised persons to trade pirated software.
* CHECK 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.
* DO read the CERT document which addresses the many problems
associated with writable anonymous ftp directories. It can be
obtained via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/cert/tech_tips/anonymous_ftp
3.6 Disk mounting
* NEVER mount disks from other machines to the ~ftp hierarchy
unless they are read-only.
------------------------------------------------------------------------------
4.0 Password and account security
------------------------------------------------------------------------------
This section of the checklist can be incorporated as part of a
password and account usage policy.
4.1 Policy
* CHECK that you have a password policy for your site.
See the AUSCERT Advisory SA-93.04 (see A.1).
* 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.
4.2 Proactive Checking
* DO use npasswd or passwd+ to proactively screen passwords as they are
entered.
These programs run a series of checks on passwords when they are
set and can help to screen out poor passwords. They were not
designed to work with shadow password systems.
(Refer to section B.3 for how to obtain these.)
* DO check passwords periodically with Crack.
(Refer to section B.4 for how to obtain Crack.)
* DO apply password aging (if possible).
4.3 Root Password
* DO restrict the number of people who know the root password.
These should be the same users registered with groupid 0
(eg. wheel group on SunOS). Typically this is limited to at most
3 or 4 people.
4.4 NIS and /etc/passwd entries
* DO NOT run NIS if you don't really need it.
* CHECK 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.
To do this, follow the steps below:
. 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 '+',
you have a problem! Your vendor needs to change their version
of NIS. If NIS users can log in AND you cannot log in as the
user '+', your implementation should not be vulnerable to this
problem.
* CHECK that /etc/rc.local is set up to start ypbind with the -s
option.
This may not be applicable on all systems. Check your
documentation.
4.5 Password shadowing and C2 security
* DO implement C2 security if possible.
Consult your vendor documentation for details.
* DO implement vendor supplied password shadowing or a third party
product if you cannot run full C2 security.
Password shadowing restricts access to users' encrypted passwords.
* DO periodically audit your password and shadow password files
for unauthorised additions or inconsistencies.
4.6 Administration
* ENSURE that you regularly audit your system for dormant accounts
and disable any that have not been used for a specified period,
say 3 months. Send out account renewal notices and delete any
accounts of users that do not reply.
* CHECK that all accounts have passwords.
* ENSURE that any user area is adequately backed up and archived.
* DO regularly monitor logs for successful and unsuccessful su
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.
4.7 Special accounts
* CHECK that there are no shared accounts other than root;
i.e. more than one person should not know the password to an
account.
* Disable guest accounts.
Better yet, do not create guest accounts!
* DO use special groups (such as the "wheel" group under SunOS) to
restrict which users have access to root.
* DISABLE ALL default vendor accounts shipped with the Operating System.
This should be checked after each upgrade or installation.
* Disable accounts that have no password which execute a command, for
example "sync".
Preferably, remove these accounts entirely. Check that they do
not own any files before you do so.
4.8 Root account
* Make sure root does not have a ~/.rhosts file.
* Make sure "." is not in root's search path.
* Make sure root's login files do not source any other files not
owned by root or which are group or world writable.
* Make sure 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.
i.e. /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 "./", eg. ./command.
------------------------------------------------------------------------------
5.0 File system security
------------------------------------------------------------------------------
5.1 General
* CHECK that there are no .exrc files on your system that have
no legitimate purpose.
These may inadvertently perform commands that may compromise
the security of your system if you happen to start either vi or
ex in a directory which contains such a file. To find .exrc files:
# /bin/find / \( -fstype 4.2 -o -prune \) -name '.exrc' \
-exec /bin/cat {} \; -print
* CHECK that any .forward files in user home directories do not
execute a command or run a program.
The mailer may be fooled into allowing a normal user privileged
access. The following command will locate and print .forward
files:
# /bin/find / \( -fstype 4.2 -o -prune \) \
-name '.forward' -exec /bin/cat {} \; -print
(Refer to AUSCERT Advisory SA-93.10 (see A.1))
5.2 /etc/rc.local
* CHECK /etc/rc.local does not chmod 666 motd.
This allows users to change system message for the day.
* ENSURE that the line "rm -f /tmp/t1" (or similar) exists in
/etc/rc.local to clean up the temporary file used to create /etc/motd.
This should occur BEFORE the code to startup the local daemons.
5.3 /usr/lib/expreserve
* DO replace versions of /usr/lib/expreserve prior to July 1993
with a recommended patch from your vendor.
If this is not possible, then remove execute permission on
/usr/lib/expreserve:
# /bin/chmod 400 /usr/lib/expreserve
This will mean that users who edit their files with either vi
or ex and have their sessions interrupted, will not be able to
recover their lost work. If you implement the above
workaround, please advise your users to regularly save their
editing sessions.
Refer to the CERT advisory CA-93:09 for advice on fixing this
problem for the SunOS and Solaris environments.
5.4 External file systems/devices
* DO mount file systems non-setuid and read-only where practical.
(Refer to section 2.5 NFS)
5.5 File Permissions
* CHECK that the permissions of /etc/utmp are set to 644.
* CHECK that the permissions of /etc/sm and /etc/sm.bak are set to 2755.
* CHECK that the permissions of /etc/state are set to 644.
* CHECK that the permissions of /etc/motd and /etc/mtab are set to 644.
* CHECK that the permissions of /etc/syslog.pid are set to 644.
* REMOVE setgid priveleges on /usr/kvm/crash.
A group of kmem allows users to read the virtual memory of a
running system.
# /bin/chmod g-s /usr/kvm/crash
* DO consider removing read access to files that users do not need to
access.
* ENSURE that the kernel (eg. /vmunix) is owned by root, has group set
to 0 (wheel on SunOS) and permissions set to 644.
* ENSURE that /etc, /bin, /usr/etc, /usr/bin and /tmp are owned by
root and that the sticky-bit is set on /tmp.
ie. permissions on /tmp should be: drwxrwxrwt.
You should implement COPS or Tiger to check for this.
Refer to section B.2 for information where to obtain these.
* ENSURE that there are no unexpected world writable files or
directories on your system. The following commands find world
writeable files and directories.
# /bin/find / -type f -perm -22 -exec ls -l {} \;
# /bin/find / -type d -perm -22 -exec ls -ld {} \;
* CHECK that files which have the SUID or SGID bit enabled, should have
it enabled:
# /bin/find / -type f \( -perm -004000 -o -perm -002000 \) \
-exec ls -l {} \;
* CHECK the umask value for each user and ensure it is set to
something sensible like 027 or 077. Refer to section E.1 for a
shell script to check this.
5.6 Files run by root
AUSCERT recommends that anything run by root should be owned by
root, should not be world or group writable and should be located
in a directory where every directory in the path 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
- /etc/rc* and similar system startup files
* If any programs or scripts referenced in these files source further
programs or scripts they also need to be verified.
5.7 Bin ownership
Many systems ship files and directories owned by bin. 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 (wheel group under
SunOS).
Anything else should be verified with the vendor.
5.8 Tiger/COPS
* Do run one or both of these.
Many of the checks in this section can be automated by using
these programs. For information on where to get these programs
see B.2.
------------------------------------------------------------------------------
6.0 SunOS specific security
------------------------------------------------------------------------------
The following is a list of security issues that relate specifically
to SunOS 4.1.x. This is not necessarily a complete list.
6.1 IP forwarding
* CHECK that IP forwarding is disabled.
You will need the following line in the kernel configuration
file:
options "IPFORWARDING=-1"
For information on how to customise a kernel, see the file:
/usr/sys/`arch`/conf/README
6.2 Framebuffers /dev/fb
If somebody can log in to your Sun workstation from
a remote source, they can read the contents of your Framebuffer,
which is /dev/fb. Sun provides a mechanism which allows the user
logging in to have exclusive access to the Framebuffer, by using
the file /etc/fbtab. A sample /etc/fbtab file:
#
# File: /etc/fbtab
# 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/fb
/dev/console 0600 /dev/bwone0:/dev/bwtwo0
/dev/console 0600 /dev/cgone0:/dev/cgtwo0:/dev/cgthree0
/dev/console 0600 /dev/cgfour0:/dev/cgsix0:/dev/cgeight0
/dev/console 0600 /dev/cgnine0:/dev/cgtwelve0
#
/dev/console 0600 /dev/kb:/dev/mouse
/dev/console 0600 /dev/fd0c:/dev/rfd0c
After the above file has been created, reboot your machine, or log
out fully, then log back in again.
Read the man page for fbtab(5) for more information.
6.3 /usr/kvm/sys/*
* CHECK all files and directories under /usr/kvm/sys/ are not
writable by group.
In SunOs 4.1.4 the default mode is 2775 with group staff,
allowing users in group staff to trojan the kernel.
6.4 /dev/nit (Network Interface Tap)
* DO run the CERT tool cpm to check if your system is running in
promiscuous mode.
For access details for cpm see B.6.
* DO disable the /dev/nit interface if you do not need to run in
promiscuous mode.
For SunOS 4.x and Solbourne systems, the promiscuous interface
to the network can be eliminated by removing the /dev/nit
capability from the kernel. Once the procedure is complete, you
may remove the device file /dev/nit since it is no longer
functional.
Apply "method 1" as outlined in the System and Network
Administration manual, in the section, "Sun System
Administration Procedures," Chapter 9, "Reconfiguring the
System Kernel." Excerpts from the method are reproduced below:
# cd /usr/kvm/sys/sun[3,3x,4,4c]/conf
# cp CONFIG_FILE SYS_NAME
[Note that at this step, you should replace the CONFIG_FILE
with your system specific configuration file if one exists.]
# chmod +w SYS_NAME
# vi SYS_NAME
#
# The following are for streams NIT support. NIT is used by
# etherfind, traffic, rarpd, and ndbootd. As a rule of thumb,
# NIT is almost always needed on a server and almost never
# needed on a diskless client.
#
pseudo-device snit # streams NIT
pseudo-device pf # packet filter
pseudo-device nbuf # NIT buffering module
[Comment out the 3 "pseudo-device" lines; save and exit the
editor before proceeding.]
# config SYS_NAME
# cd ../SYS_NAME
# make
# mv /vmunix /vmunix.old
# cp vmunix /vmunix
# /etc/halt
> b
[This step will reboot the system with the new kernel.]
[NOTE that even after the new kernel is installed, you need to
take care to ensure that the previous vmunix.old , or other
kernel, is not used to reboot the system.]
See CERT Advisory CA_94.01 (see C.7)
6.5 SUN recommended and security patches are available via anonymous ftp
from
ftp://ftp.auscert.org.au/pub/mirrors/sunsolve1.sun.com/*
------------------------------------------------------------------------------
7.0 IRIX specific security
------------------------------------------------------------------------------
The following is a list of security issues that relate specifically
to the IRIX operating system. This is not necessarily a complete list.
7.1 /usr/lib/vadmin/serial_ports
The /usr/lib/vadmin/serial_ports program is used to initialise the
data files for the serial ports on your system.
(This only be applies to IRIX Version 4 systems, or Version 5
systems that still contain the serial_ports program.)
* DO DISABLE this program
1)If you are not using the serial ports on your IRIX Version 4
system.
2)If you are using serial ports and do not wish to change the
configuration of those ports.
3)If you are using version 5 and the serial_ports program is present.
This program has been superseded by /usr/Cadmin/bin/cports on
Version 5 and therefore, is no longer required.
/usr/lib/vadmin/serial_ports can be disabled by the command:
# /bin/chmod 700 /usr/lib/vadmin/serial_ports
* If you intend changing the serial port configuration, you can still
disable the serial_ports program as above. To change the serial
port configuration, run the serial_ports program as root.
(Refer to AUSCERT Advisory AA-94.05a (see A.1))
7.2 Some IRIX patches are available via anonymous ftp from
ftp://ftp.auscert.org.au/pub/mirrors/ftp.sgi.com/security/*
ftp://ftp.auscert.org.au/pub/mirrors/sgigate.sgi.com/*
------------------------------------------------------------------------------
8.0 X windows security
------------------------------------------------------------------------------
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 windows security
referred to in C.4 below.
8.1 Problems with xdm
Note: Release 6 of X11 is now available and solves many problems
associated with X security which were present in previous releases.
If possible, obtain the source for R6 and compile and install it on
your system. Source for R6 is available via anonymous ftp from:
ftp://munnari.oz.au/X.V11/R6
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.
8.2 X security - General
* DO Read the man pages for xauth and Xsecurity.
Use this information to set up the security level you require.
* CHECK that the permissions on /tmp are set to 1777 (or drwxrwxrwt).
i.e. the sticky bit should be set. The owner MUST always be
root and group ownership should be set to group-id 0, which is
"wheel" 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 is gone forever!
If the permissions or ownership are not set as above, then
type the following commands:
# /bin/chown root.wheel /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.
------------------------------------------------------------------------------
Appendix A: Other AUSCERT information sources
A.1 AUSCERT advisories
Past AUSCERT advisories can be retrieved via anonymous ftp from
ftp://ftp.auscert.org.au/pub/auscert/advisory/*
A.2 AUSCERT's World Wide Web server
AUSCERT maintains a World Wide Web server. Its URL is
http://www.auscert.org.au
------------------------------------------------------------------------------
Appendix B: Useful security tools
There are many good tools available for checking 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.
B.1 Crack
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://ftp.auscert.org.au/pub/cert/tools/crack/*
B.2 COPS and Tiger
These packages identify common security and configuration
problems. They also check for common signs of intrusion.
Though there is some overlap between these two packages, they
are different enough that it may be useful to run both. Both
are available via anonymous ftp.
COPS:
ftp://ftp.auscert.org.au/pub/cert/tools/cops/1.04
tiger:
ftp://ftp.auscert.org.au/pub/mirrors/net.tamu.edu/tiger*
B.3 npasswd and passwd+
These programs are proactive password checkers. They run a
series of checks on passwords at the time users set them and
refuse password that fail the tests. Note that these programs
are not designed to work with shadow password systems. Both are
available via anonymous ftp.
npasswd:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.cc.utexas.edu
/npasswd/npasswd.tar.Z
passwd+:
ftp://ftp.auscert.org.au/pub/mirrors/dartmouth.edu
/security/passwd+.tar.Z
B.4 tcp_wrapper
This software gives logging and access control to most network
services. It is available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl
/tcp_wrappers_7.2.tar.gz
B.5 Tripwire
This package maintains a checksum database of important system
files. It can serve as an early intrusion detection system. It
is available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/coast/COAST/Tripwire/*
B.6 cpm
cpm checks to see if your network interfaces are running in
promiscuous mode. If you do not normally run in this state then
it may be an indication that an intruder is running a network
sniffer on your system. This program was designed to run on
SunOS 4.1.x and may also work on many BSD systems. It is available
via anonymous ftp from:
ftp://ftp.auscert.edu.au/pub/cert/tools/cpm/*
B.7 Vendor supplied C2 security packages
Consult manuals supplied by your vendor as to installing C2
security. The SunOS manual is "SunOS System & Network
Administration Guide".
B.8 Vendor supplied security auditing packages
Sun provides an additional security package called SUNshield.
Please direct enquiries about similar products to your vendor.
B.9 smrsh
The smrsh(8) program is intended as a replacement for /bin/sh
in the program mailer definition of sendmail(8). smrsh is a
restricted shell utility that provides the ability to specify,
through a configuration, an explicit list of executable
programs. When used in conjunction with sendmail, smrsh
effectively limits sendmail's scope of program execution to
only those programs specified in smrsh's configuration.
It is available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/cert/tools/smrsh
B.10 md5
md5 is a message digest algorithm. An implementation of this is
available via anonymous ftp from:
ftp://ftp.auscert.org.au/pub/cert/tools/md5/*
ftp://ftp.auscert.org.au/pub/cert/tools/md5check/*
------------------------------------------------------------------------------
Appendix C: References
C.1 Practical UNIX Security
Simson Garfinkel and Gene Spafford
(C) 1991 O'Reilly & Associates, Inc.
C.2 UNIX Systems Security
Patrick Wood and Stephen Kochan
(C) 1986 Hayden Books
C.3 UNIX system security: A Guide for Users and System Administrators
David A. Curry
Addison-Wesley Professional Computing Series
May 1992.
C.4 X Windows System Administrators Guide
Chapter 4
(C) 1992 O'Reilly & Associates, Inc.
C.5 Information Security Handbook
William Caelli, Dennis Longley and Michael Shain
(C) 1991 MacMillan Publishers Ltd.
C.6 Firewalls and Internet Security
William R. Cheswick & Steven M. Bellovin
(C) 1994 AT&T Bell Laboratories
Addison-Wesley Publishing Company
C.7 CERT advisories can be found via anonymous FTP from
ftp://ftp.auscert.org.au/pub/cert/cert_advisories/*
C.8 UNIX System Administration Handbook
Nemeth, Evi, Garth Snyder and Scott Seebas
Prentice-Hall, Englewood Cliffs(NJ), 1989
C.9 Essential System Administration
Aeleen Frisch
O'Reilly & Associates, Inc.
-----------------------------------------------------------------------------
Appendix D: Abbreviated Checklist
It is intended that this short version of the checklist be used in
conjunction with the full checklist as a progress guide (ie. check
the sections off as you go so that you remember what you have done
so far).
1.0 Patches
[ ] Installed latest patches?
2.0 Network security
[ ] Filtering
[ ] "r" commands
[ ] /etc/hosts.equiv
[ ] $HOME/.rhosts
[ ] NFS
[ ] /etc/hosts.lpd
[ ] /etc/ttytab
[ ] /etc/inetd.conf
[ ] Trivial ftp (tftp)
[ ] /etc/services
[ ] tcp_wrapper (also known as log_tcp)
[ ] /etc/aliases
[ ] /etc/sendmail.cf
[ ] majordomo
[ ] fingerd
[ ] UUCP
3.0 ftpd and Anonymous ftp
[ ] Versions
[ ] SITE EXEC
[ ] Configuration of your ftp server
[ ] Permissions
[ ] Writable directories
[ ] Disk mounting
4.0 Password and account security
[ ] Policy
[ ] Proactive Checking
[ ] Root Password
[ ] NIS and /etc/passwd entries
[ ] Password shadowing and C2 security
[ ] Administration
[ ] Special accounts
[ ] Root account
5.0 File system security
[ ] General
[ ] /etc/rc.local
[ ] /usr/lib/expreserve
[ ] External file systems/devices
[ ] File Permissions
[ ] Files run by root
[ ] Bin ownership
[ ] Tiger/COPS
6.0 SUNOS specific security
[ ] IP forwarding
[ ] Framebuffers /dev/fb
[ ] /usr/kvm/sys/*
[ ] /dev/nit (Network Interface Tap)
7.0 IRIX specific security
[ ] /usr/lib/vadmin/serial_ports
8.0 X windows security
[ ] Problems with xdm
[ ] X security - General
-----------------------------------------------------------------------------
Appendix E: Shell Scripts
E.1 Script for printing the umask value for each user.
#!/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
-----------------------------------------------------------------------------
The AUSCERT team have made every effort to ensure that the information
contained in this checklist is accurate. However, the decision to use the tools
and techniques described is the responsiblitiy of each user or organization.
The appropriateness of each item for an orgaization or individual system should
be considered before application. AUSCERT takes no responsibility for the
consequences of applying the contents of this document.
Please feel free to copy and distribute this document provided you acknowledge
AUSCERT copyright.
(C) Copyright 1995
-----------------------------------------------------------------------------
If you believe that your system has been compromised, contact AUSCERT or your
representative in FIRST (Forum of Incident Response and Security Teams).
Internet Email: AUSCERT@AUSCERT.org.au
AUSCERT Hotline: (07) 365 4417
Facsimile: (07) 365 4477
AUSCERT personnel answer during business hours (AEST - GMT+10:00),
on call after hours for emergencies.
Australian Computer Emergency Response Team
c/- Prentice Centre
The University of Queensland
Brisbane, Australia
Qld. 4072.