TCP Wrappers is one of my favorite packages. It's simple, free, and easy to implement. Logging is very concise. In fact, I will look at the
<font face="Courier">tcpd</font>log before looking at the firewall software logs.
TCP Wrappers allows you to impose service limitations based on IP addresses. The wrappers consist of a binary (
<font face="Courier">tcpd</font>) and uses two files,
<font face="Courier">/etc/hosts.deny</font>(logging goes to
<font face="Courier">/var/log/tcpd.log</font>). Obviously,
<font face="Courier">/etc/hosts.allow</font>is the file to allow services and
<font face="Courier">/etc/hosts.deny</font>to deny services.
One word of caution with this tool: by default, a service that is not specifically denied is implicitly allowed. Therefore, I always create an
<font face="Courier">/etc/hosts.deny</font>file with the entry
<font face="Courier">ALL: ALL</font>to deny everything that is not defined in
<font face="Courier">/etc/hosts.allow</font>. Otherwise, you may unwittingly allow something that you don't want to allow.
Some daemons (such as
<font face="Courier">sendmail</font>) incorporate TCP functionality (see my series on
<font face="Courier">sendmail</font>in Resources below). You can also add TCP functionality to any program by including
<font face="Courier">tcpd.h</font>in the program, compiling with
<font face="Courier">libwrap.a</font>, and following the documentation provided with TCP Wrappers.
The Washington University
<font face="Courier">ftpd</font>is a very nice replacement for the standard
<font face="Courier">ftp</font>daemon. It provides much better access control and padded cell usage than the standard
<font face="Courier">ftp</font>. I use it on my public FTP server to allow users to come in and pick up files; but at the same time, they are not allowed to see other people's files. There have been a few security problems with older versions of
<font face="Courier">wu_ftpd</font>, so make sure you have the current one.
With Secure Shell you can construct a secure communication mechanism between machines. The package provides several encryption methods (including RSA and IDEA) and authentication methods. I have not evaluated the commercial version of SSH that seems to have more features.
The open source version (for noncommercial use only) does have a couple of drawbacks. It only supports a secure shell (replacing
<font face="Courier">rlogin</font>), and a secure copy program (replacing
<font face="Courier">rcp</font>, though it doesn't support recursive copy), and an FTP client. The noncommercial SSH does not directly support X services. If you need to run an xterm, you have to set up a mechanism to allow X back through your firewall. That is not always feasible. It might be better to use a virtual private network (VPN) for this function.
My partner, Jonathan Klein, used SSH to construct a mechanism for synchronizing Web pages from an internal Web server (the preproduction environment) to a production server outside the firewall. He had to give the developers the ability to push their pages outside without providing them with real logins on the machine. The problem was that
<font face="Courier">scp2</font>(Secure Shell Copy) does not provide for recursive copying. Klein wrote a C program that wrapped around the Secure Shell commands. It queried a simple access list to verify that the user was permitted to update the files. Then it scanned the directory to find all the directories that needed to be created on the other machine, and generated a shell script to create them.
The C program ran a premove script that created a temporary head directory on the production server. Then it used
<font face="Courier">scp</font>to copy the directory script to the production machine and used SSH to run it. Next, the program generated a script of
<font face="Courier">scp2</font>commands to copy all the files to the appropriate place on the production machine. The script was then executed, and the files were copied over. Finally, a postmove script was run through SSH to move out the old files, move in the new files, and set the ownership and permissions properly for the Web server.
Virtual private networks are useful when you want to create a pipe to your network to allow administrators outside the network access to the network as if they were local. VPNs are very useful for remote administration through the Internet. Most remote dial servers are too slow and expensive to maintain. Administrators usually have Internet access from their homes anyway -- and at much faster speeds than the 28.8K modems that many remote dial servers provide.I happen to use VTPCSecure from InfoExpress to handle administrative functions. It allows me to enter the remote network through the Internet. I use triple DES encryption with keys that change every 15 minutes and SecurID rather than static passwords for authentication. The tunnel allows me to use Telnet, FTP, and X Windows (the VPN provides other functionality I haven't used yet). Those three are sufficient for me to maintain my firewall remotely. It sure beats commuting through New York City tunnels!
Next month, I'll conclude this series with a discussion of firewall software deployment.
Much appreciation to Casper Dik of Sun Microsystems and Dr. Mudge of L0pht Heavy Industries for their contributions. Also to Jonathan Klein (Wizard's Keys), who contributed extensively throughout, and to Brian Martin (Attrition.org) for his review and suggestions.