Basics of TCP Wrappers

The most common use of TCP Wrappers is in conjunction with inetd. Instead of calling the server program directly, inetd calls TCP Wrappers (via its tcpd executable) and passes it the name of the ultimate server program, along with any parameters it needs. TCP Wrappers can then study the incoming connection and decide whether or not to accept it. If the connection is refused, TCP Wrappers doesn't even call the server; it just drops the connection. If TCP Wrappers accepts the connection, it launches the server and hands it the connection.

In order to configure TCP Wrappers, you provide criteria for accepting or rejecting connections in two files: /etc/hosts.allow and /etc/hosts.deny. The first of these files defines computers that should be granted access to the system; the second specifies systems that should not be allowed to connect. If a system is listed in both files, hosts.allow takes precedence. If neither file lists a system, TCP Wrappers allows it to connect.

Tip To run a system with the tightest possible TCP Wrappers security, include a line reading ALL : ALL in /etc/hosts.deny. This line blocks all incoming accesses handled by TCP Wrappers. You can then open individual servers for specific client systems in /etc/hosts.allow.

To use TCP Wrappers, you refer to a server by its filename, which may not be the same as its service name in /etc/services. For instance, an FTP server might be referred to as in.ftpd, vsftpd, proftpd, or various other names. When you use TCP Wrappers in conjunction with inetd, the server's filename appears immediately after the call to tcpd on the /etc/inetd.conf line for the server. Ordinarily, the server must reside somewhere on tcpd's path. If you need to include the complete path to the server in your /etc/inetd.conf file, TCP Wrappers' restrictions may not work correctly. If necessary, you can create a symbolic link from a directory on your path to the actual server executable.

0 0

Post a comment