Securing Services With TCP Wrappers and xinetd

TCP Wrappers provide access control to a variety of services. Most modern network services, such as SSH, Telnet, and FTP, make use of TCP Wrappers, which stand guard between an incoming request and the requested service.

The benefits offered by TCP Wrappers are enhanced when used in conjunction with xinetd, a super server that provides additional access, logging, binding, redirection, and resource utilization control.

It is a good idea to use iptables firewall rules in conjunction with TCP Wrappers and xinetd to create redundancy within service access controls. Refer to "Firewalls" for more information about implementing firewalls with iptables commands.

Refer to "TCP Wrappers" for more information on configuring TCP Wrappers and xinetd.

The following subsections assume a basic knowledge of each topic and focus on specific security options.

Enhancing Security With TCP Wrappers

TCP Wrappers are capable of much more than denying access to services. This section illustrates how they can be used to send connection banners, warn of attacks from particular hosts, and enhance logging functionality. Refer to the hosts_options man page for information about the TCP Wrapper functionality and control language.

Displaying a suitable banner when users connect to a service is a good way to let potential attackers know that the system administrator is being vigilant. You can also control what information about the system is presented to users. To implement a TCP Wrappers banner for a service, use the banner option.

This example implements a banner for vsftpd. To begin, create a banner file. It can be anywhere on the system, but it must have same name as the daemon. For this example, the file is called /etc/banners/vsftpd and contains the following line:

220-Hello, %c
220-All activity on ftp.example.com is logged.
220-Inappropriate use will result in your access privileges being removed.

The %c token supplies a variety of client information, such as the username and hostname, or the username and IP address to make the connection even more intimidating.

For this banner to be displayed to incoming connections, add the following line to the /etc/hosts.allow file:

vsftpd : ALL : banners /etc/banners/

TCP Wrappers and Attack Warnings

If a particular host or network has been detected attacking the server, TCP Wrappers can be used to warn the administrator of subsequent attacks from that host or network using the spawn directive.

In this example, assume that a cracker from the 206.182.68.0/24 network has been detected attempting to attack the server. Place the following line in the /etc/hosts.deny file to deny any connection attempts from that network, and to log the attempts to a special file:

ALL : 206.182.68.0 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert

The %d token supplies the name of the service that the attacker was trying to access.

To allow the connection and log it, place the spawn directive in the /etc/hosts.allow file.

Because the spawn directive executes any shell command, create a special script to notify the administrator or execute a chain of commands in the event that a particular client attempts to connect to the server.

TCP Wrappers and Enhanced Logging

If certain types of connections are of more concern than others, the log level can be elevated for that service using the severity option.

For this example, assume that anyone attempting to connect to port 23 (the Telnet port) on an FTP server is a cracker. To denote this, place an emerg flag in the log files instead of the default flag, info, and deny the connection.

To do this, place the following line in /etc/hosts.deny:

in.telnetd : ALL : severity emerg

This uses the default authpriv logging facility, but elevates the priority from the default value of info to emerg, which posts log messages directly to the console.

Enhancing Security With xinetd

This section focuses on using xinetd to set a trap service and using it to control resource levels available to any given xinetd service. Setting resource limits for services can help thwart Denial of Service (DoS) attacks. Refer to the man pages for xinetd and xinetd.conf for a list of available options.

Setting a Trap

One important feature of xinetd is its ability to add hosts to a global no_access list. Hosts on this list are denied subsequent connections to services managed by xinetd for a specified period or until xinetd is restarted. You can do this using the SENSOR attribute. This is an easy way to block hosts attempting to scan the ports on the server.

The first step in setting up a SENSOR is to choose a service you do not plan on using. For this example, Telnet is used.

Edit the file /etc/xinetd.d/telnet and change the flags line to read:

flags           = SENSOR

Add the following line:

deny_time       = 30

This denies any further connection attempts to that port by that host for 30 minutes. Other acceptable values for the deny_time attribute are FOREVER, which keeps the ban in effect until xinetd is restarted, and NEVER, which allows the connection and logs it.

Finally, the last line should read:

disable         = no

This enables the trap itself.

While using SENSOR is a good way to detect and stop connections from undesirable hosts, it has two drawbacks:

It does not work against stealth scans.

An attacker who knows that a SENSOR is running can mount a Denial of Service attack against particular hosts by forging their IP addresses and connecting to the forbidden port.

Controlling Server Resources

Another important feature of xinetd is its ability to set resource limits for services under its control.

It does this using the following directives:

cps = <number_of_connections> <wait_period> - Limits the rate of incoming connections. This directive takes two arguments:

<number_of_connections> - The number of connections per second to handle. If the rate of incoming connections is higher than this, the service is temporarily disabled. The default value is fifty (50).

<wait_period> - The number of seconds to wait before re-enabling the service after it has been disabled. The default interval is ten (10) seconds.

instances = <number_of_connections> - Specifies the total number of connections allowed to a service. This directive accepts either an integer value or UNLIMITED.
per_source = <number_of_connections> - Specifies the number of connections allowed to a service by each host. This directive accepts either an integer value or UNLIMITED.
rlimit_as = <number[K|M]> - Specifies the amount of memory address space the service can occupy in kilobytes or megabytes. This directive accepts either an integer value or UNLIMITED.
rlimit_cpu = <number_of_seconds> - Specifies the amount of time in seconds that a service may occupy the CPU. This directive accepts either an integer value or UNLIMITED.

Using these directives can help prevent any single xinetd service from overwhelming the system, resulting in a denial of service.