Pick a Free OS

User login

Navigation

Network monitoring, access control & booby traps using TCP Wrappers: Part 1

Most of the applications being used on the Internet today are based on the Client - Server model. This client server model is our prime focus of our discussion from now on. The author of TCP Wrappers has written the application in such a way that it intervenes in the functioning of the required TCP application, which is based on the client-server model, and for which access control has to be administered. Depending on the access control lists specified for the particular protocol, TCP Wrappers lets the client initiate a connection to the server or just drops the connection. Either way, it logs all attempts to access the particular service. TCP Wrappers is written in such a fashion, for the simple reason that the author - a brilliant guy that he is - never wanted to re-engineer any of the hundreds of client-server applications just to make sure that they were compatible with TCP Wrappers. In fact, he did things exactly the other way around - made TCP Wrappers compatible with all other client-server applications.

This tool has been successfully used for shielding off systems and for detection of cracker activity. It has no impact on legal computer users, and does not require any change to existing systems software or configuration files. The tool has been installed world-wide on numerous UNIX systems without any source code change. Such is the beauty of TCP Wrappers.

Almost every application of the TCP/IP protocols is based on a client-server model. For example, when someone uses the telnet command to connect to a host, a telnet server process is started on the target host. The server process connects the user to a login process. A few examples are shown in table 1.

client server application

________________________________

telnet telnetd remote login

ftp ftpd file transfer

finger fingerd show users

systat systatd show users

Table 1. Examples of TCP/IP client-server pairs and

their applications.

The usual approach is to run one daemon process that waits for all kinds of incoming network connections. Whenever a connection is established this daemon (usually called inetd on our Linux boxes) runs the appropriate server program and goes back to sleep, waiting for other connections. See the example as illustrated below.

client server application

________________________________

telnet telnetd remote login

(foo1.bar) (foo2.bar)