|
|
|
|
|
|
TCP Wrappers: Part 2
By Trevor Warren <trevor@freeos.com>
Last week, we had a look at the concept of TCP Wrappers from the theoretical perspective. As we have already mentioned, TCP Wrappers isn't meant to fulfill the security measures you would want for an enterprise network. But it surely does fall into the greater scheme of rule sets that would make up a comprehensive strategy to protect an enterprise network. The author of TCP Wrappers mentions this stating, that TCP Wrappers could be made use of along with a firewall box on your corporate gateway with minimum services running. While building a firewall, we suggest, that you pipe all the firewall logging off the gateway. Although complicated to set up, this is the best way to secure your logs incase your firewall machine is compromised. Features With the TCP Wrapper package you can monitor and filter incoming requests for the SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, EXEC, TFTP, TALK, and other network services. It supports both, 4.3BSD-style sockets and System V.4-style TLI. Count yourself lucky if you don't know what that means. The package provides tiny daemon wrapper programs that can be installed without any change to the existing software or to existing configuration files. The wrappers report the name of the client host and of the requested service. Neither do they exchange information with the client or server applications, nor impose overhead on the actual conversation between the client and server applications. Optional features include: The programs are portable. `Build’ procedures are provided for many common (and not so common) environments and guidelines are a great help incase your environment is not among them. Requirements: The wrappers should run without modification on any system that satisfies these requirements. Workarounds have been implemented for several common bugs in systems software.
The TCP Wrapper program, as we all know, is intelligent enough to perform a reverse finger on the client from where the connection originates and logs all the data to disk, if asked to do so. But, for instance, if the source IP address were spoofed, TCP Wrapper, being totally ignorant about such malpractices, wouldn't suspect any foul play. The wrapper programs rely on source address information obtained from network packets. This information is provided by the client host. It is not 100 percent reliable, although the wrappers do their best Recap Let us take a quick look at the functioning of TCP Wrappers. client server application The wrapper programs rely on a simple, but powerful mechanism. Instead of directly running the desired server program, the inetd is tricked into running a small wrapper program. The wrapper logs the client host name or address and performs some additional checks. If there are no glitches, the wrapper executes the desired server program and goes away. The wrapper programs neither interact with the client user or the client process nor with the server application. Another important property is that the wrapper programs are active only when the initial contact between client and server is established. Once a wrapper has done its work, there is no overhead on the client-server conversation. But like everything else, this mechanism too has its drawbacks. A major one being that since the wrappers go away after the initial contact between client and server processes, they are of little use with network daemons that service more than one client. The wrappers only see the first client attempt to contact such a server. The NFS mount daemon is a typical example of a daemon that services requests from multiple clients. Using TCP Wrappers There are two ways to use the wrapper programs: and The advanced way: where you leave the network daemons alone and modify the inetd configuration file. For example, an entry such as: tftp dgram udp wait root /usr/etc/tcpd in.tftpd -s /tftpboot When a tftp request arrives, inetd will run the wrapper program (tcpd) with a process name `in.tftpd'. This is the name that the wrapper will use when logging the request and scanning the optional access control tables. `in.tftpd' is also the name of the server program that the wrapper will attempt to run when all is well. Any arguments, (`-s /tftpboot' in this particular example) are transparently passed on to the server program. Logging information route The wrapper programs send their logging information to the syslog daemon (syslogd). The disposition of the wrapper logs is determined by the syslog configuration file usually /etc/syslog.conf. Messages are written to files, to the console, or are forwarded to a @loghost. Some syslogd versions can even forward messages down a |pipeline. Older syslog implementations only support priority levels ranging from 9 (debug-level messages) to 0 (alerts). All logging information of the specified priority level (or more urgent) is written to the same destination. In the syslog.conf file, priority levels are specified in numerical form. For example, 8/usr/spool/mqueue/syslog causes all messages with priority 8 (informational messages), and anything that is more urgent, to be appended to the /usr/spool/mqueue/syslog file. Newer syslog implementations support message classes in addition to priority levels. Examples of message classes include mail, daemon, auth and news. In the syslog.conf file, priority levels are specified with symbolic names: debug, info, notice, ..., emerg. For example, causes all messages of class mail with priority debug (or more urgent) to be appended to the /var/log/syslog file. By default, the wrapper logs go to the same place as the transaction logs of the sendmail daemon. The disposition can be changed by editing the Makefile and/or the syslog.conf file. Send a `kill -HUP' to the syslogd after changing its configuration file. Remember that syslogd, just like sendmail, insists on one or more TABs between the left-hand and right-hand side expressions in its configuration file. Configuring TCP Wrappers The first step towards configuring Wrappers on your systems is to make sure your INETD daemon is properly configured to accept and forward connections to the respective SERVER applications through which, you plan to offer various services. Let's have a look at a sample INETD configuration file. /etc/inetd.conf # The inetd will re-read this file whenever it gets that signal. ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd -a This is the inetd daemon configuration file wherein you will specify the server to be monitored. The above entry is for the FTP server, which causes the INETD server to accept connections and pass on the connection to the wrapper program /usr/sbin/tcpd. TCP Wrapper, then depending on the ACL's set from the files /etc/hosts.allow and /etc/hosts.deny, ALLOW or DENY connections to the respective server daemons. Now, a look at some sample ACL's using our /etc/hosts.deny and /etc/hosts.allow files. /etc/hosts.allow: in.tftpd: LOCAL, .foo.bar You could always check out these entries on your machine by editing the configuration files as mentioned above. The first entry in the hosts.allow file is as follows: in.tftpd: LOCAL, .foo.bar This very clearly states that all connections to the TFTP server daemon should be allowed if the connection originates from the local machine or the foo.bar domain. ypserv: 127.0.0.0/255.0.0.0 10.0.0.0/255.0.0.0 This very clearly states that all connections to the YPSERV server daemon should be allowed if the connection originates from the local machine (127.0.0.0/255.0.0.0) or from the IP 10.0.0.0/255.0.0.0. /etc/hosts.deny: in.rshd: ALL: /usr/ucb/finger -l @%h 2>&1 | /usr/ucb/mail foobar in.telnetd: 202.54.11.23 192.168.1. in.rshd: ALL: /usr/ucb/finger -l @%h 2>&1 | /usr/ucb/mail foobar The first entry in the above configuration tells TCP Wrappers that all connections to the RSH daemon should be dropped and a reverse finger should be sent to client, logging all the information obtained. in.telnetd: 202.54.11.23 192.168.1. This entry simply denies all connection attempts from the IP address 202.54.11.23 and all machines from the subnet 192.168.1.*. Conclusion
Other articles by Trevor Warren
Current Rating: [ 6.78 / 10 ]
Number of Times Rated: [ 27 ]
|
|
|
© 1998-2004 FreeOS Technologies (I) Pvt. Ltd. All rights reserved.
[Privacy Policy]
 |
