15.6. TCP Wrappers

15.6. TCP Wrappers
Prev	Chapter 15. Security	Next

Written by Tom Rhodes.

TCP Wrappers extends the abilities of Section 29.2, “The inetd “Super-Server”” to provide support for every server daemon under its control. It can be configured to provide logging support, return messages to connections, and permit a daemon to only accept internal connections. While some of these features can be provided by implementing a firewall, TCP Wrappers adds an extra layer of protection and goes beyond the amount of control a firewall can provide.

TCP Wrappers should not be considered a replacement for a properly configured firewall. TCP Wrappers should be used in conjunction with a firewall and other security enhancements.

15.6.1. Initial Configuration

To enable TCP Wrappers in FreeBSD, ensure the inetd(8) server is started from /etc/rc.conf with -Ww. Then, properly configure /etc/hosts.allow.

Note:

Unlike other implementations of TCP Wrappers, the use of hosts.deny has been deprecated. All configuration options should be placed in /etc/hosts.allow.

In the simplest configuration, daemon connection policies are set to either be permitted or blocked depending on the options in /etc/hosts.allow. The default configuration in FreeBSD is to allow a connection to every daemon started with inetd(8).

Basic configuration usually takes the form of daemon : address : action, where daemon is the daemon which inetd(8) started, address is a valid hostname, IP address, or an IPv6 address enclosed in brackets ([ ]), and action is either allow or deny. TCP Wrappers uses a first rule match semantic, meaning that the configuration file is scanned in ascending order for a matching rule. When a match is found, the rule is applied and the search process stops.

For example, to allow POP3 connections via the mail/qpopper daemon, the following lines should be appended to hosts.allow:

# This line is required for POP3 connections: qpopper : ALL : allow

After adding this line, inetd(8) needs to be restarted:

# service inetd restart

15.6.2. Advanced Configuration

TCP Wrappers provides advanced options to allow more control over the way connections are handled. In some cases, it may be appropriate to return a comment to certain hosts or daemon connections. In other cases, a log entry should be recorded or an email sent to the administrator. Other situations may require the use of a service for local connections only. This is all possible through the use of configuration options known as wildcards, expansion characters and external command execution.

15.6.2.1. External Commands

Suppose that a situation occurs where a connection should be denied yet a reason should be sent to the individual who attempted to establish that connection. That action is possible with twist. When a connection attempt is made, twist executes a shell command or script. An example exists in hosts.allow:

# The rest of the daemons are protected. ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h."

In this example, the message “You are not allowed to use daemon from hostname.” will be returned for any daemon not previously configured in the access file. This is useful for sending a reply back to the connection initiator right after the established connection is dropped. Any message returned must be wrapped in quote (") characters.

Warning:

It may be possible to launch a denial of service attack on the server if an attacker, or group of attackers, could flood these daemons with connection requests.

Another possibility is to use spawn. Like twist, spawn implicitly denies the connection and may be used to run external shell commands or scripts. Unlike twist, spawn will not send a reply back to the individual who established the connection. For example, consider the following configuration line:

# We do not allow connections from example.com: ALL : .example.com \ : spawn (/bin/echo %a from %h attempted to access %d >> \ /var/log/connections.log) \ : deny

This will deny all connection attempts from *.example.com and log the hostname, IP address, and the daemon to which access was attempted to /var/log/connections.log.

This example uses the substitution characters %a and %h. Refer to hosts_access(5) for the complete list.

15.6.2.2. Wildcard Options

The ALL option may be used to match every instance of a daemon, domain, or an IP address. Another wildcard is PARANOID which may be used to match any host which provides an IP address that may be forged. For example, PARANOID may be used to define an action to be taken whenever a connection is made from an IP address that differs from its hostname. In this example, all connection requests to sendmail(8) which have an IP address that varies from its hostname will be denied:

# Block possibly spoofed requests to sendmail: sendmail : PARANOID : deny

Caution:

Using the PARANOID wildcard may severely cripple servers if the client or server has a broken DNS setup. Administrator discretion is advised.

To learn more about wildcards and their associated functionality, refer to hosts_access(5).

Before any of the specific configuration lines above will work, the first configuration line should be commented out in hosts.allow.

Prev	Up	Next
15.5. One-time Passwords	Home	15.7. Kerberos5