Print
Close Window
From: www.itworld.com
Installing a firewall, Part 1
March 26, 2001 —
This article is the first in a three-part series that provides a blueprint for setting up a multifunctional firewall and server. You'll want to do this if you don't want to spend the resources to have one computer act as a Web server, another as a print server, yet another as a firewall, and so on. Whether you're concerned about increasing the security level at your small business or setting up a firewall and IP Masquerading server at home, these articles will show you the steps we took to replace an old server with a multifunction server and firewall. After reading the series, you should be able to configure a functional firewall and server that provides basic Internet services while maintaining a moderate level of security.
We will use the systems we set up for one of our clients as our example configuration. The client shop had a Linux-based GNU system as its main server and firewall. The box was an old 486 running Red Hat 5.2, upgraded from 5.1. Over time, its duties had grown from simply mail service to Web, anonymous FTP, login, and CVS (source code revision control) serving. Two years ago, it was compromised twice -- with minimal damage, but several work days lost in cleanup. Further, the old machine (we'll call it plains.example.com) was too slow for all the services it offered -- and our client wanted to add more.
Security analysis
Before deciding what to do, we performed a simple security needs analysis. Our client is a small software engineering firm with virtually no valuable hardware. Its primary asset is its source code and hence the primary risk is the loss or damage of that source code. The client's second main risk is the amount of time that would be wasted in cleaning up after a break-in: finding backdoors and eliminating them, reinstalling operating systems, analyzing logs, and so on.
To manage those risks, we decided to take several steps. First, we would separate the CVS server function from the firewall function, thus rendering the client's source code less vulnerable. We would institute nightly backups of the source code in order to minimize potential losses. Finally, we would improve overall site security by installing a new firewall with fewer services to compromise.
This series of articles will tell the story of that firewall, which we'll call wolf.example.com.
Choosing an OS and distribution
There are clearly many candidate operating systems to choose from, both free and nonfree, as well as some commercial firewall appliances. We decided to go open source (cheap) and multifunctional (real operating system). We considered several flavors of Linux and one of BSD.
OpenBSD has the best security reputation of any operating system. However, we were unfamiliar with it; it also has a reputation for being difficult to install. Furthermore, the day-to-day administration of the firewall was to be the responsibility of the client, and the staff there had no experience with BSD either. We decided right away not to go with OpenBSD for those reasons. We intend to play with OpenBSD ourselves before recommending it to our clients.
Red Hat was a tempting choice, since the old server already runs it and our client had experience administering it. However, Red Hat is not a security-focused distribution. In addition, Red Hat comes with lots of usability- and desktop-oriented software which would just take up space (and create security holes) on a server. We decided not to go with Red Hat for the firewall.
Immunix from Wirex Communications (see Resources for a link) looked like a very promising candidate. The basic distribution is Red Hat 6.2, with all programs compiled by the StackGuard compiler, which protects against most stack-based buffer overruns. It does not prevent heap-based buffer overruns, however, and incurs a 10 percent performance penalty due to the extra checking. Also, it includes all of the excess software that comes with Red Hat. You also have to register before you can download it. But the icing on the cake was that SubDomain and Cryptomark, two security enhancements described on the Immunix Webpage, are "not quite ready for public release" (emphasis in original). In other words, two thirds of the security package is vaporware.
We liked the cute name of the Bastille distribution, but quickly found out that it wasn't a distribution at all. Apparently, Bastille is a set of Perl scripts that you run postinstall on your Linux system to beef up security. We want to run it on the server after we install Linux.
After running that gauntlet of half-fixes, we were very pleased to find Trustix. It is small and server-oriented -- it has no GUI, for example. The distribution includes more secure versions of various services, including postfix for mail, and bsd-ftpd instead of wu-ftpd. In fact, Trustix appeared to have no downside. We happily proceeded with the install.
Catalogue of services
Since we were duplicating the functionality of an existing firewall (
plains), there was a well-defined list of services which our new box (wolf) would have to address. We set about generating a list of services.
First, we went through /etc/inetd.conf, the Internet superserver configuration file. It listed many of the services currently running on plains. Then we ran netstat -a to determine which sockets have something listening on them; we found some services not listed in inetd.conf, such as the ssh server and the Web server. Finally, we did a full process listing with ps aux to make sure we hadn't missed anything.
We decided not to allow Telnet or POP access to wolf. Users can log in remotely with ssh, and no one will keep email on wolf, making POP unnecessary. We were reluctant to allow authenticated FTP, but it was a strong client requirement, so we looked for some way to enable it. (The chrooted FTP offered by bsd-ftpd seemed viable, but we're open to suggestions -- please send me email via LinuxWorld if you have any.) All three of these protocols (Telnet, POP, and FTP) send passwords in unencrypted form and thus are vulnerable to sniffing attacks. We staged a sniffing demonstration which suitably impressed the client.
In order to provide mail service without making wolf the client's mail server, we decided to use postfix to route mail to and from plains, which would keep running sendmail behind the firewall. Further, since our client has employees who read their mail on Windows and Outlook, we decided to apply a processing step to email on the firewall: nontext attachments would go to a security administrator who would vet them and pass them on if safe.
plains provided the company's Web service and anonymous FTP access to its software. We decided to move the FTP service to wolf, using a secured FTP daemon. However, we didn't want to run Apache on the firewall, so we left that on plains, and decided to use Squid on wolf as both a proxy server and an accelerator.
We were left with ident, CVS, and a print server. The print server had no business being outside the firewall and neither did CVS. We decided to leave both on plains and not to install them on wolf. ident, on the other hand, had to be outside the firewall. We decided to install a simple, lying ident daemon to satisfy client requirements without giving away valuable security information.
Installing Trustix 1.1
The new system consisted of a remaindered Pentium 133 MHz, with 32 MB of RAM and a 2.5-GB hard drive. We installed two Ethernet cards, one PCI and one ISA, both NE2000 clones. The ISA card was a combo because the client has an internal thinwire network. The PCI card was RJ-45 only, which plugged into the client's hub. We started with only the internal network connected.
Using plains, we downloaded a boot floppy image from the Trustix site (see Resources for a link). We dd'ed it to a new floppy using the command dd if=bootnet.img of=/dev/fd0. We booted wolf successfully and began the install.
The first question the Trustix network install asks is what driver to use for your Ethernet card. The fact that it didn't ask which Ethernet card to use should have been a warning. We tried to choose a driver for our ISA combo card, but there were no ISA drivers at all. So we scrounged around and found a PCI combo card. However, when we selected the correct driver for that card, we discovered that the Trustix install was trying to talk to the other (PCI NE2000 clone) card, which we could not connect to the internal network. We could have switched the slots, but we just pulled the noncombo Ethernet card, and two hours down the road, we were again ready to continue the install.
Next, Trustix asked which network installation method we wanted to use. The options were mirror, NFS mount, HTTP, and FTP. We selected the mirror option. Unfortunately, it failed because our client didn't allow DNS behind the firewall, and the Trustix install uses host names instead of IP addresses for its mirrors. So the installer would try to resolve the name to an IP address, wait until the specified five-minute timeout, give up, then try again. And again. Normally, long timeouts and many retries are good in that they make things work over a flaky connection; however, if it's just hopeless, retries are a huge pain.
Given that we were using a 1.1 product, we had hoped that the makers would have tested it a bit. We weren't expecting to be the first people to try to install Trustix from behind a firewall and find out that it doesn't work. Such networking and hardware issues should be identified -- and fixed -- in the beta-test stage. That said, the box came up in a useable and reasonably secure state. There are still some areas which we think Trustix should address for its 1.2 release, though.
Next we tried the FTP install from the official Trustix FTP site (using its IP address, of course). This install failed for unknown reasons. Masqueraded FTP does work on the client site, but apparently not from the Trustix installer. Finally, we downloaded the entire Trustix distribution onto plains and set up an FTP install locally. This method seemed to work. At any rate, it got us to the next stage of the install process.
Trustix's partitioning tool (Disk Druid) was fairly straightforward, although it had crummy help documentation. We proceeded smoothly to the security configuration, which was very pleasant after the network install. By default, Trustix uses shadow passwords and MD5 hashing. The company warns against the casual use of root and allows the creation of nonroot accounts during installation. However, Trustix didn't even peep when we set root's password to "password." Maybe Trustix's dictionary doesn't include that one.
After we had configured TCP/IP, time-zone, LILO, etc., and chosen the packages we wanted to install, the installation suddenly failed. After some poking around and reading the install documentation, we learned that plains was running an incompatible FTP server. Note to Trustix: maybe your install script should be less finicky.
So we moved our local mirror under the Web directory and did an HTTP install. In the process, we had to reconfigure everything because Trustix maintains no state information -- flash back to Slackware 1.0 "setup" days. It's a good thing we'd already downloaded the whole Trustix distribution, because there was no easy way to instruct the HTTP install process to use a proxy.
Since this was our second time around, we didn't read the package selection page very carefully. We thought we'd selected Install With Individual Confirmation, but Trustix installed everything with no confirmation. Oh, well, we figured could always uninstall what we didn't need. The total install took up about 400 MB. After a kernel recompilation (we'll get to that in the second article), the total space occupied was about 500 MB, which was very reasonable and lightweight.
After the install, wolf rebooted with no problems. We ran nmap against it and came up with nothing. The box was a total black hole. After all of that trouble, this was a rewarding experience.
Fatal flaws
Trustix's silent lack of ISA support is totally unacceptable. We understand that a floppy disk is small, but so are drivers. Furthermore, part of the point of Linux is to work on old or random hardware. The lack of firewall support is also crippling. If we hadn't been overcommitted to installing Trustix, we would have used the Red Hat CD we had in our hands when we discovered that Trustix required DNS and didn't support proxies.
There also should have been a shell escape from the install process. It would have made troubleshooting the network failures easier. For future reference, after loading the second image, there is a root shell available on the second virtual console, and logging information appears on VC's 3 and 4. It was particularly frustrating that the install was stateless -- one easily gets tired of re-entering one's IP address and changing the gateway address from the default.
Finally, the fact that you can't choose which Ethernet card to use during the network install makes it obvious that Trustix is not intended for use as a firewall -- since firewalls always have at least two network interfaces. It would be nice if Trustix were friendlier to the small, multifunction server market.
Strong points
However, once installed, Trustix was exactly what we had hoped. It was small, pleasingly secure by default, and came with secure servers preinstalled. We didn't have to manually install postfix or openssh, as is necessary with many other less security-oriented distributions. And the ISA issue would be irrelevant on new boxes, since they will have only PCI slots.
Wish list
The next Trustix install program should definitely be able to tell when multiple Ethernet cards are installed and allow the user to choose which one to use for the network installation. The install should allow configuration of an HTTP proxy for network install through a firewall. If Trustix makes those changes, Trustix 1.2 could easily become the distribution of choice for multifunction server/firewalls.
We would have liked to have installed Trustix from the mirror, but that option failed from behind the firewall. Perhaps the installer should try IP addresses when it can't reach the mirror site using the host name. However, the firewall would still have to allow either FTP or HTTP traffic for this method to work at all.
Finally, there were some minor annoyances, mostly related to overly spare software (to our tastes). For example, the GNU findutils were not installed by default. When you're accustomed to using locate, it's rather a shock to have to remember where squid.conf is (it's in /etc/squid/). Also, we like to use RCS for version control of config files. Trustix doesn't include it by default, either. However, both of these packages are, of course, only an RPM away.
- Trustix boot disk image:
ftp://metalab.unc.edu/pub/Linux/distributions/trustix/trustix-1.1/i586/images/bootnet.img - Trustix homepage:
http://www.trustix.net - Immunix homepage:
http://immunix.org/
LinuxWorld.com