TCP Wrappers is a host-based access control system which extends the abilities of Section 29.2, “The inetd Super-Server”. It can be configured to provide logging support, return messages, and connection restrictions for the server daemons under the control of inetd. Refer to tcpd(8) for more information about TCP Wrapper and its features.
TCP Wrappers should not be considered a replacement for a properly configured firewall. Instead, TCP Wrapper should be used in conjunction with a firewall and other security enhancements in order to provide another layer of protection in the implementation of a security policy.
To enable TCP Wrapper in FreeBSD, add the following lines to /etc/rc.conf:
Then, properly configure /etc/hosts.allow.
Unlike other implementations of TCP Wrapper, the use of hosts.deny is deprecated in FreeBSD. All configuration options should be placed in /etc/hosts.allow.
In the simplest configuration, daemon connection policies are set to either permit or block, depending on the options in /etc/hosts.allow. The default configuration in FreeBSD is to allow all connections to the daemons started with inetd.
Basic configuration usually takes the form of daemon : address : action, where daemon is the daemon which inetd started, address is a valid hostname, IP address, or an IPv6 address enclosed in brackets ([ ]), and action is either allow or deny. TCP Wrapper uses a first rule match semantic, meaning that the configuration file is scanned from the beginning 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
Whenever this file is edited, restart inetd:
# service inetd restart
TCP Wrapper 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.
Suppose that a situation occurs where a connection should be denied yet a reason should be sent to the host 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 name from hostname.” will be returned for any daemon not configured in hosts.allow. 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.
It may be possible to launch a denial of service attack on the server if an attacker floods 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 host who established the connection. For example, consider the following configuration:
# We do not allow connections from example.com:
ALL : .example.com
: spawn (/bin/echo %a from %h attempted to access %d >>
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.
To match every instance of a daemon, domain, or IP address, use ALL. Another wildcard is PARANOID which may be used to match any host which provides an IP address that may be forged because the IP address differs from its resolved hostname. In this example, all connection requests to Sendmail which have an IP address that varies from its hostname will be denied:
# Block possibly spoofed requests to sendmail:
sendmail : PARANOID : deny
Using the PARANOID wildcard will result in denied connections if the client or server has a broken DNS setup.
To learn more about wildcards and their associated functionality, refer to hosts_access(5).
When adding new configuration lines, make sure that any unneeded entries for that daemon are commented out in hosts.allow.