Networking / Beginners

Operating UNIX Safely

UNIX is a powerful operating system with many tools and capabilities. Even a system that has been properly configured and hardened is still a security risk if users and processes are not properly controlled and monitored.

Any network security attack on a workstation ultimately will come down to running code. The code can fall into one of two categories:

  • Malcode-This consists of viruses, worms, and Trojan horses. This code is either run by the user or on the user's behalf by some scripting application, such as a Web browser.
  • Host services-In this case, the attacker comes in from the network and remotely gets a foothold or access to the workstation by exploiting an open port and its associated service. This is discussed further in the next section, "Controlling processes."

The protection against malcode is twofold: Use antivirus protection and don't engage in risky behavior. Avoiding risky behavior includes the following:

  • Don't open, launch, download, or execute anything that comes from a questionable source. In other words, "Don't talk to strangers." This needs to be periodically reinforced to every level of an organizaton. The weakest-link principle definitely applies here.
  • Whenever possible, disable scripting capabilities on e-mail clients, word processing, and other office productivity products.

Note that the security of any workstation can be enhanced by using encryption. This is discussed briefly in the "Encryption and certificates" section of this tutorial.

Controlling processes

In the early days of UNIX, installations tended to be bare boned, meaning that only the bare essentials were brought into a system during installation. As UNIX and Linux got more popular, installations were made easier and the trend now is to bring in many features. All these unneeded features or applications are potential security risks.

In terms of security, you can group processes or services into three categories, as follows:

  • Avoid if at all possible-Certain services are either out of date or so inherently insecure that they should be avoided and alternatives found.
  • Use as needed-A small group of services are probably worth the risk and are generally more helpful.
  • Probably not needed-Most processes probably fall into this category. Under certain circumstances they have a use but should not be run on most UNIX workstations.

Services to avoid

For the security of the UNIX workstation and the network, it is important that system administrators be kept abreast of the processes running. Because many applications in UNIX operate in a daemon or server mode, they can be ready targets for attackers to exploit.

It is a security principle that unneeded applications or services should not be running. Here are a few services commonly found on a UNIX workstation that are not normally needed.

  • FTP (vsftpd or wuftpd)-FTP is a widely available method of transferring files. It has some vulnerabilities if anonymous access is permitted and it sends passwords in the clear (unencrypted). For these reasons, more secure methods of file transfer, such as scp or sFTP, should be used instead.
  • Network File System (NFS)-Designed for sharing files over a network but over not the Internet. NFS is a remote procedure call (RPC) service using portmap. NFS makes the spreading of malcode such as Trojan horses easier for the attacker.
  • nfslock-The NFS file locking service. If NFS is not being used, this service should be disabled.
  • RPC-This protocol has some inherent security problems and should be avoided if not needed. Few applications these days use RPC. Most users could operate their workstations for years and never need to use RPC. Therefore, it is advisable to turn off RPC services unless otherwise needed. Most implementations of RPC deal with homegrown remote control of the computer or distributed processing. Both of these circumstances are rare.
  • portmap-This service uses RPC to support nfslock.
  • r commands (rsh, rcp, rlogin)-These protocols have weak authentication and pass information in the clear (unencrypted). There are a number of better replacements, such as ssh and scp.
  • telnet-This very simple service allows remote access to a UNIX workstation. Information is passed in the clear, so a third party could easily capture passwords and other sensitive information. Telnet sessions can easily be hijacked and taken over or redirected.

Useful services

