2.5 SECURING (DISABLING) SERVICES

2.5.2 Create a List of Services That Should Be Started

Some or all of the services described below may appear in the output from the previous chkconfig command.

2.5.2.1 Independent Services

The list of services that should be run for every system is short. They are summarized in the table below:

2.5.2.1.1 gpm

Adds mouse support for the console mode text-based applications. If this is a workstation and X-Windows is installed, then this service should be off and the rpm package ( gpm ) can safely be removed. If this is a server without X-Windows and mouse support is desired at the console, this service should be on.

2.5.2.1.2 sshd (http://www.openssh.org/portable.html)

The sshd service encrypts all network communication and provides interactive shell and file transfer access for remote users. Note that the sshd service is NOT required by local users when making outbound connections from this system to another system with the ssh or scp commands. If users will need to access the system remotely, the sshd service should be configured ON so it will start when the system boots.

2.5.2.1.3 kudzu

The kudzu service enables automatic detection and configuration of system hardware changes. If configured to start, it will probe the system for hardware changes every time the system boots. If hardware changes occur only infrequently, then the service should be off. Note that kudzu can be manually started anytime to detect new hardware using the following command:

[root@localhost]# /etc/init.d/kudzu start

2.5.2.1.4 xinetd (http://www.xinetd.org)

The xinetd service manages the operation and start-up of many familiar services (see next section). If none of the services controlled by xinetd need to be turned on, the xinetd service should be off and the rpm package (xinetd) can safely be removed. Note that this service should probably be off for most workstations.

2.5.2.2 xinetd-Based Services

2.5.2.2.1 telnet

The telnet service provides remote shell access to a system without verifying the identity of the originating host or encrypting the data sent across the network. The service is inherently insecure and should not be used for connections across the Internet. Telnet should be off and the rpm package (telnet-server) can safely be removed. Note that users may still use the telnet client to make outbound connections even if the service is disabled.

2.5.2.2.2 wu-ftpd (http://www.wu-ftpd.org)

The wu-ftpd provides file transfer protocol service for remote users to transfer files to the system without verifying the identity of the originating host or encrypting the data sent across the network. The service is inherently insecure and, in general, should not be used for connections across the Internet. The primary exception is anonymous ftp servers commonly used for distribution of software source code and patches. Unless the system is an ftp server, wu-ftpd should be off and the rpm packages (wu-ftpd and anonftp) can safely be removed.

2.5.2.2.3 rlogin, rsh, rexec (The Berkeley r-services )

All of these services originating from BSD UNIX support weak IP based authentication and transmit data across the network as clear text ( i.e. unencrypted). Note that this includes user login names and passwords. SSH was designed to duplicate the functionality provided by these services and can be configured to replace them in a way that is transparent for the system's users. These services should be off and the corresponding rpm package (rsh-server) can safely be removed.

2.5.2.2.4 snmpd - Simple Network Management Protocol daemon (http://www.snmplink.org)

The snmpd service is used to communicate with network management software. If there is no need for the system to cooperate with centralized network monitoring applications, the service should be off and the rpm package (snmpd) can safely be removed.

If the service is on, be sure to review the /etc/snmpd/snmpd.conf file. Settings in the file control who has access to the snmpd agent and what level of information the agent will provide. See the snmpd.conf(5) man page for more information.

2.5.2.2.5 tftp - Trivial File Transfer Protocol

The tftp service enables file transfers without any authentication credentials. The most common use of this protocol is by network devices that need to download configuration files from the network during their boot sequence. Unless the system is a boot server, tftp should be off and the rpm package (tftp-server) can safely be removed.

2.5.3 Disable and Remove Services That Should Not be Started

Any service that is not needed should be stopped and configured not to start on boot using the following commands:

[root@localhost]# /etc/init.d/

servicename

stop
    [root@localhost]# /sbin/chkconfig --level 0123456

servicename

off

In the commands, replace servicename with the name of a service shown in the leftmost column of the list output above (e.g. netfs or wuftpd). Repeat the command for each service.

The rpm package corresponding to the service should be removed using the command:

[root@localhost]# /bin/rpm -e

packagename

In the command, replace packagename with the name of the rpm package to which the service belongs.

The package owning a given file can be determined with the following command:

[root@localhost]# rpm --qf /etc/init.d/servicename

2.5.4 [Optional] Verify Configuration of Run-Level Services

Repeat Step 2.5.1 and verify that the list of services that are configured to be on matches the list expected for the system.

2.5.5 Configure Access to Any Enabled Services

2.5.5.1 TCP Wrappers (ftp://ftp.porcupine.org/pub/security/index.html)

Access control to services compiled with TCP wrappers support is implemented by the /etc/hosts.allow and /etc/hosts.deny files. When a connection attempt is made, the hosts.allow file is checked. If a line is matched, the connection is allowed. Then the hosts .deny file is consulted, if a line is matched, the connection is denied . If no matches have occurred in either file, the connection is allowed.

2.5.5.1.1 Create Authorized Use Only Banners

If configured as described below, TCP wrappers will display a warning banner to any user attempting to connect to a service it monitors . The following set of commands generate the directory /etc/banners , and the files therein contain warning banner text for each service. In this example, the banner text is "Use of this system is restricted to authorized users." Note that exact wording of a warning banner is site specific; however, it should at least emphasize that the use of the system is restricted to authorized persons and that consent to monitor activities is implied by logging in to the system.

[root@localhost]# /bin/mkdir -p /etc/banners
    [root@localhost]# /bin/echo "Use of this system is restricted to authorized users" > /etc/banners/
    prototype
    [root@localhost]# cd /etc/banners ; /usr/bin/make -f /usr/share/doc/tcp_wrappers-7.6/Banners.Makefile

2.5.5.1.2 Deny Everything Except What is Explicitly Allowed

In order to implement the security best practice stance of deny everything except what is explicitly allowed, issue the following command.

[root@localhost]# echo 'ALL: ALL: spawn (/bin/echo -e '/bin/date'"\n%c attempted connection to %s
    and was denied" \
    >  /bin/mail -s "Connection attempt to %s" root) &' > /etc/hosts.deny

Any connection attempt not listed in the hosts.allow file will be denied, a message will be logged to the syslog auth facility, and an email will be sent to root.

2.5.5.1.3 Allow Access to Those Who Require It

Edit the hosts.allow file and add a line for each service to which access should be allowed. A few examples are shown below (See the man pages for hosts.allow for more detail).

ALL: LOCAL : banners /etc/banners            # All services from local clients (hostnames with no ".")
    sshd: 10.1.1.0/255.255.254.0 : banners /etc/banners # SSH connections from host IP addresses
    between 10.1.1.0 and 10.1.2.0

2.5.5.2 xinetd

If xinetd has been disabled or removed (typically the case for workstations), this step should be skipped .

The xinetd service provides access control to the services that it manages. There should be one file in the /etc/xinetd.d directory for each service. To control access to a service, find the file with the service name and add the following line somewhere between the start and end bracket .

only_from =   10.1.1.0/23      # allow connections from host IP addresses between 10.1.1.0 and 10.1.2.0

[root@localhost]# /usr/bin/perl -p -i.bak -e 's/id:5:init/id:3:init/' /etc/inittab