Next , Use the Right Firewall
There never was much truth in the axiom "We're secure, our firewall will protect us!" For too long, many people have believed that a single firewall between their network and the world is all they needed. In the modern world of interconnected everythingwhere most connections are anonymous, port numbers are meaningless, and much traffic is encryptedit's utter fantasy that just having a single basic firewall at the edge will protect a network and all of its computers.
Firewalls do nothing to prevent attacks from the inside. And firewalls are powerless to stop attacks or prevent unauthorized information disclosure when such attacks or disclosure occur inside encrypted channelsor even in clear text over open ports that basic firewalls allow through. Firewalls are also powerless against people who accidentally or intentionally install worms or viruses, against administrators who use weak passwords, or against attackers returning to networks they've already penetrated. And they are particularly powerless against poor configurations. Amazingly, some people say things such as "block foo at your firewall." This is precisely the incorrect way to design your firewall ruleset: for you can never know all the bad stuff! Firewalls should block everything and permit only that traffic for which you've identified a business need.
Understand this: firewalls are still crucial components of any security architecture. But to remain useful, firewalls must evolve beyond simple header-checking packet filters and beyond a "thing" at the edge of the network. Good firewalls that block real attacks must examine the entire payload of every packet. Furthermore, "firewalling" must now become an idea, a defensive tactic that's deployed pervasively throughout a network. Depending on business need, you might separate some groups from others with internal firewalls. Later in the book, we discuss the critical importance of every computer in a network running its own host-based firewall.
Much has been written about the arrival, evolution, purpose, and ( occasional ) demise of firewalls. Every firewall book, it seems, favors its own classification of firewall products. Let this book be no exception: we present two simple categories, because every firewall is either one or the other or both.
Packet-filtering firewalls examine only the IP and the TCP or UDP packet headers. They can be simple or stateful.
Simple packet-filtering firewalls examine the IP header and the next protocol (TCP or UDP) header of each packet, compare the headers to a rulebase, and either permit the packet to pass or block it. Rules operate in one direction only, so a rule that allows outbound access requires a mirror rule that allows inbound access to permit replies to enter the network. Because simple packet filters don't keep track of sessions or flows, and some don't track sequence numbers, they are relatively easy to circumvent for certain kinds of attackespecially those exploiting application vulnerabilities.
Stateful packet-filtering firewalls also examine IP and TCP/UDP headers. But these firewalls are a little smarterthey understand IP, TCP, and UDP, and can watch as connections get set up. If a client behind the firewall accesses a Web server on the outside, the firewall opens a dynamic inbound filter that allows reply traffic from the server to return to the client. Other inbound traffic is blocked. Stateful packet filters also track sequence numbers in TCP flows for additional connection awareness. Stateful packet filters don't need mirror rules because reply traffic is always permitted by the dynamic filters created as necessary.
Simple packet-filtering firewalls examine traffic at the protocol level, making decisions based on header information only. If a rule permits traffic over a particular protocol and port, the rule nondiscriminately permits all traffic over that protocol and port. Simple packet filters have no way of analyzing the payload to determine whether it makes sense given the characteristics of the protocolthey remain blissfully unaware of the content flowing through them.
Stateful-inspection firewalls don't provide much additional security. A stateful inspection firewall would block unsolicited inbound traffic sourced from port 80 because there's no corresponding initial outbound connection request, but wouldn't block an attack delivered over a Trojan on the inside if that Trojan makes the initial connection. Just because a packet header says "source port 80," there's no guarantee that contained within is benign Web traffic.
Here's another limitation. In a typical corporate environment, outbound requests with port 80 as the destination are usually small, while the returned information is quite large. This describes typical Web surfing behavior. If an attacker successfully convinced a user to install HTTPtunnel,  thereby exploiting the open port 80 to move private data out of the network, the traffic patterns would reverse. No simple firewall can sense that this is a problem.
Application firewalls are aware of the expected protocol format of the application data flowing through them. They examine the traffic according to various rules and make intelligent decisions about what is expected and acceptable. For example, an HTTP application filter knows how a browser-to-server session is set up, what legitimate HTTP and HTML traffic should look like, and can even control which HTTP verbs are and aren't allowed. Such fine-grained knowledge of HTTP is becoming necessary as HTTP evolves into the next universal transport. (SOAP requires HTTP; RPC, DCOM, and some VPNs can run over HTTP.)
Application-filtering firewalls are usually implemented as proxies. Proxies disallow direct IP connections between nodes. Proxies behave like both clients and serversfrom the point of view of a client, the proxy is the server; from the point of view of a server, the proxy is the client. Neither the client nor the server knows that a proxy has interposed itself, accepting traffic from one, evaluating it, repackaging it, and delivering it to the other.
Proxies also help solve the encryption versus inspection dilemma. When people want to "secure" something, at times they might mean they want to inspect everything passing between two peers; at other times, they might mean they want to keep the communications private to avoid eavesdropping. These two goals, both certainly within the realm of "security," are in fact at odds with each other! How can you inspect that which you want to keep completely private? If the proxy knows how to terminate an encrypted session, inspect the cleartext payload for protocol and application conformance, and then re-encrypt before passing the traffic on, you've achieved an interesting combination of these two opposing goals while preserving a nearly complete private channel. The only time the traffic isn't private is while it's in the memory of the proxy computer. So as you would expect, then, like domain controllers, physical security of application proxy firewalls is of paramount importance.
But not all proxies are application-filtering firewalls. Some proxies skip the "evaluate it" step and simply accept packets, drop the original headers, repackage the payload in new packets, and send them on for delivery. Such " circuit-level " proxies, such as SOCKS v4 and v5,  provide a bit more security than packet filters because they present a level of indirection between the client and the serverdirect connections are disallowed , thwarting attacks that use illegal header formats. Most application firewalls have a "generic proxy" mode for traffic they can't process with an application-aware filter.
However, circuit-level proxies and generic proxy modes are, at best, temporary measures that can help you pass traffic when you absolutely need to and there is no application-aware filter. Because they can't really examine everything coming in, they provide little additional protection over packet-filtering firewalls.
In the introduction to RFC 1928 (which defines SOCKS v5), written way back in 1996, there's an acknowledgement of the importance of application-aware proxies:
Some of the first firewall-like devices were proxies designed for specific protocols like the ones mentionedtelnet, FTP, SMTP. What's scary is that packet-filtering firewalls began increasing in popularity at about the same time protocols began increasing in complexity; many people believed that it was better just to invent a kind of "firewall bypass" mechanism than to invest in advanced proxies for sophisticated protocols. Consider the very next sentence in the introductory paragraph of RFC 1928:
Look: SOCKS's stated purpose is to "transparently traverse a firewall"! Securely in the quote above means only that SOCKS v5 incorporates a mechanism for optional authentication of clients to SOCKS proxies.  There is absolutely no protocol awareness in SOCKS at all.
Let your border router handle the only header-based inspection that makes sense these days: the five rules previously listed. All your firewalls behind the router and within your network should be true application proxies that understand all the protocols you need to pass. Now you might be wondering about performance. Application filters, because they are doing more work, are a little slower than packet filters. It takes more time to inspect 1500 bytes per packet than to inspect just 40. But (perceived  ) poor performance is no longer an excuse for not using application firewalls. Understand this: it's now possible to deliver any payload over any port and any protocol. Packet-filtering firewalls of any kind have reached the end of their useful lifetimes. For the reasons we mentioned earlierports don't indicate intent, payloads can be anythingmodern networks require modern firewalls that reach inside the traffic, examine the payload, and make decisions based on the contentnot just the envelopeof every packet entering the network.
Hardware or Software? And One Brand or Two?
Hardware firewalls are all the rage these days. Even ISA Server now comes as a " hardened appliance"not quite a hardware firewall, but similar in that it's a lot more plug and play than building your own Windows server and ISA Server from scratch.  But before you rush out and buy the latest hardware firewall gizmo basking in glowing accolades from the press, stop and think for a moment.
All hardware firewalls still run software in their heartsit just happens to be burned into ASICs instead of loaded from hard drives . Software, regardless of its form, has vulnerabilities. It can be pretty difficult to patch hardware firewalls because the vendors are slow to release patches and the patches can be challenging to install. Software firewalls running on general-purpose operating systems are much easier to keep up-to-date because your staff is already familiar with the underlying operating system and you can incorporate the firewall into your standard systems management discipline. Software firewalls allow you to use standard equipment from the hardware vendors you prefer to do business withor easily change the vendor should you decide to do so. Furthermore, you can repurpose the hardware investments you make if you decide to upgrade or replace them; and the costs of that hardware plus the software is almost always cheaper than that of dedicated hardware-based firewalls.
It's true that a single hardware firewall performs faster than a single software firewall. Again, however, that single hardware firewall costs a lot of money. For less money, you could invest in several 1U rack-mount servers, Windows licenses, and ISA Server licenses and build a firewall farm that gives you more bandwidth, load balancing, and high availability. Built in to Windows Server 2003 Enterprise Edition and ISA Server 2004 Enterprise Edition is everything you need: no additional load-balancing software or hardware is necessary.
The other oft-repeated mantra is to use two different brands of firewalls under the assumption that a vulnerability present in one that might allow an attacker to penetrate part of your network won't be present in another, and therefore constrain the attacker to that part. This is hardly true in the real world! Remember in Chapter 5, "Educating Those Pesky Users," we discussed the three kinds of vulnerabilities: code, configuration, and circumvention? We've spent a lot of time with many different customers in all kinds of networks, and by far configuration vulnerabilities outnumber the other two. Often these are the result of poorly trained staff having to manage network devices they don't know much about.
We challenge you to find, attract , and retain one of the ten people on the planet who know everything about two or more firewalls. You'll need tremendous searching skills, hugemongous amounts of money, and over-the-top benefits and perks. Because that's nigh impossible , don't subject your staff to the confusing and destabilizing environment of multiple firewalls vendors. Best-of-breed sounds mighty attractive when you read about idealized environments in test labs populated by people whose only jobs are to know everything. But in the real world, limit what your staff needs to understand by limiting your choices of products. Let them become absolute experts on a single productespecially one with a strong, thriving user community  that you use in multiple locations. They'll keep it up-to-date against the latest threats and vulnerabilities, make very few configuration mistakes, and generally be happier people.