TCP Wrappers / Hosts Access
This is a short and basic introduction to the TCP wrappers. Useful as a start to create your own access control files tailored to your own specific needs.
Introduction
Probably most people know Wietse Venema’s TCP Wrapper software as a result of their usage ofinetd, the internet “super-server”, in combination with tcpd. An arbitrary line of/etc/inetd.conf, the configuration file of inetd:
ident stream tcp nowait nobody /usr/libexec/tcpd /usr/libexec/identd -elo
The /usr/libexec/tcpd here is the program that takes a look at the incoming connection that inetd has accepted on behalf of the identd program. If it thinks it can allow the connection, it passes it to identd. If not, it unleashes hell (well,.. it just drops the connection) on that TCP connection and identd will never see a packet coming from the remote client.
But not only tcpd uses the wrapping functionality. By default OpenBSD’s Sendmail and SSH daemon are linked to LIBWRAP and can use its functionality too.
Access control flow/algorithm
To tell tcpd and other programs linked to LIBWRAP which connection to which daemon/service to allow, one should modify or leave alone the following two files:
/etc/hosts.allow
/etc/hosts.deny
In hosts.allow you put the remote host/local daemon combinations that you approve of having a happy TCP chatter. If a remote host, the client, likes to chat with a local daemon and that client/daemon pair has a positive match in the hosts.alllow file, the client is granted access to the daemon’s services. The hosts.deny file is ignored.
If there is no positive match, the hosts.deny is checked for a match. If the tcp wrapper can find a positive match in hosts.deny, the client is not granted access to the daemon and the TCP connection gets dropped. But if the client/daemon pair is not matched, the connection to the daemon is granted.
If one or both of the hosts access files is missing, the above explained flow treats them as if they exist, but are empty.
The control flow is a Yes-Unless kind of strategy. You can come in, unless you’re mentioned inhosts.deny. To reverse that strategy that you can configure hosts.deny to deny all access. Then all clients trying to communicatie with a daemon should be listed in hosts.allow. Then we have a No-Unless situation created.
Configuration
Here I’ll explain how to create that el neato No-Unless situation with some real life X-rated examples.
First we edit hosts.deny to disallow life, the universe and everything:
ALL: ALL
Then we edit hosts.allow to let the complete internet whisper in the ears of our SSH daemon, Sendmail and our ident daemon:
identd: ALL
sendmail: ALL
sshd: ALL
Don’t use above example if you don’t like allowing anyone to access the Sendmail daemon, ssh daemon and/or ident daemon.
The combination of the above example of the hosts.deny and hosts.allow allows the complete internet access to your sendmail, ssh daemon and ident daemon, but completely forbids anyone to access any other daemon/service you’re running.
If you’d like to have hosts on your intranet access to your POP3 daemon, but not anyone else you can do something like this in hosts.allow:
popa3d: 127.0.0.1 192.168.0.
With this rule access is granted to our POP3 daemon popa3d from localhost and the “192.168.0.” IP range. You can read “192.168.0.” like 192.168.0.*, 192.168.0.1 – 192.168.0.254, or 192.168.0.0/24. It comes down to 254 IP addresses that start with “192.168.0″.
More information
More information can be obtained by reading the following man pages:
- hosts_access(5)
- hosts_options(5)
- tcpd(8)
They provide far more advanced information then you can find here and recommended reading if you’d like to tailor the hosts access files to your own specific (and complex?) needs.