TCP Wrappers: Securing Linux

This how-to describes configuring TCP Wrappers for providing Access Control for the supported services in a Linux box.TCP wrappers are supported by most of the Linux distributions such as Redhat Enterprise Linux, Ubuntu, SUSE, Debian, BSD and UNIX. TCP Wrappers work in the manner of a host-based Access Control List. 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.

The work flow of TCP wrappers

The TCP Wrappers package (tcp_wrappers) is installed by default and provides host-based access control to network services. The most important component within the package is the /usr/lib/libwrap.a library. In general terms, a TCP-wrapped service is one that has been compiled against the libwrap.a library.

 To determine if a client is allowed to connect to a service, TCP Wrappers reference the following two files, which are commonly referred to as hosts access files:

            a. /etc/hosts.allow

            b. /etc/hosts.deny

 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.

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.

Configuring TCP Wrappers in Linux

Syntax:

           daemon list: client list [: option: option: ...]

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.

option- An optional action or colon-separated list of actions performed when the rule is triggered. Option fields support expansions, launch shell commands, allow or deny access, and alter logging behaviour.

The wildcards that can be user while configuring TCP Wrappers.

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.

 Example TCP Wrapper configurations:

            vsftpd : .example.com

 This rule instructs TCP Wrappers to watch for connections to the FTP daemon (vsftpd) from any host in the example.com domain. If this rule appears in hosts.allow, the connection is accepted. If this rule appears in hosts.deny, the connection is rejected.

The following example applies to any host within the example.com domain:

           ALL : .example.com

The following example applies to any host within the 192.168.x.x network:

          ALL : 192.168.

The following example applies to any host with an address range of 192.168.0.0 through 192.168.1.255:

          ALL : 192.168.0.0/255.255.254.0

The following example refers TCP Wrappers to the /etc/telnet.hosts file for all Telnet connections:

         in.telnetd : /etc/telnet.hosts

In the following example from a hosts.allow file, all example.com hosts are allowed to connect to all services except cracker.example.com:

          ALL: .example.com EXCEPT cracker.example.com

In addition to basic rules that allow and deny access, the Red Hat Enterprise Linux implementation of TCP Wrappers supports extensions to the access control language through option fields.

Logging with TCP Wrappers:

 Option fields let administrators easily change the log facility and priority level for a rule by using the severity directive.

 In the following example, connections to the TELNET daemon from any host in the example.com domain are logged to the default authpriv syslog facility (because no facility value is specified) with a priority of emerg:

             in.telnetd : .example.com : severity emerg

It is also possible to specify a facility using the severity option. The following example logs any FTP connection attempts by hosts from the example.com domain to the local0 facility with a priority of alert:

           vsftpd : .example.com : severity local0.alert

Access Control with TCP Wrappers:

Option fields also allow administrators to explicitly allow or deny hosts in a single rule by adding the allow or deny directive as the final option.

 For example, the following two rules allow SSH connections from host1.example.com, but deny connections from host2.example.com:

            sshd : host1.example.com : allow

     sshd : host2.example.com : deny

 By allowing access control on a per-rule basis, the option field allows administrators to consolidate all access rules into a single file: either hosts.allow or hosts.deny.

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 >>/var/log/ftp_access.log

Expansions, when used in conjunction with the spawn and twist directives, provide information about the client, server, and processes involved.

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")

 The following sample rule uses an expansion in conjunction with the spawn command to identify the client host in a customized log file.

When connections to the SSH daemon (sshd) are attempted from a host in the example.com domain, execute the echo command to log the attempt, including the client hostname (by using the %h expansion), to a special file:

            sshd : .example.com \

           : spawn /bin/echo `/bin/date` access denied to >>var/log/sshd.log : deny

 Similarly, expansions can be used to personalize messages back to the client. In the following example, clients attempting to access FTP services from the example.com domain are informed that they have been banned from the server:

                vsftpd : .example.com \

             : twist /bin/echo "421 %h has been banned from this server!"