2.10 Turn Off Unneeded Services 
Each service is a door into the system with varying levels of security. Each service turned off is an access point into the system that is sealed shut. In an effort to be easy to set up and user-friendly, most Linux distributions turn on as many services as possible. Your system likely has remnants of this in the form of services that you do not want, need, know about, and which might not be secure without configuration changes and security patches. These common services and their relative risks will be discussed. The ports C program is on the CD-ROM. It will do a scan of your system's ports to list services available, services in use, and to identify suspicious port numbers in use that might be Trojan horses listening on ports to act as servers to crackers. It is designed to be easy to use. The following is a typical invocation. ports | more The services that are turned on by default vary by distribution and by version within each distribution. Additionally, very few people keep such detailed records that they can look up what services they turned on, and what services they turned off. Sometimes a cracker will insert a Trojan horse into an existing service. There are several good ways to see what services are available. They are listed here and the use of all of them in sequence is recommended. | Several of the author's programs are offered that are written in the C language. To compile any of these into an executable (binary) program, for example, ports.c, do the following: Create or change to a directory to work in (avoid a publicly writable directory such as /tmp). Copy the source file, ports.c, into that directory. Issue the following command to compile the program make ports or invoke the C compiler directly with the command cc o ports ports.c Test it before installation, if desired, via ./ports Give it safe permissions with chmod 755 ports Install it as root in a public directory, if desired, via su cp ports /usr/local/bin/ports Exit the root shell exit If using tcsh or csh, give the command rehash |
Use ports, netstat, or lsof to see what ports have processes listening on them This is an easy way to determine what services are running due to their well-known ports. The services associated with each commonly used TCP and UDP port are listed in Appendix C. The best way to invoke netstat for this purpose is netstat -atuvp | more The -a flag indicates that even ports that are not connected to an associated port on another system should be listed. This is important in order to list servers that do not have clients presently. The -t and -u flags specify that only TCP and UDP services should be listed. The -v flag adds verbosity. The -p flag says to list the name of the active program using each port; it requires root permission. I wrote the ports program to provide results in a form that is easier to interpret than netstat. Additionally, it flags suspicious ports that include active ports known to be used as popular cracker tools. Also, it flags high-numbered ports that are being used for daemons. Normally high-numbered ports are used by clients. These flagged ports too may be Trojan horses planted by crackers. Typical invocation is shown here. ports | more In this phase, we are concerned primarily with securing a system, and are not expecting to find that it has been compromised already. Some systems will be compromised already and some readers will be surprised. (Those that are surprised are asked to send me e-mail at book@verysecurelinux.com with the details.) Examine the startup scripts These will show those services that are supported via daemons. In distributions that follow the UNIX System V-style of startup scripts, there are directories of the form /etc/rc.d/rc[0-6].d. The normal running state is 3. This may be verified with the command grep initdefault /etc/inittab The output will look something like id:3:initdefault: Inspect this output to see what state number is listed, "3" in this case. Then issue the command ls -F /etc/rc.d/rc3.d/S* The listed services are the ones with daemons that are started when the system comes up. On a Red Hat-derived system, there is a menu-driven program that may be used to see and change which of these services are started. To invoke the program issue the command ntsysv Inspect /etc/xinetd.d/* or /etc/inetd.conf The /etc/xinetd.d directory contains a configuration file for each service that will be provided by xinetd, the new superserver. While managing this many configuration files is more effort than the single configuration file of inetd, xinetd has more capabilities suitable for heavy-duty servers. These include limiting the number of simultaneously running instances of a particular service and altering each server's process priority from the default. It has the libwrap library built in to parse the /etc/hosts.allow and hosts.deny files to decide which remote systems are allowed to use each service. By using libwrap, the system load is substantially reduced by eliminating the need to fork the tcpd process to do this. Some of the more useful variables that may be used in a configuration file for a service are disable Disables a service without removing the configuration file. instances Specifies the number of simultaneous instances of a service that are allowed or UNLIMITED to not enforce a limit. nice Increases the niceness (i.e., lowers the server's priority) or vice versa. user Specifies what user permissions the server will run under. group Specifies what group permissions the server will run under. SENSOR Listens on this port for attackers, but does not actually start a server when someone connects. Instead, does not accept further connections from the client system until the deny_time setting expires. This can slow down crackers but is less effective than a good Adaptive Firewall (see "Adaptive Firewalls: Raising the Drawbridge with the Cracker Trap" on page 559). only_from Specifies what hosts are allowed to use this service. It is redundant with respect to TCP Wrappers except that it supports IPv6 addresses. The move to IPv6 seems almost as slow as the move in the U.S. to the metric system. access_times Specifies what times of the day the service will be supported. If you manage a 9-to-5 operation, access_times can be used to prevent people from trying to brute-force crack passwords at night by hitting your SSH, FTP, POP, or IMAP servers. Unfortunately, one cannot specify days of the week, so crackers still can attack you during the day on weekends. It also can be used to limit public services and the requisite load during the day. A better solution would be to have some conditional code in the firewall script file that is keyed to the time of day and day of the week and to invoke this script at the start and end of the business day from cron, as discussed in "Firewall Tricks and Techniques" on page 472.
Not all Linux distributions have moved to xinetd, due to concerns about security bugs and its configuration files requiring more effort to maintain. Additionally, there is not an overwhelming advantage over inetd. Unlike xinetd, the inetd program uses the single /etc/inetd.conf text file to list all of the ports that it will listen on, then it forks the appropriate program to process the request. Red Hat's inetdconvert program for converting one's inetd.conf to configuration files suitable for xinetd was discussed in "Revving Up Red Hat 7.3" on page 66. Use ps to list processes The ps (Process Status) command may be used to list all running processes on the system and then recognize those that are daemons. This requires a fair amount of system knowledge. Many daemons have names that end in "d" (for daemon). The following invocation of ps is typical. ps -axlww The a flag causes the listing of all processes, not just those on the invoker's terminal. The x flag indicates that even processes not associated with a terminal should be listed. These typically are invoked during system startup or via cron. The l flag indicates a long listing. The w indicates wide; the output will be truncated at 130 160 columns instead of 80, depending on the Linux distribution and version. The second w indicates wider; the output will be unlimited on Red Hat. On Slackware, each w adds another 80 columns of possible output. The suggested rules for deciding which services to allow are as follows: Do not run any service that you do not understand well. It is easier to turn them on after you understand them than it is to recover from an intrusion and violated confidentiality. If you do not understand it, you cannot understand the security implications. If you do not understand the security, you might not have any security. These issues are covered in great detail in this book. Consider the choice of leaving a service on, risking reduced security, versus turning the service off and "breaking something." Pick better security and turn it off. For assistance, try searching this book's Table of Contents and Index for the services you are not sure about. UDP source addresses can be faked easily, so services that rely on UDP source addresses for security are not secure (unless you absolutely trust every system that can "get to" the clients and servers using UDP). See "Why UDP Packet Spoofing Is Successful" on page 242 for more information. If the systems on your LAN can be trusted, and your UDP services will talk only to IP addresses on your LAN, and your firewall will block outside systems spoofing these addresses, UDP services may be safely used for authentication. That is a lot of conditions. Avoid services that send clear text passwords (unencrypted passwords) over the network. Telnet, FTP, pop3, imap, and http are the worst violators. Avoid services that send unencrypted confidential data over the network. Telnet, FTP, pop3, imap, and http are the worst violators. Confidential e-mail should be wrapped in PGP. Be careful of services that have suffered many vulnerabilities in the past. These include nfsd, rshd, rlogind, rexecd, ftpd, sendmail, named, and any UDP service but there are others too.
Table 2.3 lists the most dangerous services that should be turned off in many installations. Note that any service has potential for danger. Table 2.3. Dangerous ServicesDanger Level | Name | Where Discussed |
|---|
| rsh, rlogin, and rexec | "The rsh, rcp, rexec, and rlogin Services" on page 198 |
| nfs, mountd, lockd, statd, quotd | "Turn Off NFS, mountd, and portmap" on page 98 |
| telnet | "Protecting User Sessions with SSH" on page 409 |
| sendmail | "Sendmail" on page 174 | 
| finger | "Do Not Get the Finger" on page 94 |
| tftp | "Turn Off TFTP" on page 102 |
| printer | "The print Service (lpd)" on page 231 |
| ftp | "FTP" on page 190 |
| ident (auth) | "The ident Service" on page 231 |
| www (httpd) | "Scouting Out Apache (httpd) Problems" on page 275 |
| pop3 & imap | "POP and IMAP Servers" on page 204 | 
| systat and netstat | "Turn Off systat and netstat" on page 102 |
| linuxconf | "Linuxconf via TCP Port 98" on page 403 |
| named (DNS) | "DNS (named, a.k.a. BIND)" on page 201 | 
| rwhod | "Turn Off rwhod" on page 95 |
| rwalld[*] | "Turn Off rwalld" on page 96 |
| syslog | "The syslogd Service" on page 230 |
| ingreslock | "The Mysterious Ingreslock" on page 395 |
| talk & ntalk[*] | "Turn Off talk and ntalk" on page 101 |
| chargen[*] | "Turn Off Echo and Chargen" on page 101 |
[*] Has DoS Potential. Do not allow service from external sites.
The C program (ports.c) that is discussed here will list all your TCP and UDP ports that are open; what state they are in; the remote IP, host, and port that they are connected to (if any); and will note possible security breaches due to unusual port usage. Its ability to generate alerts for unusual port activity that might be cracker activity is an advantage over netstat -atuvp A copy of ports.c is on the CD-ROM. It is suggested that you use it periodically to see what services your systems are supporting, to aid in analysis. Many people are surprised at how many services are running on their systems, with some services easily cracked. Note that the ports with named services in all CAPITAL LETTERS are the default port numbers for some known Trojan horses. In many cases a Trojan will be tweaked to use a different port to make detection harder. There are stealth versions of some of the DDoS Trojan horses such as trin00 that listen for instructions without keeping any TCP or UDP ports open and thus are very hard to detect. See "Stealth Trojan Horses" on page 400 for details. The ports.c program will not detect a rogue on your system that has placed your Ethernet card in Promiscuous mode and is stealthily listening to all network traffic. See "Detecting Promiscuous Network Interface Cards" on page 656 on how to detect that problem.
|