The following services should be used if needed. In some cases, they can be made more secure by blocking their ports from the network.

  • iptables-This is a kernel resident packet filter that works off rules controlling packets on input, output, and when they are forwarded through the workstation's network interfaces. iptables adds another layer of security and is an important defense-in-depth addition to the UNIX workstation.
  • keytable-This script loads a keyboard map and system font during the boot.
  • kudzu-This is a hardware-detection program that runs during the boot. It is useful if your workstation frequently has hardware changes, such as a laptop that changes docking stations frequently. If the workstation is stable and does not change, this service can be disabled.
  • network-This script starts the network interfaces and is required if the workstation is connecting to the network.
  • pcmcia-This is the script that inserts pcmcia kernel modules for PCMCIA cards on laptops. Even though laptops probably constitute only a small percent of installed UNIX workstations, this service is often on by default. If not applicable to the workstation's hardware, it should be disabled.
  • Print daemons (cupsd, lpd)-These processes allow the UNIX workstation to print to network printers. While useful for that purpose, these services should not be accessible from the network. iptables should be used to block these ports.
  • random-This script provides for the random seed for the system.
  • rawdevices-This service enables raw Input-Output (IO).
  • sshd-This is the server that supports remote access to the workstation using a Secure Shell (ssh) client. If remote access into the workstation is not needed, this may be disabled.
  • syslog-This process supports the logging of system messages, which can be sent to a central server for analysis and auditing.
  • xfs-The X Font server shares fonts with other machines to speed up font rendering and to support TrueType-style fonts. This process may be required for XWindows to function efficiently. In these cases, the port can be blocked with iptables. Also, XWindows can be started without the feature of xfs looking out to the network. To do this, start X with startx -- -nolisten tcp.
  • xinetd (inetd)-This service starts other services on demand. xinetd is responsible for starting many of the common, small networking daemons. It only runs the daemon when a connection request is made for the particular service. For example, when the machine receives a pop3 request, xinetd starts up the ipop3d daemon to respond to the request. Any service can be made available via xinetd. A simple configuration file identifying the port and the service to run is put in the /etc/xinetd/ directory. The following are typical services run via xinetd. None of these should be needed for a typical UNIX workstation that is not functioning as a server.
    • chargen-A service that continuously generates characters until the connection is dropped. The characters look something like this: # !"#$%&'( )*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefg.
    • cups-lpd-An on-demand version of the print daemons discussed earlier.
    • daytime-A service that gets the current system time then prints it out in a format such as "Wed Nov 13 22:30:27 EST 2002."
    • echo-A service that echos characters back.
    • finger-A service that displays information about users on a system. With the advent of brute force and social engineering attacks, it is no longer advisable to provide user information to non-authenticated users over the network.
    • imap-A service that allows remote users to access their mail using an Internet Message Access Protocol (IMAP) client such as Mutt, Pine, fetchmail, or Netscape Communicator.
    • imaps-A service that allows remote users to access their mail using an IMAP client with Secure Sockets Layer (SSL) support, such as Netscape Communicator or fetchmail.
    • ipop2-A service that allows remote users to access their mail using a POP2 client such as fetchmail. In most cases, clients support POP3 instead of POP2, so enabling this service is rarely necessary.
    • ipop3-A service that allows remote users to access their mail using a POP3 client such as Netscape Communicator, Mutt, or fetchmail.
    • ktalk-A K Desktop Environment (KDE) version of the talk server (accepting talk requests for chatting with users on other systems).
    • ntalk-A server that accepts ntalk connections, for chatting with users on different systems.
    • pop3s-A service that allows remote users to access their mail using a POP3 client with SSL support such as fetchmail.
    • rexec-A server for the rexec routine. The server provides remote execution facilities with authentication based on user names and passwords.
    • rlogin-A server for the rlogin program. The server provides a remote login facility with authentication based on privileged port numbers from trusted hosts.
    • rsh-A server for the rcmd routine and, consequently, for the rsh(1) program. The server provides remote execution facilities with authentication based on privileged port numbers from trusted hosts.
    • rsync?-A server that allows Cyclic Redundancy Check (CRC) checksumming.
    • servers-A service that lists active server processes. This is discussed in detail in a later section.
    • sgi_fam-A file-monitoring daemon. It can be used to get reports when files change.
    • talk-A server that accepts talk requests for chatting with users on other systems.
    • telnet-An on-demand daemon of the telnet service discussed earlier.
    • time-This protocol provides a site-independent, machine-readable date and time. The time service sends back to the originating source the time in seconds since midnight on January 1, 1900.
[Previous] [Contents] [Next]