| ## Taking Advantage of TCP Wrappers
## Dan Langille <>
The tcp_wrapper port installs a great little daemon by the name of
tcpd. This port can be used to enhance the security of your site. It
is easy to use and provides a very useful log. It has become a basic
part of what people use to secure incoming connections.
This article how I installed tcpd under FreeBSD. At it's lowest
level, this port can be useful as a tool for monitoring incoming
requests but it can also filter such requests.
What are TCP wrappers?
The port description contains the following excerpt:
With this package you can monitor and filter incoming
requests for the SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH,
EXEC, TFTP, TALK, and other network services.
But I'm sure it can be used for more than just that.
tcpd is the daemon in question. It works on one-off programs like
telnet which start running when inetd sees an incoming request on a
port. It won't work for programs that run all the time. In short,
tcpd is told by inetd what program to start. tcpd then checks starts
other applications for you but first checks the security to see if the
application should start.
For full port installation instructions, please see
in the FreeBSD handbook.
Here's what I did:
# cd /usr/ports/security/tcp_wrapper
# make install
I recommend that you read the README file which should be located at
/usr/ports/security/tcp_wrapper/work/tcp_wrappers_7.6. It will
describe the port in detail and explain more fully the steps I will
I modified /etc/inetd.conf as follows:
telnet stream tcp nowait root /usr/libexec/telnetd telnetd
telnet stream tcp nowait root /usr/local/libexec/tcpd telnetd
Note that under recent installations (e.g. 3.1-STABLE), the file
location was /usr/local/libexec/tcpd. Watch your make install for
details on where the file was actually installed and amend
/etc/inetd.conf as appropriate.
In order to test that the above change was working, I first did a test
of the finger command. Try finger <user> where <user> is a user
on your system. If you get "no such user", then perhaps the user has a
.nofinger file in their home directory.
After testing that finger worked, I did a HUP to inetd. Then I did
another finger. It still worked and thus proved the changes were
successful. I did similar entries in /etc/inetd.conf for other
The main purpose of using tcp_wrapper is to provide log information.
Where does that information go? Well, if you read the README file,
you'll see that it goes to syslogd. I strongly urge you to read
the manpage for syslog.conf before attempting to modify it.
Here's what you can expect to find if you have tcp wrappers running
correctly for telnet:
Jan 10 15:49:41 ngatoto telnetd: connect from wocker.dvl-software.com
Jan 10 15:49:58 ngatoto login: login from wocker.dvl-software.com on ttyp2 as mike
The first line indicates that someone telnetted to the machine ngatoto.
The second line indicates that they managed to login as mike. There
are some issues associated with getting the above messages into your
log file. I found it very difficult to get the above logging messages
where I wanted them. The key is /etc/syslog.conf and the entries
therein. The following file will put the messages into
# Spaces are NOT valid field separators in this file.
# Consult the syslog.conf(5) manpage.
# uncomment these if you're running inn
# news.crit /var/log/news/news.crit
# news.err /var/log/news/news.err
# news.notice /var/log/news/news.notice
The only line I added is in bold and starts with "auth". This directs
the log messages, as displayed in the example above, to the file
/etc/auth.log. Remember to restart syslogd after making any change
to /etc/syslog.conf. Also, you must manually create the log file
because syslogd expects the file to exist. You can do this with this
And because you have just created a new log file, you may wish to add
a new entry to /etc/newsyslog.conf and have it rotated. See the man
page for newsyslog for more details.
There are two files should know about. Both are located in
/usr/local/etc/hosts. These files are hosts.allow and hosts.deny.
Here's what I have in my hosts.allow.
ALL: theirdomain.com: ALLOW
telnet: 192.168.4.0/255.255.255.0: ALLOW
ALL: ALL: DENY
NOTE: Do not include the line numbers as indicated above. They are
for reference only.
Line 1 allows all connections from from theirdomain.com.
Line 2 allows all machines in the 192.168.0.* network to telnet.
Here's a extract from the man pages which explains the numbering
An expression of the form `n.n.n.n/m.m.m.m' is
interpreted as a `net/mask' pair. A host address is
matched if `net' is equal to the bitwise AND of the
address and the `mask'. For example, the net/mask
pattern `188.8.131.52/255.255.254.0' matches every
address in the range `184.108.40.206' through
Line 3 allows everyone to connect to the ftp server.
Line 4 denies access to everyone by default (if not explicity allowed
above). Basic security practices dictate that you should deny
everything and then explicity permit the things you want. The above
example follows that advice. For more detail on this file, please see
man 5 hosts_access.
tcpd comes with a couple of nice utilities, both of which I was
recently informed off. They sound like very good companion tools.
The following two sections contain description from the respective
man pages for these tools.
These tools are found at /usr/local/sbin.
tcpdchk examines your tcp wrapper configuration and reports
all potential and real problems it can find. The program
examines the tcpd access control files (by default, these are
/usr/local/etc/hosts.allow and /usr/local/etc/hosts.deny), and
compares the entries in these files against entries in the
inetd or tlid network configuration files.
tcpdchk reports problems such as non-existent pathnames;
services that appear in tcpd access control rules, but are not
controlled by tcpd; services that should not be wrapped;
non-existent host names or non-internet address forms;
occurrences of host aliases instead of official host names;
hosts with a name/address conflict; inappropriate use of
wildcard patterns; inappropriate use of NIS netgroups or
references to non-existent NIS netgroups; references to
non-existent options; invalid arguments to options; and so on.
Where possible, tcpdchk provides a helpful suggestion to fix
tcpdmatch predicts how the tcp wrapper would handle a specific
request for service. Examples are given below.
The program examines the tcpd access control tables (default
/usr/local/etc/hosts.allow and /usr/local/etc/hosts.deny) and
prints its conclusion. For maximal accuracy, it extracts
additional information from your inetd or tlid network
When tcpdmatch finds a match in the access control tables, it
identifies the matched rule. In addition, it displays the
optional shell commands or options in a pretty-printed format;
this makes it easier for you to spot any discrepancies between
what you want and what the program understands.
Well, that was that.
This should get you started. Install the port. Monitor the logs.
It should make your security issues much easier to deal with and
allow you to concentrate on other issues.
Return to Issue #5