firewalls at home

by John Sinteur
<john@dubbele.com>

John Sinteur is the maintainer of the free NetBSD/i386 Firewall project at <http://www.dubbele.com/>. John's current day-time activities include being contracted out by his employer, Aedius IT diensten, as a lead developer for e-commerce applications.

WHAT IS A FIREWALL ANYWAY?

A firewall is a computer that connects to two networks (usually the Internet and a local-area network) and doesn't allow any traffic from one to the other. Now, that can just as easily be achieved by not connecting the two networks together, and although the practical upshot of a firewall is that nobody on the Internet can connect to your shared printers and disk drives on the local network, it isn't really useful until you start adding things to it. Those things can be of two categories: allowing network packets of a certain kind to travel through, or acting on behalf of computers on one network to get some service from a computer on the other network. The firewall in this article is configured not to let any traffic through, and not to do anything on behalf of computers on the Internet side, and to act on behalf of the computers on the local network for any network service they want, through a mechanism known as NAT. Another way to do the same would be by using proxy applications. A proxy application knows one protocol only, such as Web requests, so you would need to add one for every service you want to provide. What the firewall does not protect against is malicious content. So if you pick up an email with a virus attachment, the firewall is not going to stop you. If that virus attachment is a tool that can be used to participate in the next DoS attack, the firewall is not going to stop that attack. However, nobody on the Internet who tries to trigger the attack can send a signal directly to the tool, because that would be stopped.

The Problem, Or, Times Are A-Changing

Firewalls have traditionally been pretty scary things — devices that sat in protected areas in the computer room, maintained through High Wizardry, protecting the Company Network from All Evils. However, as we have seen with the DDoS attacks earlier this year, computer security is not something that should be limited to large companies with big, fat pipes coming off the Net. Neither is computer security something that is being done solely to protect the company network from what's happening outside. Not a great many people are aware that nowadays the Internet as a whole can be in trouble when a single system, yours, is compromised. With tools like Tribal Floodnet, TFN2K, and Stacheldraht, your system is not the one that is hurt the most when it is compromised. Your system could be used to participate in the next round of DDoS attacks that hits the news, or it could be used to send out spam.

A big change is happening right now: it's no longer just companies or universities that have fast enough permanent connections to be of interest to the average script kiddie out there. With cable modems and ADSL lines being installed in huge numbers, there's lots of bandwidth connected to unprotected systems. People at home never had to think about this kind of thing before. They are not aware that they are the next big target for script kiddies. The number of systems that can be compromised easily is exploding. And can the home user really be blamed? I don't think so. What's special about an average family with kids in high school owning more than one computer in the home, and connecting them together in a small network to share a hard disk or a printer? Nothing really, but unless they take specific action to prevent it, those drive shares will be accessed from across the planet. Any sysadmin who has installed snort¹ on his firewall can testify that Windows shares are the most often scanned for "vulnerability."

Security at Home

Companies should not assume that as long as their computer network has a good firewall and security policy, employees' home computers are a nonissue. In the good old days when people dialed in through a phone line, odds were those same phone lines were used to connect to their Internet Service Provider. Since people only had one phone line and one modem, they were either connected to the Internet or to the company network, but never to both at the same time. That, too, is no longer true. Legit employee access can be exploited, and your company firewall is not likely to notice that. Deploying some VPN technology may be the answer in this particular case, but make sure to have the right questions when you implement it. Securing just the connection between the home computer and your company network is not enough. Any computer that is connected to two networks at the same time is a potential relayer for attacks, and you need to make sure that the solution you choose addresses all possible threats.

There is a huge gap in security level between companies and families at home. Firewalls are traditionally expensive. Buying the firewall software and hardware and the machine to run it on, and training the system administrator in writing and maintaining the firewall policies (and in keeping the company policies on security in general up to date), takes money. Company firewalls usually allow people on the Internet to access Web and mail services provided by the company. It often also allows employees to access resources on the Web. Companies have to take the actions required to ensure that enough protection is in place to provide just those services, and those services only. Home users have fewer requirements. Typically, they do not run a Web or mail server; they just want their home computer inaccessible from the Net, without being limited in their browsing.

