Building Firewalls in the Real World
"Okay," you ask, "So, what's the best firewall, and what's the best way to deploy it?" Ah, if only life were so simple. The short answer is that there is no single, best solution. However, there are some good tips and guidelines that can help you come to a strong decision, and I will do my best here to get you started down the right road.
Let's begin with a few prepurchase guidelines:
1. Understand that firewall platforms change there is no superior firewall platform. For example, VendorX might have their head in the clouds for a few revisions, and then get their act together for the next version of their product. By the same token, VendorY and VendorZ might have great products one year, and deep-six them the following year after all their lead developers die bungee-jumping in Kazakhstan. Keep up with the testing done by magazines like Network Computing and InfoWorld, talk to your peers, and, above all else, test the products if you can. Think of a firewall as a new car: If you don't like how it feels, you don't want to be driving it for the next few years.
2. Understand and document your requirements. Do you need your firewall to support Token Ring, or just Ethernet? Do you need your firewall to support Network Address Translation (NAT)? How many interfaces do you need? Does the firewall need to run on a particular platform? People all too often get caught up in extreme benchmarking num bers and massive feature lists. But if you don't need your firewall to manage your toasters, and you don't have 15 OC12 links coming into your DMZ, you might not need the fastest and the shiniest. Remember what your firewall is primarily going to be used for: controlling access into and out of your network.
3. Know your limitations. If you are primarily a Windows NT shop with no UNIX expertise, going out and purchasing a UNIX-based firewall that requires a lot of command-line interaction might not be the best of ideas. Keep in mind that a good portion of firewall failures are because of "pilot error" that is, the firewall does not fail, the person administering it does. Know your limits. If you or your staff don't understand how to use it, or if the technology is way over your head, that is only going to come back to haunt you. Don't choose the firewall with the prettiest GUI, but don't pick one that takes a Ph.D. to administer, either.
4. Go with a product that has been at least ICSA certified, and preferably something that has a respectable installed base of users. Just because it says "firewall" in the product literature doesn't mean it's secure. Go with something that has been proven on the battlefield.
One of my employer's clients (a Fortune 100 company) contracted our team to take a look at a new firewall "appliance" that they were thinking of migrating to. This client was looking at purchasing these units in bulk, but wanted a third-party evaluation done before they jumped ship from their main firewall vendor. Within three days of our team banging on the units, we discovered that, not only were we able to format the entire box through the Web administration interface, but the units that the vendor had shipped us had pirated copies of a popular graphics package stored on the hard drive. (Whoops.) Sometimes "too good to be true," is, well, too good to be true.
Before you buy a firewall, you should seriously research your own network, your users, and their needs. You should also generate a visual representation of the connections that will be traveling through your firewall and document those findings. Not only will this help you with your requirement gathering, it will leave a paper trail detailing why certain openings were made, and what processes and people were behind those openings. Should anything come into question years from now, you (or your successor) will have something to turn to for help.
There are five primary steps you must take when building a firewall:
1. Identify your topology, application, and protocol needs.
2. Analyze trust relationships and communication paths in your organization.
3. Evaluate and choose a firewall product.
4. Plan and deploy the firewall correctly.
5. Test your firewall policies stringently.
Identifying Topology, Application, and Protocol Needs
Your first step is to identify your topology, application, and protocol needs. This step is more difficult than it sounds, depending on the size and composition of your network. If you run one of the few homogenous networks in existence and only need to support basic protocols (SMTP, HTTP, FTP, and so on) you are in luck. The task ahead of you is pretty easy.
But if you are like the majority of the organizations out there, you need to support a mix of platforms, protocols, and applications. Although this might appear to be easy, this can get messy really quickly. For example, your application developers might say, "We just need access to the Lotus Notes servers from the Internet." Sounds simple enough, right? Well, let's dig a bit deeper. What kind of access? "Well, we need to replicate data to our suppliers, and we need to be able to use the Lotus Notes clients remotely."
Whoa! That's a little more in depth then just "accessing Notes." It sounds as though we might need to support the ports related to the Notes clients (TCP port 1352). We will need to support the ports relating to the replication process, if the developers want to access anything via the Web interface. Plus, we'll need to support HTTP (usually over port 80), and what about remote management?
"Oh yeah, we'll be using PCAnywhere to manage the servers remotely."
Yuck! Okay, you see where I'm going with this: Simple requests can turn out to be more complex then they initially seem. Plan accordingly! You will need to dig deep into your organization, and make sure you talk to everyone who will be using/depending on this firewall.
Although it smells like a CYA (Cover Your Ass) move, when going through requirement-gathering phases, it's a good idea to be as loud and as encompassing as possible within your organization. That way, if a user or project team approaches you after the firewall deployment with some bizarre need or functionality requirement, you have some room to stand your ground on why the function wasn't built into the deployed model. "Why didn't you inform me of this during my requirement-gathering phase?" You might be surprised at how much room this tactic can give you to breathe.
Companies focused on e-commerce sometimes separate their product network from that of their internal LAN-based network services. For example, let's say that you're building a new e-commerce site selling the new integrated PCS-enabled toaster/coffeemaker combos. You'll want 24x7 Web server farms, 24x7 payment processing gateways (often called merchant gateways), possible email servers, and needed support systems (application servers, database servers, and so on). Now, you will most likely want to separate these mission-critical 24x7 systems from less critical day-to-day internal systems, such as the internal email SMTP gateway, the internal FTP sites, the proxy servers, and so on. This quickly becomes a topology issue: How many interfaces will your firewall need to support this configuration? Better yet, how many firewalls will you need? Do you need hot-standby functionality? Will your firewall need to support extended high-availability (HA) protocols such as HSRP and VRRP?
Better to ask these questions beforehand then to get stuck with a solution that won't scale.
Analyze Trust Relationships and Communication Paths in Your Organization
Just as it's important to understand applications and protocols heading outbound from your organization, you also need to take the time to understand internal, or "inbound" processes as well. This is important for a number of reasons. First, in the end, the applications you are supporting have to work. If you move the middle-tier (the application servers) of your three-tier e-commerce solution to your firewalled segment, and the servers become cut off from their database counterparts, you'll have a lot of angry users on your hands (and a broken application). At the same time, if a server that is "Internet exposed" has free, unrestricted access to your internal networks and infrastructure, you have a potential security nightmare on your hands if that machine is ever compromised by a hostile intruder.
Again, this is more up-front investigative work you need to perform. This might involve discussions with individual departments. Certain network segments might need to access one another's resources. To prevent total disruption of your current system, it's wise to perform a detailed analysis of these relationships first.
Throughout this process, use considerable tact. You might encounter users or managers who insist, "We've been doing it this way for 10 years now." You have to work with these people. It's not necessary that they understand the process in full. However, if your security practices are going to heavily impact their work environment, you should explain why. This is also an area where up-front policy creation helps if there are defined, ratified policies in place before going into potential conflicts, your chances of coming out of meetings unscarred greatly increase. Managers tend to avoid monkeying with policies that have been ratified "by above."
Evaluate and Choose a Firewall Product
Next, based on what you discover about your network and those who use it, you need to evaluate and decide on a firewall product. Before conducting purchasing research, you should generate a list of must-haves. You'll ultimately base your purchasing decision on this list. Now, the preferred way of handling the next step is to get your top firewall choices into a lab to do some testing. However, not everyone has a test lab and a few extra weeks to play with cool security products. If you do, enjoy it for those of us who don't!
The next best thing is to get a product demo, visit someone who does have a lab, or ask your vendor for suggestions on how you can see the product in a live environment. If your vendor is good, they'll most likely be able to help you out. Common criteria most people use in deciding on a firewall include
Capacity. Can the firewall support the throughput that you estimate? Does it have room to scale? Typically, if you are talking speeds of T3 (45Mbps) or less, almost any firewall will work.
Features. Although we talked about the problems of feature bloat earlier, features still count. Make sure your firewall can do what you need it to do. However, be realistic with what you are going to use it for. If you aren't going to manage your toaster with it, you don't really need that feature.
Administrative interface. You've got to live with this thing. If you aren't comfortable with the interface, or if you don't understand the interface, chances are you might mess it up. Avoid pilot-error go with something you like.
Price. Okay, who are we kidding? This is always a factor. Although many people have traditionally opted to go the route of CheckPoint FW-1, often times even a basic deployment of FW-1 is intense on the pocketbook, costing 5 to 10 times as much as other products. Take a look at all your options; sometimes the second-best will still enable you to be just as secure for a lot cheaper.
Reputation. Has the vendor typically been responsive to product vulnerabilities? What's the product's track record? Does it have a deployed user base, or is it a recent addition to the scene?
Also, consider looking at independent testing labs and respected technical, testing-oriented trade magazines for other sources of information.
Network Computing magazine tests firewall products a few times a year, and usually does a fairly good job in their reviews. Check out http://www.nwc.com for more information.
Deploying and Testing Your Firewall
Finally, after you've purchased your firewall, you'll put your research to good use by implementing your firewall and its supporting rule set(s). First, make sure that the firewall itself is secured. If the unit is an appliance, chances are there is little outside of changing default passwords that you'll need to do to harden the unit. However, if it is an NT- or UNIX-based firewall, make sure that the OS on which you deploy the firewall software is properly hardened. (See Chapter 19, "Microsoft;" Chapter 20, "UNIX;" and Chapter 21, "Novell," for more infor mation).
The next step is to put your new firewall into your production environment. If this is planned properly, and in the right environment, you might even be able to transition the firewall into the production environment by moving one server at a time behind it. However, often times it is not this easy. Expect at least a few problems, and also budget some time for network down time. (Also, be prepared to field some fairly angry users.) It is extremely unlikely that you'll get it right the first time. That is, unless your network environment is extremely simple, or you are a rule set wizard. If you get it right on the first try, congratulations you are one of the few! Otherwise, join the ranks of the rest of us, and don't be too hard on yourself. This stuff isn't rocket science, but it's not Tinker toy construction, either.
Finally, you'll need to test your rule sets. For this, I recommend extensive test runs. There are really two phases:
Testing the rule set from the outside
Testing the rule set from the inside
Consider using the NMAP tool to take snapshots of your network from an internal perspective (inside the firewall), and from an external perspective (outside the firewall). Make sure the external view is in line with what you expect.
Above all else, remember DEFAULT DENY should be your mindset. If you don't know what it is, don't allow it through your firewall. Better to struggle through learning about protocols and application dependencies than to unknowingly open huge holes into your enterprise. Think minimalist.
People often make the mistake of "firing and forgetting" with their firewalls. They deploy them, they test them, and then they forget about them. One of the top things you should look to implement after your firewall deployment is a process for reviewing your firewall logs. Not only will this help you identify potential problems and trends with your configuration, it will help you get an advanced warning of who is at your doorstep. If any potential intruders come around to rattle your doorknobs, your firewall logs will be the first place where you'll spot them. Use your logs they are your friend.