|
|
|
|
|
|
Network monitoring, access control & booby traps using TCP Wrappers: Part 1
By Trevor Warren <trevor@freeos.com>
Will opens the door to success. What according to you would be the best way to fortify your machine from the anarchy of the Internet? Let's look at a few options. You could put in a well configured firewall. Though this is quite a complex procedure, it's worth going through the pain. And there will be pain. Putting down your organizational policies and framing rulesets that keep the bad guys out and lets the good guys in, requires a lot of thinking on your part. Experience has taught us to verify our rulesets again and again, because even one slip during the framing of the rulesets can bring the house down. At the end of the day, you'll be the only punching bag around. OR You could be too lazy to have any security measures in place. You justify this by saying that among the millions of machines out there, you're not going to be hit. OR You could be totally paranoid about security concerns on the Internet. Securing yourself from the Internet is a simple affair of disconnecting your machine from the network. But then, you wouldn't be reading this article. OR You could put security measures in place that GRANT or DENY access to various services on your machines depending on the privileges that you have setup using TCP Wrappers. TCP Wrappers by itself isn't a complete solution as far as securing you machine is concerned. But it does fit into the overall scheme of framing a security policy for your enterprise. In this first part of the series, we will be introducing to you the whole concept surrounding the working of TCP Wrappers. We will leave out the implementation part for later. For now, we will help you get a foot hold on the use and importance of TCP Wrappers on a Linux/UNIX system. One more point that comes to mind, and which warrants clarification is the uniformity of concept that we are dealing with in relevance to the various UNIX operating systems . Of course, the procedure of implementation of the TCP Wrapper differ across various Unix systems, but we can assure you that if can find yourself GCC/G++ for your Unix machine, there's no stopping you from implementing this latest version of TCP Wrappers on your machine. Getting down to business ..... Are any of you Linuxers familiar with Eindhoven University of Technology, Netherlands? If you are, you would be fairly familiar with the product that originated from the labs of the "Mathematics and Computing Science Department, Eindhoven University of Technology". By now, you should have figured out our object of concern. TCP Wrappers was born under an interesting set of circumstances. It won't be relevant for us to bore you with those circumstances but it sure warrants reading. It's a typical administrators saga trying to track down a hardened cracker whose ultimate goal was to obtain a remote shell to run "rm -rf /". Though the cracker was never brought to justice, the occurrence of such episodes throws light on the serious vulnerabilities on Unix architectures. Before getting to know why we really need an application called TCP Wrappers, lets look at the protocols that our Internet/ Intranet is based upon. Most of the Intranets we come across and probably yours too is based upon the Ethernet standard offering 10/100 MBps data transfer duplex / half duplex on our Local Area Networks (LAN's). More recently, we have seen the emergence of Gigabit Ethernet in use for our corporate backbones. Ethernet as we know of is situated at the lower level in reference to the OSI model.
Application Ethernet is structured in such a way that it functions at the bottom of the OSI model. The Internet as we commonly know it is structured on the TCP protocol or Transmission Control Protocol. TCP/UDP works at the upper layers of the OSI model. We won't get into too much of the nitty gritty out here, but to be specific, TCP/UDP will work at the transport layer of the OSI model. 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 Table 1. Examples of TCP/IP client-server pairs and 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 We are on a client Linux box called foo1.bar and want to connect to a remote Linux box called foo2.bar which resides on a remote network. We then use the telnet client application from my box i.e foo1.bar to connect to the remote telnet server box foo2.bar. Have a look at the graphical illustrations as given below.
Figure 1. The inetd daemon process listens on the ftp, telnet etc. network ports and waits for incoming con- nections. The figure shows that a user has connected to the ftp/telnet port.
Figure 2. The inetd process has started a telnet server process that connects the user to a login pro- cess. Meanwhile, inetd waits for other incoming con- nections. This illustrates an unprotected machine. Fortunately, the author of TCP wrapper came up with a simple solution that did not require any change to existing software, and that turned out to work on all UNIX systems that were ever tried it on. The trick was to make a swap. Move the vendor-provided network server programs to another place, and install a trivial program in the original place of the network server programs. Whenever a connection was made, the trivial program would just record the name of the remote host, and then run the original network server program.
Figure 3. The original telnet server program has been moved to some other place, and the tcp wrapper has tak- en its place. The wrapper logs the name of the remote host to a file. This illustrates a protected machine.
Figure 4. The tcp wrapper program has started the real telnet server and no longer participates. The user can- not notice any difference. Lets look at the logs capable of being generated by our TCP wrapper application. May 22 14:43:29 tuegate: systatd: connect from monk.rutgers.edu Some of the first cracker connections observed with the tcp wrapper program by the author. Each connection is recorded with: time stamp, the name of the local host, the name of the requested service (actually, the network server process name), and the name of the remote host. Automatic reverse fingers had proven useful in the authors fight against the cracker, so he decided to integrate the "ad hoc" reverse finger tool with TCP Wrappers. To this end, the access control language was extended so that arbitrary shell commands could be specified. /etc/hosts.allow: in.tftpd: LOCAL, .foo.bar /etc/hosts.deny: in.tftpd: ALL: /usr/ucb/finger -l @%h 2>&1 | /usr/ucb/mail wswietse This is an example of a booby trap on the tftp service. The entry in the first access control file says that tftp connections from hosts within its own domain are allowed. The entry in the second file causes the TCP Wrapper to perform a reverse finger in all other cases. The "%h" sequence is replaced by the actual remote host name. The result is sent to the administrator by email. Our discussion till now gives only a limited illustration of the use of booby traps. Booby traps can be much more useful when installed on firewall systems, whose primary purpose is to separate an organizational network from the rest of the world. A typical firewall system provides only a limited collection of network services to the outer world. For example, telnet and smtp. By placing booby traps on the remaining network ports one can implement an effective early-warning system. Conclusions The TCP Wrapper is a simple but effective tool for monitoring and controlling network activity. Probably it has been installed in almost every part of the world, and that it's use is picking up almost every day. Some of the documentation and illustrations that we have made use of for this article accompanied the documentation that comes along with the TCP rapper package. In case you are interested in knowing more about the TCP Wrapper package, look at the following sites. ftp.uu.net:/comp.sources.misc/volumexx/log_tcp In our next article on this series of TCP Wrappers we will continue our discussion on the implementation of TCP Wrappers and we will help you create a minimal security policy using these TCP Wrappers. The secret of success is working
Other articles by Trevor Warren
Current Rating: [ 8 / 10 ]
Number of Times Rated: [ 52 ]
|
|
|
© 1998-2004 FreeOS Technologies (I) Pvt. Ltd. All rights reserved.
[Privacy Policy]
 |
