TCP Wrappers Configuration Files (2022)

To determine if a client machine is allowed to connect to a service,TCP wrappers reference the following two files, which are commonlyreferred to as hosts access files:

When a client request is received by a TCP wrapped service, it takes thefollowing basic steps:

The following are important points to consider when using TCP wrappersto protect network services:

17.2.1. Formatting Access Rules

The format for both /etc/hosts.allow and /etc/hosts.deny are identical. Any blank lines or lines that start with a hash mark (#) are ignored, and each rule must be on its own line.

Each rule uses the following basic format to control access to network services:

<daemon list>: <client list> [: <option>: <option>: ...]
  • <daemon list> — A comma separated list of process names (not service names) or the ALL wildcard (refer to Section 17.2.1.1 Wildcards). The daemon list also accepts operators (refer to Section 17.2.1.4 Operators) to allow greater flexibility.

  • <client list> — A comma separated list of hostnames, host IP addresses, special patterns (refer to Section 17.2.1.2 Patterns), or special wildcards (refer to Section 17.2.1.1 Wildcards) which identify the hosts effected by the rule. The client list also accepts operators listed in Section 17.2.1.4 Operators to allow greater flexibility.

  • <option> — An optional action or colon separated list of actions performed when the rule is triggered. Option fields support expansions (refer to Section 17.2.2.4 Expansions), launch shell commands, allow or deny access, and alter logging behavior (refer to Section 17.2.2 Option Fields).

The following is a basic sample hosts access rule:

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 next sample hosts access rule is more complex and uses two option fields:

sshd : .example.com \: spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \: deny

Note that each option field is preceded by the backslash (\). Use of the backslash prevents failure of the rule due to length.

This sample rule states that if a connection to the SSHdaemon (sshd) is attempted from a host in theexample.com domain, execute theecho command (which logs the attempt to a specialfile), and deny the connection. Because the optionaldeny directive is used, this line denies accesseven if it appears in the hosts.allow file. For amore detailed look at available options, refer to Section 17.2.2 Option Fields.

17.2.1.1. Wildcards

Wildcards allow TCP wrappers to more easily match groups of daemons or hosts. They are used most frequently in the client list field of access rules.

The following wildcards may be used:

  • ALL — Matches everything. It can be used for both the daemon list and the client list.

  • LOCAL — Matches any host that does not contain a period (.), such as localhost.

  • KNOWN — Matches any host where the hostname and host address are known or where the user is known.

  • UNKNOWN — Matches any host where the hostname or host address are unknown or where the user is unknown.

  • PARANOID — Matches any host where the hostname does not match the host address.

17.2.1.2. Patterns

Patterns can be used in the client list field of access rules to more precisely specify groups of client hosts.

The following is a list of the most common accepted patterns for a client list entry:

  • Hostname beginning with a period(.) — Placing a period atthe beginning of a hostname matches all hosts sharing thelisted components of the name. The following example applies toany host within the example.com domain:

    ALL : .example.com
  • IP address ending with a period(.) — Placing a periodat the end of an IP address matches all hosts sharingthe initial numeric groups of an IP address. The following exampleapplies to any host within the192.168.x.x network:

    ALL : 192.168.
  • IP address/netmask pair — Netmaskexpressions can also be used as a pattern to control access to aparticular group of IP addresses. The following example appliesto any host with an address range of 192.168.0.0through 192.168.1.255:

    ALL : 192.168.0.0/255.255.254.0 
    TCP Wrappers Configuration Files (2)Important

    When working in the IPv4 address space, the address/prefix length (prefixlen) pair declarations are not supported. Only IPv6 rules can use this format.

  • [IPv6 address]/prefixlen pair —[net]/prefixlen pairs can also be used as a pattern to controlaccess to a particular group of IPv6 addresses. The followingexample would apply to any host with an address range of3ffe:505:2:1:: through3ffe:505:2:1:ffff:ffff:ffff:ffff:

    ALL : [3ffe:505:2:1::]/64 
  • The asterisk (*) — Asterisks can be usedto match entire groups of hostnames or IP addresses, as long asthey are not mixed in a client list containing other types ofpatterns. The following example would apply to any host withinthe example.com domain:

    ALL : *.example.com
  • The slash (/)— If a client list begins with a slash, it istreated as a file name. This is useful if rules specifying largenumbers of hosts are necessary. The following example refers TCPwrappers to the /etc/telnet.hosts file forall Telnet connections:

    in.telnetd : /etc/telnet.hosts

Other, lesser used, patterns are also accepted by TCP wrappers. Refer to the hosts_access man 5 page for more information.

TCP Wrappers Configuration Files (3)Warning

Be very careful when using hostnames and domain names. Attackers can use a variety of tricks to circumvent accurate name resolution. In addition, disruption in DNS service prevents even authorized users from using network services.

It is, therefore, best to use IP addresses whenever possible.

17.2.1.3. Portmap and TCP Wrappers

When creating access control rules for portmap, do not use hostnames as portmap's implementation of TCP wrappers does not support host look ups. For this reason, only use IP addresses or the keyword ALL when specifying hosts in hosts.allow or hosts.deny.

In addition, changes to portmap access control rules may not take affect immediately without restarting the portmap service.

Widely used services, such as NIS and NFS, depend on portmap to operate, so be aware of these limitations.

17.2.1.4. Operators

At present, access control rules accept one operator, EXCEPT. It can be used in both the daemon list and the client list of a rule.

The EXCEPT operator allows specific exceptions to broader matches within the same rule.

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 the another example from a hosts.allow file, clients from the 192.168.0.x network can use all services except for FTP:

ALL EXCEPT vsftpd: 192.168.0.
TCP Wrappers Configuration Files (4)Note

Organizationally, it is often easier to avoid using EXCEPT operators. This allows other administrators to quickly scan the appropriate files to see what hosts are allowed or denied access to services, without having to sort through EXCEPT operators.

17.2.2. Option Fields

In addition to basic rules allowing and denying access, the Red Hat Enterprise Linux implementation of TCP wrappers supports extensions to the access control language through option fields. By using option fields within hosts access rules, administrators can accomplish a variety of tasks such as altering log behavior, consolidating access control, and launching shell commands.

17.2.2.1. Logging

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 SSH 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:

sshd : .example.com : severity emerg

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

sshd : .example.com : severity local0.alert
TCP Wrappers Configuration Files (5)Note

In practice, this example does not work until the syslog daemon (syslogd) is configured to log to the local0 facility. Refer to the syslog.conf man page for information about configuring custom log facilities.

17.2.2.2. Access Control

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 instance, the following two rules allow SSH connections from client-1.example.com, but deny connections from client-2.example.com:

sshd : client-1.example.com : allowsshd : client-2.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. Some consider this an easier way of organizing access rules.

17.2.2.3. Shell Commands

Option fields allow access rules to launch shell commands through the following two directives:

  • spawn — Launches a shell command asa child process. This option directive can perform tasks likeusing /usr/sbin/safe_finger to get moreinformation about the requesting client or create special logfiles using the echo command.

    In the following example, clients attempting to access Telnetservices from the example.com domain arequietly logged to a special file:

    in.telnetd : .example.com \ : spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \ : allow
  • twist — Replaces the requested service with the specified command. This directive is often used to set up traps for intruders (also called "honey pots"). It can also be used to send messages to connecting clients. The twist directive must occur at the end of the rule line.

    In the following example, clients attempting to access FTPservices from the example.com domain aresent a message via the echo command:

    vsftpd : .example.com \: twist /bin/echo "421 Bad hacker, go away!"

For more information about shell command options, refer to the hosts_options man page.

17.2.2.4. Expansions

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

Below is a list of supported expansions:

  • %a — Supplies the client's IP address.

  • %A — Supplies the server's IP address.

  • %c — Supplies a variety of client information, such as the username and hostname, or the usernameand IP address.

  • %d — Supplies the daemon process name.

  • %h — Supplies the client's hostname (or IP address,if the hostname is unavailable).

  • %H — Supplies the server's hostname (or IP address,if the hostname is unavailable).

  • %n — Supplies the client's hostname. If unavailable,unknown is printed. If the client'shostname and host address do not match,paranoid is printed.

  • %N — Supplies the server'shostname. If unavailable, unknown isprinted. If the server's hostname and host address do not match,paranoid is printed.

  • %p — Supplies the daemon process ID.

  • %s —Supplies various types ofserver information, such as the daemon process and the host orIP address of the server.

  • %u — Supplies the client'susername. If unavailable, unknown is printed.

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 %h>>/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!"

For a full explanation of available expansions, as well as additional access control options, refer to section 5 of the man pages for hosts_access (man 5 hosts_access) and the man page for hosts_options.

For additional information about TCP wrappers, refer to Section 17.5 Additional Resources. For more information about how to secure TCP wrappers, refer to the chapter titled Server Security in the Red Hat Enterprise Linux Security Guide.

Top Articles

Latest Posts

Article information

Author: Errol Quitzon

Last Updated: 10/27/2022

Views: 6519

Rating: 4.9 / 5 (59 voted)

Reviews: 82% of readers found this page helpful

Author information

Name: Errol Quitzon

Birthday: 1993-04-02

Address: 70604 Haley Lane, Port Weldonside, TN 99233-0942

Phone: +9665282866296

Job: Product Retail Agent

Hobby: Computer programming, Horseback riding, Hooping, Dance, Ice skating, Backpacking, Rafting

Introduction: My name is Errol Quitzon, I am a fair, cute, fancy, clean, attractive, sparkling, kind person who loves writing and wants to share my knowledge and understanding with you.