|
Network Security Checklist for Unix
Workstations
This document provides a checklist along with
implementation guidelines for securing Unix workstations. It is based on the
recommendations provided to Unix users at
Yale University.
|
Precompiled Unix Software discussed here can be
found at:
|
MSIS strongly recommends the
CIS
Benchmarking Tool and
YASSP for Solaris
users. The CIS Benchmarking tool includes more detailed (step-by-step)
implementation guidelines than those summarized below and YASSP
automatically implements many of the steps outlined in this document and
significantly simplifies secure system administration.
1) Maintain System Security
2) Limit Access
3) Network Services
4) Resource Sharing
Implementation Guidelines
1) Maintain System Security
- 1.1) Confirm that latest OS and patches
are installed
: There are usually
security fixes incorporated in the patches. Patches for Linux and Solaris
are available and from the vendor e.g. Solaris,
Redhat Linux,
AIX, IRIX.
If the vendor has patch clusters or packs that contain all known fixes
since release, it's advised just to install the whole package every time.
1.2) Check logs regularly for suspicious
activity: Exploit signatures and
unauthorized logins often manifest themselves in the systems logs (e.g., a
failed service that was attacked). Consider using
Logcheck to help you
see anomalies. Intruders are well aware of the importance of log files and
often modify or delete them so consider storing a copy remotely.
1.3) Regularly check file system integrity:
Use a program like Tripwire, AIDE, or ISS System Scanner to determine if
critical system files have been modified by an intruder or accidentally
during a system upgrade (some patches change system configuration in
unexpected ways).
1.4) Make regular backups:
Backup system to tape or if you can't backup the whole system, then at
least ensure that important data is backed up.
2) Limit Access
- 2.1) Use password protected
screensaver: Use of screensaver passwords provides additional physical
protection of Unix workstations.
2.2) Restrict access to X server:
An open X display allows anyone, anywhere to view your screen, capture
keystrokes and even execute commands remotely. This is a serious
vulnerability that is easily fixed using xhosts or xauth. The xhost
program is used to add and delete host names or user names to the list
allowed to make connections to the X server, providing a rudimentary form
of privacy control and security sufficient for a workstation environment
(e.g. xhost +user@host when granting access). For greater protection you
can use a key-based protection scheme, such as xauth. Also, tunnel all X
sessions through SSH as described at
http://www.openssh.org/faq.html.
2.3) Disable ability to log on remotely as
root: Older systems Only terminals
marked as secure in the file /etc/ttytab file will allow any user with UID
= 0 to login directly. At all other terminals the user will need to login
as a normal user and then su to root. For new Linux systems, the file
/etc/securetty controls remote root access. If any entry has the value
ttyp, then remote root logins are possible. On newer versions of Solaris,
make sure to enable the "CONSOLE" line in /etc/default/login and to
disable use of ftp by root by adding "root" to /etc/ftpusers.
2.4) Ensure that root password is strong:
If an intruder obtains the password file or has an account on the machine,
it may be possible to guess the root password.
2.5) Regularly review user list and
remove unnecessary accounts:
2.6) Limit network access to system
using IPFilter, IPChains, TCPWrappers and SSH: Allowing individuals to
connect to your machine over the network is risky and should be restricted
as much as possible. There are several applications that enable you to
restrict access to your computer over the network. IPFilter is a
host-based firewall for Solaris/SunOS, IRIX, and BSD that plugs into the
kernel and can be configured to restrict access to a machine on a packet
by packet basis. IPChains is a host-based firewall for Linux that is
preinstalled (but not enabled) on Linux RedHat 6.x and 7. Some commercial
versions of Unix have IP packet filtering functionality their newer
implementations (e.g. AIX 4.3 - chfilt, lsfilt).
TCPWrappers can be configured to restrict
access to certain services on a Unix machine and make detailed syslog
entries to help administrators track problems and detect intrusion
attempts. Redhat Linux comes with TCPWrappers but must be configured using
the hosts.allow and hosts.deny files.
For installation and configuration
instructions see:
IPFilter,
IPChains, and
TCPWrappers. Installation tips for SSH are provided below. Restrict
access to SSH using the AllowsHost or DenyHosts variables in the sshd
configuration file. As a general rule, configure your SSH server to deny
remote root logins by setting the PermitRootLogin flag to "no" in /etc/sshd_config
and be sure to set the DSAAuthentication flag to "yes" if you are using
DSA keys to authenticate.
Note that many network applications can be
compiled with libwrap, allowing you to use a single restrict file in lieu
of separate files such as /etc/sshd_config.
2.7) Remove /etc/hosts.equiv and /.rhosts:
Remove /etc/hosts.equiv and /.rhosts unless you have some overriding need
for them. If using host.equiv or even host.allow and host.deny files,
ensure that they are only writable by root.
2.8) Set file permissions:
Ensure that startup files and other core system files can only be modified
by root. On Solaris, you can use
fix-modes
to set permissions on important files on Solaris systems. Consider using
hardening scripts such as Bastille Linux (http://www.bastille-linux.org/)
and Hardening Solaris (http://yassp.parc.xerox.com/).
2.9) Display legal notice: It is
generally believed that logon warning banners will help when prosecuting
unauthorized users. The following commands insert warning banners:
echo "Authorized uses only. All activity
may be monitored and reported." >> /etc/motd
echo "Authorized uses only. All activity may be monitored and reported."
>> /etc/issue
echo "Authorized uses only. All activity may be monitored and reported."
>> /etc/default/telnetd
echo "Authorized uses only. All activity may be monitored and reported."
>> /etc/default/ftpd
3) Network Services
Most Unix systems have a large number of
network services enabled, allowing remote individuals (anyone in the world)
to connect to the system and gain various levels of access. Any of these
services can contain a vulnerability that is just waiting to be discovered
and exploited (see the
Vulnerabilities
page). Therefore, to prevent unauthorized access, great care must be taken
to minimize the number of network services running on the machine and
restrict access to services that are running on the system. Also, many of
the network services that come with Unix are not secure (e.g. Telnet, FTP,
rsh) and should be replaced with secure alternatives such as
SSH.
ftp:
enables an FTP server that introduces a variety of insecurities and is
the cause of many intrusions. Disable this and use
SSH instead to
transfer files between systems.
telnet, shell, login, exec:
allows users from other systems to log into and run commands on your
machine. This is useful, but the more useful something is, the more
likely it is that someone will find a way to exploit it. Disable these
services and, if you do need to allow remote logins, use
SSH instead.
comsat:
a daemon which is used to notify users of newly arrived email. There are
alternate means of doing the same thing, and there are occasional rumors
of security problems with comsat. Unless you have some overwhelming need
for this, turn it off.
talk:
allows users to communicate by typing at each others’ terminals. If you
need to use this feature, restrict access to the service using
TCPwrappers and IPFilter/IPChains.
uucp:
Nobody uses uucp anymore - disable this. While you are at it, you may as
well turn off execute permission on the uucp-related shell commands.
tftp:
FTP without any security. This should be needed only if your system will
be used for booting workstations. If this is the case, you must invoke
the daemon with the -s flag, as in:
If you don't, tftp can be used to
retrieve any file from your system, anonymously. Also make all the files
in the bootfile directory read-only. Finally, restrict access to the
service using TCPwrappers and IPFilter/IPChains.
finger:
this gives out information on who is loggedin, or people's phone
numbers and offices. Unfortunately this information can be used by a
potential intruder to find accounts to attack. You may wish to disable
this, run a custom finger daemon, or restrict access to it using
TCPwrappers and IPFilter/IPChains.
systat, netstat:
these services give out information about your system. The comments for
finger apply to these.
time:
Gives out the system time to any remote host that asks for it. Probably
safe but can be disabled without impacting the system.
echo, discard, daytime, chargen:
these are used for testing, and are generally safe, though there have
been reports of TCP packets with forged IP source addresses being used
to trick a system into sending echo packets to itself, causing a packet
storm on the local ethernet segment. Disable them and only turn them on
while testing.
rexd
- this is the Remote Procedure Call mechanism. It has minimal
authentication, so disable it and use SSH
instead.
walld:
allows people to send messages to all logged in users. Useful, but
easily abused. Disable this service or restrict access to it using
TCPwrappers and IPFilter/IPChains.
ttdbserverd (tooltalk):
used by some convenient desktop elements but not important from a system
operation standpoint. Some versions of this service contain serious
remote exploits and should be disabled (dsabling this service causes
virtually no operational degradation).
rpc.cmsd (calendar manager):
used to share calendar information over the network but not important
from a system operation standpoint. Some versions of this service
contain serious remote exploits and should be disabled.
others:
Other services such as sadmind (once found to be vulnerabale to remote
root exploit) and kerberos can be disabled without impacting the system.
- 3.3) Disable unnecessary services in rc2.d
and rc3.d
: Many services are not
controlled by inetd but rather are spawned during the boot process. These
standalone daemons do not use inetd so TCPWrappers will have no effect. On
the other hand,
IPFilter/IPChains can be used to restrict access
to these services.
Standalone services can be disabled by renaming the associated startup
script in one of the /etc/rc*.d directories. For instance, if you do not
want sendmail, rename the S80Sendmail file in /etc/rc.d to
disable.S80Sendmail.
Some services started in /etc/rc*.d are described here with their
associated risks.
Common Desktop Environment (CDE):
Many graphical user interfaces on Unix require remote procedure call (RPC)
services and other daemons that introduce insecurities. For instance,
the Gnome package on Linux opens a number of listening ports. Recently,
the common desktop environment on Solaris has introduced the serious
vulnerabilities that were widely exploited to gain remote root access.
If you must run a desktop environment, be sure to restrict access to all
network services that it provides. This can be achieved by implementing
a host-based firewall, as described in section 2.6, that denies all
traffic unless specified otherwise (default-deny policy).
Network File System (NFS): Allowing other machines to access your
computer’s file system is inherently risky. For example, a
misconfiguration can give unrestricted access to files on your system,
including password files and private data. Also, there have been
vulnerabilities in NFS that have allowed unauthorized access to files.
Specifically, NFS uses the portmapper - a notoriously problematic daemon
from a security perspective. If you must run NFS, see the next Shared
Resources section for security requirements.
Sendmail: It is not necessary to run Sendmail in order to send
e-mail from the system. Sendmail is an e-mail server that accepts
incoming e-mail that is addressed directly to the computer system it is
running on. Running an e-mail server like Sendmail can be abused in two
ways. First, some servers allow anyone on the Internet to relay e-mail
through a mail server. This is regularly abused to send unsolicited junk
e-mail to thousands of users on the Internet. Second, mail servers have
had vulnerabilities in the past that allowed remote individuals to gain
unauthorized access to a computer. If you cannot use the central SOM
e-mail services and must run Sendmail, contact the ISO and we will
implement security measures at the network level to protect your mail
server.
POP/IMAP: Running a server that allows individuals to retrieve
e-mail from a machine is a security risk both because passwords are sent
in plain text and because serious vulnerabilities have been found in
these servers. If you cannot use the central SOM e-mail services and
must run Sendmail, contact the ISO and we will recommend ways to protect
your POP/IMAP server (e.g. using SSL).
- 3.4) Enable buffer overflow protection
:
Protection against buffer overflows - user stack execution prevention.
There is a kernel patch for Linux. On Solaris, put the following in
/etc/system and rebooting:
- 3.5) Disable incoming remote syslog
:
Prevent incoming remote syslog messages whenever possible. Unless this is
a syslog server that accepts and stores logs from remote hosts, use syslog
-t on newer versions of Solaris (in /etc/init.d/syslog) to prevent the
syslogd from accepting messages from remote systems via UPD port 514.
- 3.5) Kernel settings
:
Security related kernel settings for Solaris are detailed at
http://www.sun.com/bluprints/1299/network.pdf along with a well
documented script.
4) Shared Resources
Shared resources, notably exported file
systems, should be limited in terms of access and control. The following
suggest guidelines for sharing resources on Unix systems using NFS or Samba.
:
To disable NFS, move or rename the nfs.server startup script in rc3.d. If
you must use NFS export systems readonly if possible and then only to
hosts that require them. Check that all system programs and system
directories (including all parent directories all the way up to root) are
owned by root, rather than some other user such as bin. The reason for
this is that NFS treats numeric userids as equivalent between systems,
except for root which it maps to nobody. If say, the executable files in
/bin are owned by bin, a malicious sysadmin on another system could NFS
mount this directory and overwrite the files. Also restrict access to port
111 (portmapper) using IPCHAINS/IPFILTER.
4.2) Confirm mounts are nosuid:
Mount file systems with the nosuid option by supplying the arguments "-o
nosuid" to the mount command or by using the keyword nosuid in the options
field of the /etc/fstab file.
4.3) Mount file systems read-only when
possible: Mounting file systems
containing system binaries read-only makes malicious or accidental changes
to the system more difficult.
4.4) Restrict NFS client requests to
privileged ports: On Solaris, put
the following in /etc/system and rebooting:
Back to top of page |
Home
