Yale University

ITS Information Security

Yale ITS Home Information Security

Gateways for:

Help Desk
203.432.9000
203.785.3200

ITS Office
Yale University
25 Science Park
P.O. Box 208276
New Haven, CT
06520-8276
USA

Yale logo.

Network security checklist for Unix workstations

This document provides a checklist along with implementation guidelines for securing Unix workstations. The Information Security Office (ISO) 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

2) Limit access

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.

  • 3.2) Disable unnecessary services in inetd.conf/xinetd.d: As a rule, comment out (by placing a "#" column 1) every line of the /etc/inetd.conf file or, on Redhat 7, remove all configuration files from the /etc/xinetd.d directory to disable network services. Remember: In addition to protecting against known vulnerabilities, you need to protect against the possibility that some newly discovered vulnerability will affect your system. If a particular service is not enabled, no one can use it to break into your system.

    Here is a quick rundown of the risks associated with services started in /etc/inetd.conf:

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:

    tftp dgram udp wait root in.tftpd -s /tftpboot

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 logged­in, 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 Yale 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 Yale 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:
      • set noexec_user_stack=1
      set noexec_user_stack_log=1
  • 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/blueprints/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.

Jump to top.

Last modified: Tuesday, 02-Sep-2008 14:45:20 EDT. (jj)