14.4.Â TCP Wrapper

Written
by TomRhodes.

TCP Wrapper 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 Wrapper 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.

14.4.1.Â Initial Configuration

To enable TCP Wrapper in FreeBSD,
add the following lines to
/etc/rc.conf:

inetd_enable="YES"
inetd_flags="-Ww"

Then, properly configure
/etc/hosts.allow.

Note:

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

14.4.2.Â Advanced Configuration

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.

Warning:

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:

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: