Securing Small Networks with OpenBSD, Part 1by Jacek Artymiak
Like almost all things in life, good security costs good money. It has to be that way, because there are simply not enough skilled security specialists to look after all of the networks that need their attention. An unfortunate result of low supply and high demand is the migration of highly skilled personnel to clients who can meet their salary requirements. This leaves a lot of small and underfunded networks in the hands of less experienced administrators, who might not know how to design, configure, and monitor these networks' safety mechanisms, leaving them vulnerable to attacks from unscrupulous people looking for inside information, free warez storage, zombie hosts for DDoS attacks, or systems they can simply destroy for fun of doing it.
Fortunately, many good security products are available for free and can be implemented using commodity hardware components and free or open source software. This article describes the design and implementation of a small network with a split private/DMZ design that allows a high level of protection for its users while making some services available to the outside world. The design is easy to implement and administer, even for beginners, and can serve as a foundation for custom security installations.
Our goal is to achieve maximum protection from attacks originating from outside of our network (insider attacks are a separate subject that I may get to in a separate article). At the same time, we do not want to spend a lot of money, which limits our options to open source or free software. This is not as bad as it sounds, because all major free operating systems contain high-quality network security software that can meet requirements of an enterprise client, let alone those of a small business or school network. Also, many of these free solutions are often incorporated into commercial products.
To keep things simple, I will assume that the network we are building will have just one connection to the Internet and that it will only have about a dozen or so internal users. Of course, you can always scale it up or down as you please, keeping in mind that you may need to use faster hardware, split the network into many smaller subnets to avoid bottlenecks, or even add more connection points to the outside world.
The design that seems to be the simplest to build and maintain uses a firewall that protects an internal private network, to which no outside connections can be made, and a so-called "demilitarized zone" (DMZ), in the form of a separate network with some services open to the outside world, also protected by the same firewall. These services might be DNS, WWW, mail, FTP, or news, but you are free to limit or expand that list as needed. The DMZ can consist of a single machine or a number of machines; it all depends on how complex you want it to be.
All traffic coming into our network will be checked and filtered by the firewall, running on a separate machine with three network interfaces:
- Interface A connects the firewall to the Internet. The IP address of the interface is assigned by the ISP (in this article I'll use x.x.x.x).
- Interface B connects the firewall to the internal private network. The IP address of this interface, in this article, will be 192.168.1.1.
- Interface C connects the firewall to the DMZ network. The IP address of this interface, in this article, will be 192.168.2.1.
The general outline of our network will look like Figure 1.
The firewall will use the following rules to manage traffic:
- All packets sent from the internal private network to all legal addresses should pass through the firewall without any restrictions. (This rule could be more restrictive, if necessary.)
- All packets sent from the Internet to the private network should be filtered, and only those that are valid responses to the queries originally sent from the internal private network should be allowed into the private network.
- All packets sent from the Internet to the DMZ should be filtered, and only those that are destined to the services that are being made available on the Internet may pass through the firewall. Also, all valid responses to the queries originally sent from the DMZ should be allowed into the DMZ as well. (This rule could be more restrictive, if necessary.)
- All packets sent from the DMZ that are valid responses to the queries originally sent from the internal private network should be allowed into the private network.
- All packets sent from the DMZ to the Internet, but not the private network, should pass through the firewall without any restrictions. (This rule could be more restrictive, if necessary.)
- All other traffic is discarded.
Apart from the packet filtering rules listed above, we also need a way to make services running on machines in the DMZ available to the outside world. It is perfectly possible to run all services opened to the public on the firewall machine, but by doing so we are asking for trouble, because the more services we actually run on the firewall, the "weaker" it becomes. By redirecting traffic to the DMZ, we are moving the target of a potential attack from the firewall to the DMZ and should the intruders break into these machines, they will still have to break into the firewall and the rest of the network, which considerably slows their efforts down and makes the whole network more secure. (This packet redirection mechanism is sometimes called "port forwarding.")
Because small networks will usually have a single IP address assigned by their ISP, the firewall will also need to run some sort of "masquerading" software, which makes all traffic from the internal network and the DMZ appear as if it originated from a single machine. This is an additional security measure that makes our network harder to compromise, because the IP addresses of the machines behind the firewall are never revealed to the outside world.
Free firewall products that can filter packets, redirect traffic to other hosts and perform IP address masquerading are
iptables. The first two packages are used in the BSD family of operating systems, while the last two packages are popular on the Linux platform.
Choosing Software and Hardware
The firewall software I choose to describe in this article is Daren Reed's
ipfilter, running on OpenBSD 2.8.
ipfilter is also available for NetBSD, Solaris, SunOS, BSD/OS, IRIX, HP-UX, and QNX. If you use other firewall software, you must remember to translate the rules presented later in this article into the syntax of that particular software package. (The general design principles will be identical in all cases.) I chose
ipfilter, because a) I know it well, b) it's been thoroughly tested, c) it's the default firewall on OpenBSD, and d) I like its simple syntax.
ipfilter performs stateful packet filtering; that is, it can recognize incoming packets that are replies to the queries sent by users located inside of the protected network, and lets them through without the need to write complex firewall rules. It also includes a straightforward packet redirection and masquerading module,
As for the hardware, the machine running the
ipfilter firewall software can be any computer supported by OpenBSD or another operating system for which
ipfilter is available (either commercial or free), such as NetBSD, as long as it can accommodate at least three network interfaces (one to connect to the Internet, one to connect to the internal private network, and one to connect to the DMZ). My choice was a generic desktop PC with a low-end Pentium processor, equipped with a serial port and three free expansion slots on the motherboard, but it could just as well be an Alpha, Sun, VAX, or any other machine that meets the requirements listed above. In any case, the hard disk that the firewall machine will use should have a capacity of at least 540MB. It is fine to use an IDE drive instead of a SCSI device, as the disk system will not be stressed too much, as long as the machine has at least 24MB of RAM.
Other important components are the network interface cards. For connecting the internal network and the DMZ to the firewall I recommend 10/100Mb/s cards with 10BASE-T sockets for twisted-pair cables with RJ-45 plugs, as they are inexpensive new or secondhand. The rest of the equipment necessary to make everything work together includes twisted-pair cables and 10/100Mb/s hubs with 10BASE-T sockets (or one hub for the private network and one crossover twisted-pair cable, if the whole DMZ sits on a single machine).
I recommend that you use twisted-pair cables (and cards and hubs with RJ-45 sockets) instead of coaxial 10BASE2 cable, because twisted-pair installations are much more reliable, even though they require a hub. (A single failure in a coaxial installation leaves all computers connected to the same cable without access to the network, while a failure of a single twisted-pair cable disconnects only one machine.) That's it -- that's all the hardware you need, besides a Phillips screwdriver.
Now, before you raid second-hand equipment shops in your area or log on to eBay, I suggest that you carefully check the supported hardware lists posted on the OpenBSD Web site, as well as the INSTALL documents found in the top directory for the hardware platform you want to use (i386 for Intel x86 and Pentium processors). This will save you a lot of trouble during installation.
You should also download all available configuration utilities for your computer, disks, controller cards, network interface cards, and the actual chips that these cards use. I recently found a strange Ethernet card that could not be configured using the card manufacturer's own utilities. I used the card chip's manufacturer's utility instead, and it did work as expected. (Thank you, Nick!)
If you are having trouble with a hard disk, try downloading a configuration/setup utility from the disk manufacturer's Web site. If that does not help, go to the computer manufacturer's Web site and download appropriate utilities. These might only be available from the major computer manufacturer's sites; that is why it pays to buy used hardware made by companies that are still around, like IBM, Compaq, Dell, or Gateway.
The last important software tool is a bootable DOS disk or a Windows 95/98 rescue disk from which you will need to boot your computer before you can use the configuration utilities. Since I am not too sure what Microsoft thinks of using DOS or Windows boot disks to configure computers in order to install other operating systems, I suggest that you either obtain a legitimate copy of DOS or MS Windows that you will use for that purpose, buy a copy of DOS from IBM, or better still, download FreeDOS, a free DOS clone. Once you have DOS in one form or another, make a boot disk, remove all unnecessary files from it, and copy the necessary utilities onto it.
(Note that you do not need a copy of DOS or Windows to install OpenBSD itself; bootable disk images are a part of the system's distribution.)