However, even those lessened requirements come with a gotcha: the thousands of dollars a company normally invests in security are not available to the home user, so it is impossible to apply the same amount of effort that the company does. Acquiring the know-how is out as well — people have enough problems figuring out what the browser buttons do, or how to change the skin on the new version they just downloaded, and can't be bothered to learn about SYN floods as well. Therefore, there has to be an answer that does not cost a lot in terms of money or effort but meets the security requirements that are specific to those home users.

Shareware Answers

Lots of shareware authors jumped into this hole by writing little background applications running on Windows systems, trying valiantly to stop network services from being abused. Windows, however, is a moving target when it comes to protection on the computer itself, and besides, not everybody uses Windows. Mac and Linux owners face the same problems — they have to protect their systems from abuse, and the knowledge to secure those systems is not generally available. The rise of the ever more popular Linux is especially a problem. Sure, out of the box it is generally more secure than Windows, but since Linux is traditionally more a server system than a client, chances are people will, sometimes inadvertently, turn on those services. Telling people, "Well, don't do that then" is not an option — sharing Windows drives is far too useful to tell people not to do it, and Linux users typically want to play around with their systems. So, some time ago I set myself to developing a better answer.

WHAT TO AIM FOR?

I set myself a few limits. First, it had to run standalone. As any firewall administrator can tell you, "One function, one box" is an important design concept. It keeps things simple, and therefore easier to handle. Cost is another limit. If possible, whatever I came up with had to run on hardware already available, or, better yet, on surplus hardware. Since most cable-modem and ADSL owners are pretty computer-literate, probably having graduated from using dial-up connections, it is fairly safe to assume they have either an old computer lying around gathering dust or enough computer savvy to buy such a "boat anchor" cheaply. I decided my firewall had to be able to run on any discarded 80486 PC with less than 100MB of disk space, and 8MB of memory. Buying a second Ethernet card is just about the only cost I was willing to incur. From the feedback I got, these design decisions turned out to be well balanced. I've been told success stories by users who invested a few dollars in a secondhand computer; some bought only a second Ethernet card and a dust rag to clean out an old system.

I aimed at a "fire and forget" system. Of course, any company large enough to have a good security policy and dedicated staff will have to do maintenance all the time, but the home user probably wants to stick a box in the basement next to the cable entering the premise, and perhaps clean an air filter every two years, but that's it. Forget about it. Seemingly, this goes against the fact that security is an ever-continuing effort, but don't forget that this is a simple home-network solution. The ironic fact is, there are so many cable-modem and ADSL owners who don't secure their digital premises that even minor security measures are likely to send the cracker searching for easier targets. Not that I was going to settle for minor security improvements, but it's useful to keep in mind the kind of adversary that you're dealing with. Obviously, Amazon has different security requirements (and a budget to match) compared to Joe Six-Pack.

"Fire and forget" also has its effects on daily maintenance. For example, nobody is ever going to look at log files or console warnings. Sure, that's against every firewall policy I ever saw, but the whole point of this particular setup is: Home users will never perform daily or even monthly maintenance, if any at all. There is no sense in denying: yes, this is a firewall, but not as we know it.

Keeping the costs low means using existing open source wherever possible, and running on leftover PCs limits it to Linux or one of the BSD variants, since those operating systems still perform very well on those older machines. I picked NetBSD because that was the one I was most familiar with. It has to use NAT² so it can use one of the reserved address ranges³ for the inside network. That way, people can configure their machines in any way they want, without having to worry about interfering with the Internet. Although NAT is not meant to be a firewall, using it with reserved addresses makes the internal machines effectively unreachable from the outside, and that's a very nice bonus. Talking bonuses, it also means that no matter how many computers there are behind the firewall, the ISP will see only one: the firewall. Since some service providers like to charge extra if more than one computer is hooked up to the connection, this could save people some money. It could be against ISP policy, but most providers only charge the extra money if you take up extra IP addresses.

