How to Implement TCP Wrappers

TCP Wrappers work in the manner of a host-based Access Control List. They are used to filter out network access to Internet Protocol (IP) servers that are running Linux, Unix, or BSD. They will allow host or network addresses to be used as indicators to filter and implement a layer of access control. They additionally extend the capabilities of xinetd-controlled daemons. By using this technique, connection attempts can be logged, restricted, and messages returned. This can add an extra layer of security in your environment. TCP Wrappers also allow run-time reconfiguration without restarting or reloading the services they protect.


When connections are attempted to a service using TCP wrappers, the following occurs (the following steps are important because order matters, and rules are processed line-by-line):

1. The process will check the file /etc/hosts.allow. Access will be granted if a match is found in the /etc/hosts.allow file.
2. The process will check the file /etc/hosts.deny. Access will be denied if a match is found in the /etc/hosts.deny file.
3. In the event no matching rules apply, access will be granted.

To uncover what processes/daemons use TCP Wrappers, do the following:

strings -f  | grep hosts_access

An example of output from this command:

[root@alien ~] strings -f /usr/sbin/* | grep hosts_access
/usr/sbin/in.tftpd: hosts_access
/usr/sbin/sshd: hosts_access
/usr/sbin/stunnel: hosts_access
/usr/sbin/stunnel: See hosts_access(5) manual for details
/usr/sbin/tcpd: hosts_access_verbose
/usr/sbin/vsftpd: hosts_access
/usr/sbin/xinetd: hosts_access

[root@alien ~] strings -f /sbin/* | grep hosts_access
/sbin/portmap: hosts_access_verbose

In most cases, it then uses the syslog daemon (syslogd) to write the name of the requesting client and the requested service to /var/log/secure or /var/log/messages. The following are important points to consider when using TCP Wrappers to protect network services:

• Because access rules in hosts.allow are applied first, they take precedence over rules specified in hosts.deny. Therefore, if access to a service is allowed in hosts.allow, a rule denying access to that same service in hosts.deny is ignored.
• The rules in each file are read from the top down and the first matching rule for a given service is the only one applied. The order of the rules is extremely important.
• If no rules for the service are found in either file, or if neither file exists, access to the service is granted.
• TCP-wrapped services do not cache the rules from the hosts access files, so any changes to hosts.allow or hosts.deny take effect immediately, without restarting network services.

Implementing TCP Wrappers

When using TCP Wrappers, bear certain things in mind. First, order matters. Second, the search will stop with the first match. Any changes to /etc/hosts.allow or /etc/hosts.deny take effect immediately without having to restart any services. As with iptables, order is crucial in these rules. Let's take a look at the commands for setting rules. The basic formats of commands in /etc/hosts.allow and /etc/host.deny are:

daemon_list : client_list  : shell_command 

daemon_list - This is a list of one or more daemon process names or wildcards
 
client_list - This is a list of one or more host names, host addresses, patterns or 
              wildcards that will be matched against the client host name or address.

Examples of /etc/hosts.allow and /etc/hosts.deny rules:
/etc/hosts.allow

#
# hosts.allow   This file describes the names of the hosts 
#               allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
# My new rule below
sshd : 192.168.0.14 

/etc/hosts.deny

#
# hosts.deny    This file describes the names of the hosts 
#               *not* allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular,
# you should know that NFS uses portmap!
#
# My new rule below
ALL : ALL

Observe the results of my new rules:
From station14.example.com (192.168.0.14)

Last login: Tue Apr  7 06:45:09 2009 from station14
[root@station15 ~]# 

From alien.example.com (192.168.0.247)

[root@alien ~]# ssh 192.168.0.15
ssh_exchange_identification: Connection closed by remote host
[root@alien ~]#

Commands

ALL:

This wildcard will match all services or hosts.

LOCAL:

This matches any host that does not contain a dot character.

UNKNOWN:

This matches any unknown user, and matches any host whose name or addresses are unknown. Remember that host names may be unavailable if name server problems are encountered.

KNOWN:

This matches any known user, and matches any host whose name and address are known. Remember that host names may be unavailable if name server problems are encountered.

PARANOID:

This will match any host whose name does not match its address.

EXCEPT:

This is intended to be used in the form: list_1 EXCEPT list_2. This operator matches anything that matches list_1 unless it matches list_2. EXCEPT can be used in daemon_lists and in client_lists.

(WARNING: Always leave a blank line containing an 'enter' character in both /etc/hosts.allow and /etc/hosts.deny! Simply go to the end of your last line in insert mode within the vi editor, and hit the carriage return () key. Failure to perform this step may cause unwanted consequences with TCP Wrappers.)
Here are some rule examples included below. Which file you put the rule in determines how the rule works, unless you add an 'allow' or a 'deny' at the end of the rule.

sshd : .example.com
vsftpd : 192.168. 
ALL : 192.168.1.0/255.255.255
sshd : station1.example.com : allow
sshd : station15.example.com : deny
vsftpd : ALL EXCEPT *.hacker.org

Using Twist

The 'twist' directive is used to replace the service with a selected command. It is commonly used to set up honeypots. Another use for it is to send messages to connecting clients. The 'twist' command must be used at the end of a rule line. Here is an example of using 'twist' in /etc/hosts.deny to send a message to a host that has abused FTP services, via the echo command:
Example using twist in /etc/hosts.deny

vsftpd : station6.example.com \
: twist /bin/echo "Service suspended for abuse!"

Using Spawn

The 'spawn' directive causes a child process to be launched. This can be very handy when used to generate special access log files. You can also run custom scripts in the background with this directive that will be unseen by the user. In this example, we will create a timestamp in a custom log so we can monitor FTP connections:
Example in /etc/hosts.allow

vsftpd : .example.com  \
: spawn /bin/echo $(/bin/date) access granted to %h>>/var/log/ftp_access.log 

These are what character expansions you can take advantage of, when used in either /etc/hosts.allow or /etc/hosts.deny.

% EXPANSIONS
       The following expansions are available within shell commands:
       %a    The client host address
       %A    The server's host address
       %c    Client information: user@host, user@address,  a  host  name,  or just an address
       %d    The daemon process name
       %h    The client  host name or address, if the  host  name  is unavailable
       %H    The server host name or address, if the  host  name  is unavailable
       %n    The client host name (or "unknown" or "paranoid")
       %N    The server host name (or "unknown" or "paranoid")
       %p    The daemon process id
       %s    Server  information: daemon@host, daemon@address, or just a daemon name
       %u    The client user name (or "unknown")
       %%    Expands to a single "%" character.
       (Characters in % expansions that may confuse the shell are replaced by underscores)