If you have ever wondered how to configure and run a secure open source firewall, look no further. This book excerpt is from chapter three of Open Source Security Tools by Tony Howlett, ISBN 0321194438, copyright 2004. All rights reserved. It is reprinted with permission from Addison-Wesley Professional.
At some point, preferably before you start loading software, you should document in writing a business process for your firewall(s). Not only will this be a useful tool for planning your installation and configuration, but it may also help if you have to justify hardware purchases or personnel time to your boss. Documenting your security activities will make you look more professional and emphasize the value you add to the organization, which is never a bad thing. It also makes it easier for anyone who comes after you to pick up the ball.
This plan documents the underlying processes and procedures to make sure that you get a business benefit from the technology. Installing a firewall is all well and good, but without the proper processes in place, it might not actually give the organization the security it promises. The following steps outline a business process for firewall implementation and operation.
1. Develop a network use policy. There may already be some guidelines in your employee manual on proper computer use. However, many computer use polices are intentionally vague and don’t specify which applications count as misuse. You may have to clarify this with your manager or upper management. Are things like instant messengers allowed? Do you want to follow a stringent Web and e-mail only outbound policy? Remember that it is safer to write a rule for any exceptions rather than allowing all types of activity by default. Getting the answers to these questions (hopefully in writing) is crucial before you start writing rules.
2. Map out services needed outward and inward. If you don’t already have a network map, create one now. What servers need to be contacted from the outside and on which ports? Are there users who need special ports opened up for them? (Hint: technical support staff often need FTP, Telnet, and SSH.) Do you want to set up a DMZ for public servers or forward ports to the LAN from the outside? If you have multiple network segments or lots of public servers, this could take longer than the firewall setup itself. Now is the time to find out about these special requests, not when you turn on the firewall and it takes down an important application.
3. Convert the network use policy and needed services into firewall rules. This is when you finally get to write the firewall rules. Refer to your list of allowed services out, required services in, and any exceptions, and create your firewall configuration. Be sure to use the “deny all” technique described in the sidebar to drop anything that doesn’t fit one of your rules.
4. Implement and test for functionality and security. Now you can turn on your firewall and sit back and wait for the complaints. Even if your rules conform exactly to policy, there will still be people who didn’t realize that using Kazaa to download movies was against company policy. Be ready to stand your ground when users ask for exceptions that aren’t justified. Every hole you open up on your firewall is a potential security risk.
Also, once your firewall is operating to your users’ satisfaction, make sure that it is blocking what it is supposed to be blocking. By using two tools discussed later in this book together, you can run tests against your firewall: A port scanner on the outside and a network sniffer on the inside will tell you which packets are getting through and which ones aren’t. This setup can also be useful for troubleshooting applications that are having problems with the firewall.
5. Review and test your firewall rules on a periodic basis. Just because your firewall is working great today doesn’t mean it will be tomorrow. New threats may evolve that require new rules to be written. Rules that were supposed to be temporary, just for a project, may end up being left in your configuration. You should review your rules periodically and compare them with the current business requirements and security needs. Depending on the size and complexity of your configuration and how often it changes, this may be as infrequently as once a year for firewalls with a small rule set (20 or fewer rules), or once a month for very complex firewalls. Each review should include an actual test using the scanner/sniffer setup mentioned above using the tools in Chapters 4, 5, and 6 to verify that the rules are indeed doing what they are supposed to be.
Designing and using a business process such as this will help ensure you get a lot more out of your firewall implementation, both professionally and technically. You should also develop plans for the other technologies discussed in this book, such as vulnerability scanning and network sniffing.
Flamey the Tech Tip: "Deny all!" When It Comes to Firewall Rules
There are two ways set up a firewall: You can start with an “allow all” stance and then add the behavior you want blocked, or start with a “deny all” statement and then add what you want to allow (permissible user behavior). The overwhelmingly preferred method is starting with “deny all.” By beginning with this statement, you automatically block all traffic unless it is specifically allowed in the configuration. This method is both more secure and easier to maintain securely than the other route.
Most commercial firewalls use this philosophy. The idea behind it is that if you have to define what is bad behavior, you will be continually behind as the Internet changes and evolves. You cannot predict what form the next new attack might take, so you will be vulnerable until it is published and you can add a new line to your firewall configuration. By using the “deny all” approach, you categorically deny anything that isn’t known good activity.
The “allow all” type of configuration might make sense in a extremely permissive environment where the overhead of adding lines for allowed items overrides the value of the information on the network, for example, on a nonprofit or purely informational site. But for most sites the “deny all” approach is much safer. However, just because you use this approach doesn’t mean your network is totally secure. Attacks can still come in via any holes you’ve created, such as for the Web and e-mail. Also, keep in mind that even when the “deny all” statement is used, you have to be careful not to negate it with an overly permissive statement higher up in your configuration.
This section describes how to configure a firewall with Iptables, which is the firewall/ packet filter utility built into most Linux systems with kernel version 2.4 and later. This utility lets you create a firewall using commands in your operating system. Iptables evolved from earlier attempts at firewalls on Linux. The first system, called Ipfwadm, could be used to create a simple set of rules to forward or deny packets based on certain criteria. Ipchains was introduced in kernel 2.2 to overcome the limitations of Ipfwadm. Ipchains worked pretty well and was modular in architecture. However, with the growing number of people using their firewalls for multiple functions (for example, proxy server and NAT device), Ipchains also became insufficient. Iptables represents an update to these programs and allows for the multiple uses that today’s firewalls are expected to perform. (Note that the concepts and terms for Iptables are pretty much the same for Ipchains.)
Iptables is a powerful but complex tool, and is usually recommended for users who are familiar with firewalls and the art of configuring them (see the sidebar on writing shell scripts). If this is your first firewall, I suggest using one of the autoconfiguration tools discussed later in the chapter to create your firewall configuration, at least at first. These tools use Iptables (or its predecessor, Ipchains) to create a firewall by using your input. However, it is good to have a basic understanding of what is going on “under the hood” with Iptables before start configuring with one of the graphical tools.