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.
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.
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 >> \ /var/log/connections.log) \ : deny
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.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
    documentation may be
    sent to <freebsd-questions@FreeBSD.org>.
    Send questions about this document to <freebsd-doc@FreeBSD.org>.