tcp wrapper – monitoring telnet requests, permit deny connections, etc.
Note: tcp wrapper is now included within FreeBSD by default. This started with
FreeBSD 3.2-RELEASE.
If you have installed tcp wrappers, you should deinstall when you
upgrade to any version of FreeBSD after 3.2-RELEASE inclusive. See Incoming ssh is being refused for a good reason why you should
do this.
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 tcp wrappers (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 is tcp wrapper?
The port description contains the following exerpt:
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.
tcpd is the daemon which comes with the tcp wrapper port.. 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.
Installation
From FreeBSD 3.2-RELEASE, tcpd is built in. In fact, there is no tcpd,
but the functionality is still there. You do not have to install it so you can skip
down to the Output section.
For FreeBSD prior to
3.2-RELEASE, you will need to install and configure the port.. The following is how
I did it.
For full port installation instructions, please see Getting a FreeBSD Port
in the FreeBSD handbook.
Here’s what I did (remember that I had already installed all
the ports):
# cd /usr/ports/security/tcp_wrapper # make # make install
Configuration
From FreeBSD 3.2-RELEASE, tcpd is built in. You do not have configure /etc/inetd.conf
so you can skip down to the Output section.
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 outline
below.
My first tests involved just telnet and finger. I modifed /etc/inetd.conf
as follows:
telnet stream tcp nowait root /usr/libexec/telnetd telnetd finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s
became
telnet stream tcp nowait root /usr/local/libexec/tcpd telnetd finger stream tcp nowait/3/10 nobody /usr/local/libexec/tcpd fingerd -s -l
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 daemons.
Output
The main purpose of using tcp wrappers 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 man
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[1758]: connect from wocker.www.example.org Jan 10 15:49:58 ngatoto login: login from wocker.www.example.org on ttyp2 as mike
The first line indicates that someone telnet’d 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.
By default, the telnetd message will go into.
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 /var/log/auth.log.
$Id: tcpwrapper.php,v 1.28 2007/08/27 16:34:48 dan Exp $ # # Spaces are NOT valid field separators in this file. # Consult the syslog.conf(5) manpage. *.err;kern.debug;auth.notice;mail.crit /dev/console *.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages auth.* /var/log/auth.log mail.info /var/log/maillog lpr.info /var/log/lpd-errs cron.* /var/cron/log *.err root *.notice;news.err root *.alert root *.emerg * # 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 !startslip *.* /var/log/slip.log !ppp *.* /var/log/ppp.log
The only line I added is in bold and starts with "auth".
This direct the log messages, as displayed in the example above, to the file /etc/auth.log.
Remember to restart syslogd after making any changes 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 command:
touch /var/log/auth.log
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 man
newsyslog for more details.
Restricting connections
For versions prior to FreeBSD 3.2-RELASE, there are two files should know about.
Both are located in /usr/local/etc/. These files are hosts.allow
and hosts.deny. For versions 3.2-RELEASE and after, you use a single
file and it’s location is different. There is only only the /etc/hosts.allow
file and you put both the deny and allow functionality in that file.
Here’s what I have
in my hosts.allow.
1 ALL: theirdomain.com: ALLOW 2 telnetd: 192.168.4.0/255.255.255.0: ALLOW 3 ftpd:ALL@ALL 4 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.4.* network to telnet. Here’s a extract
from the man pages which explains the numbering system:
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 `131.155.72.0/255.255.254.0' matches every address in the range `131.155.72.0' through `131.155.73.255'.
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.
Utilities
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
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; inappro- priate 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 the problem.
tcpdmatch
tcpdmatch predicts how the tcp wrapper would handle a spe- cific 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 configuration file. 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 discrep- ancies between what you want and what the program under- stands.
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 important issues.
your article cannot help any more on tcpd install: the 4.5 says that it is part of the default install (when following your instructions to make/install), and that it is in the regular installation (yaddah, yadah..) but.. it is not there. It is nowhere, even in the /usr/src/libexec/tcpd there is a Makefile,v which do nothing.
any hint??
The article is dated January 1999. Since that date, tcpd has been added to the base system. The article also states:
Note: tcp wrapper is now included within FreeBSD by default. This started with FreeBSD 3.2-RELEASE.
I have some questions regarding the integrated tcpd in freeBSD
post-version-3.2:
1. Why??????
2. Where the bloody hell is it? In the past, one had the option
of wrapping things either of two ways in /etc/inetd.conf. Now
that seems no longer the case.
3. Why was the location for tcpd’s config files moved? Seems
like more change for the sake of change to me.
4. How can one now update to a more recent version of wrappers
without updating the whole bloody operating system?
What’s the matter? Don’t the freeBSD developers trust us to be
able to install and configure wrappers ourselves if we want them?
Perhaps you should post your message in the <A HREF="/phorum/">FreeBSD Support fourum</A>.