Intro to TCP Wrappers

TCP Wrappers is an easy-to-configure security mechanism that protects some (but not all!) services using the hosts access files. TCP Wrappers works by referencing /etc/hosts.allow and /etc/hosts.deny. The sequence of checks is as follows:

  1. hosts.allow is processed first, then hosts.deny.
  2. Each file is read from top down and the first matching rule is applied. All subsequent rules are ignored.
  3. If no matching rule is found, access is granted. NOTE that granting access is the default.
  4. Changes take effect immediatly upon creating an entry in the files listed above. No services need restarting.

Installing TCP Wrappers

TCP Wrappers is typically installed by default when the operating system is installed. See the section called "Additional Notes & Considerations for TCP Wrappers" below for more details.

TCP Wrappers Configuration Files

As stated above, TCP Wrappers works by referencing /etc/hosts.allow and /etc/hosts.deny. These files are well commented. Also, there are man pages available. See the section called "Additional Notes & Considerations for TCP Wrappers" below for more details.

TCP Wrappers Protects Select Services

Not all services are protected by TCP Wrappers. Services running under the xinetd super-daemon are excellent candidates for protection by TCP Wrappers. In order for a service to work with TCP Wrappers, it must be compiled against the libwrap.a library. To check whether a service is capable of being configured for TCP Wrappers, the following command is used:

    # ldd `which sendmail` | grep libwrap
    libwrap.so.0 => /lib64/libwrap.so.0 ...

Note that the return shows that libwrap.so.0 was used during the compile of sendmail. Therefore, the sendmail program can be successfully configured to work with TCP Wrappers. Typically, sshd, sendmail, and vsftpd are compiled to work with TCP Wrappers. Notably, httpd is not.

To see which services are running under the xinetd super-daemon, run chkconfig --list and look toward the bottom of the output for the listing.[13]

Additional Notes & Considerations for TCP Wrappers

On my Fedora 19 laptop, I ran the following series of commands and received the indicated output. This example series of events can be used to check and verify information about many files, packages, and services regardless of the Linux distribution or version.

    root@intrepid ~/
    --> rpm -qf /etc/hosts.allow
    setup-2.8.71-1.fc19.noarch

The above program listing identifies which package "owns" or installed the /etc/hosts.allow file.

    root@intrepid ~/
    --> rpm -qi setup
    Name        : setup
    Version     : 2.8.71
    Release     : 1.fc19
    Architecture: noarch
    Install Date: Sat 23 Nov 2013 11:16:11 CST
    Group       : System Environment/Base
    Size        : 696224
    License     : Public Domain
    Signature   : RSA/SHA256, Fri 07 Jun 2013 19:32:51 CDT, Key ID 07477e65fb4b18e6
    Source RPM  : setup-2.8.71-1.fc19.src.rpm
    Build Date  : Fri 07 Jun 2013 09:41:41 CDT
    Build Host  : buildvm-08.phx2.fedoraproject.org
    Relocations : (not relocatable)
    Packager    : Fedora Project
    Vendor      : Fedora Project
    URL         : https://fedorahosted.org/setup/
    Summary     : A set of system configuration and setup files
    Description :
    The setup package contains a set of important system configuration and
    setup files, such as passwd, group, and profile.

The above program listing gives information about the controlling package based upon what the authors and developers indicated in their SPEC file for the pacakge.

    root@intrepid ~/
    --> man -k hosts.{allow,deny}
    hosts.allow (5)      - format of host access control files
    hosts.deny (5)       - format of host access control files

The output above shows that there are man pages available for hosts.allow and hosts.deny. Both of these perform the same essential function from different angles. They have been in development for several years and are mature enough to have been included in many major distribution repositories.

Utilities that Make Use of the Above

There are two excellent utilities that are "production worthy" which make use of the services in this chapter. Fail2Ban works with IPTables, and DenyHosts works with the '/etc/hosts*' files.

Reference Material for this Chapter

For this chapter's supporting material, please reference Chapters 4, 9, 10, & 11 in the RHCSA/RHCE Linux Certification Study Guide text book.



[13] There should be a dump directory /etc/xinetd.d. This directory, if present, contains the configuration files for services running under xinetd. More information is available by exploring that directory.