Turning off all other network services on the firewall box and building a kernel that has unwanted or unneeded services turned off (such as source routing, debuggers, and optional filesystems like NFS) gives you a system that is already more secure than some commercially available firewalls. Curiously enough, the next step would be to write extensive packet-filter rules — something almost every firewall vendor will either do or require — but I decided against it in this case. It would be too much of an effort while adding relatively little extra security. Let's face it: most packet-filter rules are there to prevent address spoofing and to limit the availability of servers under specific circumstances. Since the typical cable-modem or ADSL owner is not likely to run servers (some ISP policies explicitly forbid it), one major reason for filtering goes out the window. Source routing could be another good reason for filtering, but I turned that off in the kernel. Some more exotic network features such as ICMP redirects and IP option flags remain, but they are usually of no relevance to this particular setup anyway. Again, remember that we're talking home networks here. By the time you get down to analyzing the risks of the things the filter rules protect you from, you're at a level far beyond what is required for this situation. There are simply no services offered by the firewall, viewed from the outside. There's no service listening to the network, and where there are no services, exploiting them is not really feasible. I've had some requests from people who do want to run services, most of them with small Web sites, and also some with networked multi-user games. When I find the time I will write some Web pages explaining how to add support for this to the firewall system.

INSTALLATION

Since we are talking "Fire and Forget" systems, the only remaining technical hurdle is the installation process. The NetBSD installer is already very friendly, but some assumptions about the installation can be made beforehand to simplify the installation process further. For example, the firewall box is going to run just one operating system, with a known set of software, so any disk partition and multiboot questions can be skipped, with appropriate defaults filled in. Adding support for DHCP is a must, since a lot of service providers do not give their client fixed IP addresses. When you get down to it, you can almost reduce the questions you have to ask the user to, "What Ethernet card did you connect to the cable modem?" and "I am about to wipe your disk, is that OK?" How's that for simplicity?

Future Developments

Did I mention that any nonserving network can be reasonably protected by this scheme? SOHOs can use this as a way to protect their office networks as well — good security for a very low price and low overhead. In fact, from a technical point of view, even large businesses might find the system useful as a starting point. When you buy a new low-end Pentium system, you'll have at least 400MHz these days, with 64MB memory and a few GB of disk space — with a system like that, and the firewall installed, it is possible to support hundreds of users and a fat pipe to the Net. And all that without breaking a sweat. At that point, the focus shifts back to installing and maintaining services like mail and Web. I give some email support, but if a company wants to be able to fall back on the firewall provider 24 hours a day, I happily point them toward commercial firewall vendors. For me, this is just a volunteer effort, as so many open source projects are.

I admit that it has been very tempting to add services to the system. After all, Squid, Apache, and a mail daemon are easily added to the system, and before you know it, you've got a Small Business Server. However, I feel it wouldn't be a firewall any more, and I would not want to promote it as such. I might build a system like that at some point, since it's not difficult, but I would set it up as a different product, and serve it off a different domain. Way back in the good old days, a 4GB disk was something reserved for file servers. Today, a disk with many times that amount almost comes free with your breakfast cereal, so adding Samba and Netatalk to the Small Business Server is also a possibility. But I digress.

Conclusion

There's one important caveat to this story: I'm preaching to the choir here. Any one reading this magazine knows it's a jungle out there, and it's the average Web surfer at home who needs this information most. Getting the word out is not easy. Even the attacks on Amazon, CNN, and others in the beginning of 2000 go only so far in making people aware. Most people get a false sense of security, thinking it's something that affects Amazon, CNN, and a few other dotcoms, but not them. They don't know that it was the thousands of insecure computers (just like they have at home) that were used to launch the attack. I have yet to see statistics on what computers were used and what organizations own those computers. And it doesn't really matter anyway, because since those attacks took place the tools involved have migrated from the UNIX platforms they were exclusively running on to Windows computers (and, in one case, Macs). There are lots and lots more of those around. For a good time, take a look at <http://www.dubbele.com>, and remember to let me know what you think of it.

REFERENCES

1. <http://www.clark.net/~roesch/security.html>. Snort is a libpcap-based packet sniffer/logger that can be used as a lightweight network intrusion-detection system.

2. <http://www.faqs.org/rfcs/rfc1631.htm>. Network Address Translator.

3. <http://www.faqs.org/rfcs/rfc1918.html>. Address Allocation for Private Internets.