Chapter 10. Firewalls

Security is a process, not a product.

—Bruce Schneier, Counterpane Labs

IN THIS CHAPTER

·        What Is a Firewall?

·        Other Features Found in Firewall Products

·        Firewalls Are Not Bulletproof

·        A Look Under the Hood of Firewalling Products

·        Pitfalls of Firewalling

·        Firewall Appliances

·        Building Firewalls in the Real World

·        Sample Failures of Firewall Technology

·        Building a Firewall with the Firewall Toolkit (FWTK)

·        Commercial Firewalls

This chapter covers firewalls, what they are, how they work, and who makes them.

Firewalls have been around for years, and now serve as pillars for the information security strategies of most organizations. Although firewalls are fundamentally very important, any organization that relies entirely upon a firewall to fulfill its security needs does so foolishly. Firewalls are not bulletproof. In fact, recently many of the most popular firewall platforms have fallen victim to some of the problems that have long plagued operating systems and applications. Buyers, beware!

Although parts of this chapter will be familiar territory to veteran administrators, some of the material presented here might be new ground. We will investigate what firewalls are, what they do, and more importantly, what they do not do. At the end of this chapter, the reader will understand the basics of firewalling, where and why it can be useful, how to do further research on the subject, and where the "We have a firewall—we are safe" philosophy falls flat on its face.

What Is a Firewall?

A firewall can be any device used as a network-level access control mechanism for a particular network or set of networks. In most cases, firewalls are used to prevent outsiders from accessing an internal network. However, firewalls can also be used to create more secure pockets within internal LANs for highly sensitive functions such payroll, payment processing, and R&D systems. They are not limited to perimeter use exclusively. The firewall devices themselves are typically standalone computers, routers, or firewall "appliances." Firewall appliances are usually proprietary hardware devices often running a custom or proprietary OS. The Cisco PIX series is a good example of a firewall appliance.

Firewalls are designed to serve as control points to and from your network. They evaluate connection requests as they are received. Firewalls check whether or not the network traffic should be allowed, based on a predefined set of rules or "policies." Only connection requests from authorized hosts to authorized destinations are processed; the remaining connection requests are discarded.

Note

As high-speed, residential Internet service continues to make its way into the world, organizations will be forced to face the growing issues surrounding the remote user. Forward-thinking security officers should begin looking at the adoption of "personal firewalls" now, to help address this growing threat. Although they are relatively new, products by Network Associates, InfoExpress, and F-Secure (and other vendors) will become more critical in defending external assets.

Most firewalls accomplish this by screening the source and destination addresses along with port numbers. For example, if you don't want folks from http://www.mcp.com connecting to your FTP site (via FTP), you can bar their access by blocking connection requests from 206.246.131.227 to your FTP site's address (ftp.yoursite.example) on port 21. On their end, the mcp.com folks see a message that reports "Connection Refused" or something similar (or they might receive no notice at all; their connection attempts might simply be blocked).

Other Features Found in Firewall Products

Firewalls can analyze incoming packets of various protocols. Based upon that analysis, a firewall can undertake various actions. Firewalls are therefore capable of performing conditional evaluations. ("If this type of packet is encountered, I will do this.")

These conditional constructs are called rules. Generally, when you erect a firewall, you furnish it with rules that mirror access policies in your own organization. For example, suppose you had both accounting and sales departments. Company policy demands that only the sales department should have access to your FTP site. To enforce this policy, you provide your firewall with a rule; in this case, the rule is that connection requests from accounting to your FTP site are denied.

In this respect, firewalls are to networks what user privilege schemes are to operating systems. For example, Windows NT enables you to specify which users can access a given file or directory. This is discretionary access control at the operating-system level. Similarly, firewalls enable you to apply such access control to your networked workstations and your Web site.

However, access screening is only a part of what modern firewalls can do. Over the past two years, firewall vendors have begun implementing the "kitchen sink" approach to feature development—that is, many vendors have been tossing every feature BUT the kitchen sink into their firewall offerings. Some of the added features include

·        Content filtering. Some organizations want to stop their users from browsing particular Web sites: Web-based email sites, "underground" sites, day trading gateways, sites with pornography, and so on. Content filtering features and services can help block these sites, as well as protect against some types of ActiveX and Java-based hostile code and applets.

·        Virtual Private Networking (VPN). VPNs are used to tunnel traffic securely from point A to point B, usually over hostile networks (such as the Internet). Although there is a wide range of dedicated VPN appliances on the market today, vendors such as Checkpoint and Cisco are happily rolling VPN services into their firewall offerings. Many firewall products now offer both client-to-enterprise VPN functionality, as well as LAN-to-LAN functionality.

·        Network Address Translation (NAT). Network address translation is often used for mapping illegal or reserved address blocks (see RFC 1918) to valid ones (for example, mapping 10.0.100.3 to 206.246.131.227). Although NAT isn't necessarily a security feature, the first NAT devices to show up in corporate environments are usually firewall products.

·        Load Balancing. More of a generic term then anything else, load balancing is the art of segmenting traffic in a distributed manner. Although firewall load balancing is one thing, some firewall products are now supporting features that will help you direct Web and FTP traffic in a distributed manner.

·        Fault Tolerance. Some of the higher-end firewalls like the Cisco PIX and the Nokia/Checkpoint combination support some fairly intricate fail-over features. Often referred to as High-Availability (HA) functionality, advanced fault-tolerance features often allow firewalls to be run in pairs, with one device functioning as a "hot standby" should the other one fail.

·        Intrusion Detection. The term "intrusion detection" can mean many things, but in this case, some vendors are beginning to integrate an entirely different product type with their firewall offering. While this doesn't create a problem in itself, people should be weary of the kind of work load this might impose on their firewall.

Although the thought of managing all these features from within a single box or product can be appealing, one should approach the kitchen sink mentality with a fair amount of skepticism. Firewalls have always been viewed as playing pivotal roles in organizations'security models. Borrowing from the KISS (Keep It Simple, Stupid) principle that is held so dear in the network administration world, we could suggest that going the route of feature bloat might not be the smartest thing to do when it comes to a security product. But we need not speculate on this…the latest round of firewall vulnerabilities have confirmed our suspicions for us. Read on.

Firewalls Are Not Bulletproof

Although vendors like to think their firewall products are immune to the problems that plague operating system and application developers, the fact of the matter is that they are every bit as vulnerable. Consider a sample of some of the issues that have crept up in firewall products:

·        May 1998: It was discovered that Firewall-1 had several reserved keywords that, when used to represent a network object, would open a gaping security hole. (The named object would be interpreted as "undefined," and unless other changes were made, the object would be accessible to any address.) You can better understand this vulnerability (and get a list of those keywords) by downloading http://www.checkpoint.com/techsupport/config/keywords.html.

·        June 1998: It was discovered that the Cisco PIX Private Link uses a small (48-bit) DES key. It's conceivable that this can be cracked. The CIAC reported the following:

PIX Private Link is an optional feature that can be installed in Cisco PIX firewalls. PIX Private Link creates IP virtual private networks over untrusted networks, such as the Internet, using tunnels encrypted with Data Encryption Standard (DES) in ECB ("electronic codebook") mode. An error in parsing of configuration file commands reduces the effective key length for the PIX Private Link DES encryption to 48 bits from the nominal 56 bits. If attackers know the details of the key-parsing error in the PIX Private Link software, they will know 8 bits of the key ahead of time. This reduces the effective key length from the attacker's point of view from 56 to 48 bits. This reduction of the effective key length reduces the work involved in a brute-force attack on the encryption by a factor of 256. That is, knowledgeable attackers can, on the average, find the right key 256 times faster than they would be able to find it with a true 56-bit key.

Cisco found a fix for this problem. Check http://www.cisco.com/warp/public/770/pixkey-pub.shtml for details.

·        July 1999: Problems were discovered in "ipchains," the firewall code found natively in Linux. Remote attackers could use the flaw to send data to supposedly blocked ports. More information can be found here: http://www.securityfocus.com/bid/543.

·        May 2000: A buffer overflow was discovered in Network Associates Gauntlet firewall product that reportedly let intruders execute malicious code on the firewall itself—remotely. It turns out, however, that the bug wasn't part of the original firewall code. Instead, the culprit was introduced through the content filtering (Cyber Patrol) system NAI had acquired and rolled into the Gauntlet product line. Nevertheless, organizations using the newer version of Gauntlet were forced to deal with the problem. You can read the full thread here: http://www.securityfocus.com/bid/1234.

·        June 2000: A denial of service attack using fragmented packets was discovered that could disable all Checkpoint Firewall-1 firewalls. At the time of this writing, there was a workaround available, but the fundamental problem was still not remedied. More information can be found here: http://www.securityfocus.com/bid/1312.

·        June 2000: Another denial of service attack was discovered in CheckPoint FW-1, this one targeting Firewall-1's mail handler. Again, no patch had been released at the time of this writing. More information can be found here: http://www.securityfocus.com/bid/1416.

·        July 2000: During the Black Hat briefings, two well-known security researchers, John McDonald and Thomas Lopatic, reported a number of vulnerabilities they found in Checkpoint's Firewall-1 product. (See it at http://www.dataprotect.com/bh2000/blackhat-fw1.html.) This was significant, as Checkpoint's product is one of the most widely deployed firewalls in the world.

By no means is this list conclusive—this is simply a taste of some of the recent problems discovered in today's firewall products. Also, consider that the some of these issues are directly related to non-core functionality found in firewall products that the vendors have added: content filtering and encapsulation (for VPN use).

It remains to be seen whether the firewall vendors will treat security considerations equally with that of feature additions. However, to the vendors'credit, they claim that most of their clients aren't asking for more security, but rather more features. I present the question to the reader: What do you think is more important in your firewall? Do us all a favor—let your vendor know how you feel.

A Look Under the Hood of Firewalling Products

In the esoteric sense, components of a firewall exist in the mind of the person constructing them. A firewall, at its inception, is a concept rather than a product; it's the idea surrounding the access control mechanism that enables traffic to and from your network.

In the more general sense, a firewall consists of software and hardware. The software can be proprietary, shareware, or freeware. The hardware can be any hardware that supports the software.

Firewall technologies can generally be classified into one of three categories:

·        Packet-filter–based (usually routers, Cisco IOS, and so on)

·        Stateful packet-filter–based (Checkpoint FW-1, PIX, and so on)

·        Proxy-based (NAI Gauntlet, Axent Raptor, and so on)

Let's briefly examine each.

Packet-Filter–Based Firewalls

Packet filtering firewalls are typically routers with packet-filtering capabilities. Using a basic packet-filtering router, you can grant or deny access to your site based on several variables, including

·        Source address

·        Destination address

·        Protocol

·        Port number

Router-based firewalls are popular because they're easily implemented. (You simply plug one in, provide an access control list, and you're done.) Moreover, routers offer an integrated solution. If your network is permanently connected to the Internet, youneed a router anyway. So, why not kill two birds with one stone?

On the other hand, router-based firewalls have several deficiencies. First, they usually aren't prepared to handle certain type of denial of service attacks. Many of the denial of service tactics used on the Internet today are based on packet mangling, SYN flooding, or forcing other TCP/IP-based anomalies. Basic routers aren't designed for handling these types of attacks. Second, most routers can't keep track of session state data. Administrators are forced then to keep all ports above 1024 open in order to handle TCP sessions and session negotiations properly. Although this is arguably not a huge security concern (because there shouldn't be any listening services running on those ports anyway), it's not generally a good practice to leave unused ports open to the outside.

Finally, using ACLs (access control lists) on high-end routers that are supporting extremely busy networks can contribute to performance degradation and higher CPU load. However, for most low-speed connections (such as T1 circuits) on lower-end routers (such as Cisco 2500 series routers), normal packet filtering will not tax the router to any significant degree.

Note

For a long time, it was believed that putting access control lists (ACLs) on routers would greatly degrade their performance. Although sticking a 100 rule ACL on a Cisco 7000 supporting a dozen ATM connections might not be the best of ideas, placing basic ACLs on routers supporting low-speed (10Mbps or lower) connections doesn't usually degrade their performance noticeably. Two members of the underground, rfp and NightAxis, published some basic findings on this subject that can be found at http://www.wiretrip.net/rfp/. Since then, other studies have also been performed (your mileage can vary). Remember, even the low-end Cisco 2500 series routers were based on Motorola 68030 and 68040 chip sets, and the newer ones are using even more advanced RISC-based chips. Routers are more powerful then many people give them credit for. Test it yourself—see what you find.

Tip

Many network administrators will use ACLs on their perimeter routers in conjunction with a more advanced firewall to create a multitier approach to network access control.

Stateful Packet-Filter–Based Firewalls

Stateful packet filtering builds on the packet filtering concept and takes it a few steps further. Firewalls built on this model keep track of sessions and connections in internal state tables, and can therefore react accordingly. Because of this, stateful packet-filtering–based products are more flexible than their pure packet-filtering counterparts. In addition, most stateful packet-filtering–based products are designed to protect against certain types of DoS attacks, and to add protection for SMTP-based mail and an assortment of other security-specific features.

Checkpoint pioneered the technique called "stateful inspection" (SI), which takes stateful packet filtering up one notch. SI enables administrators to build firewall rules to examine the actual data payload, rather then just the addresses and ports.

Note

Because stateful packet-filtering–based firewalls track session states, they can keep the ports above 1024 closed by default and only open the high ports on an as-needed basis. As simple as this might sound, this is why most administrators consider stateful packet filtering to be the minimum technology they will implement for their firewall solutions.

Proxy-Based Firewalls

Another type of firewall is the proxy-based firewall (sometimes referred to as an application gateway or application-proxy). When a remote user contacts a network running a proxy-based firewall, the firewall proxies the connection. With this technique IP packets are not forwarded directly to the internal network. Instead, a type of translation occurs, with the firewall acting as the conduit and interpreter.

How does this differ from stateful packet filtering and generic packet filtering, you ask? Good question—and one that many people ask. Both packet filters and stateful filtering processes examine incoming and outgoing packets at the network and session levels (see Chapter 4, "A Brief Primer on TCP/IP" ). They examine IP source and destination addresses along with ports and status flags, compare them to their rule sets and table information, and then decide whether the packet should be forwarded. Proxy-based firewalls, on the other hand, inspect traffic at the application level in addition to lower levels. A packet comes into the firewall and is handed off to an application-specific proxy, which inspects the validity of the packet and application-level request itself. For example, if a Web request (HTTP) comes into a proxy-based firewall, the data payload containing the HTTP request will be handed to an HTTP-proxy process. An FTP request would be handed to an FTP-proxy process, Telnet to a Telnet proxy process, and so on.

This concept of a protocol-by-protocol approach is more secure then stateful and generic packet filtering because the firewall understands the application protocols themselves (HTTP, FTP, SMTP, POP, and so on). It's more difficult for intruders to sneak past something that is watching more than just the ports and IP addresses. However, notice that I used the word "concept" in reference to it being more secure. The truth of the matter is that in real-world applications, this approach has had its fair share of problems.

Proxy-based firewalls have always been slower then stateful packet-filtering–based ones. Now, for most networks (10Mbps or slower), this difference is moot. However, for heavily loaded networks (T3s at 45Mbps, multiple T3s approaching 100Mbps, and so on), this becomes a much larger issue. As technology improves, the gap might close, but for now the use of pure proxy-based technology is still a concern for high-volume networks.

Note

Network Associates is working on a cross between proxy and stateful packet filtering called "adaptive proxy technology." It remains to be seen how groundbreaking this will truly be, but you can read all about it here: http://www.nai.com/asp_set/buy_try/try/whitepapers.asp

In addition to the performance problem, the proxy-based solution also has some adaptability issues. Suppose, for example, that a new protocol is invented to manage your coffeemakers at home. For the sake of example, we'll call this protocol the Percolation Control System, or PCS for short. Now, let us also assume that PCS uses TCP and runs over port 666. Administrators of stateful packet-filtering–based firewalls will simply have to build a new rule into their firewall allowing traffic over TCP on port 666, and it's a done deal. Administrators of proxy-based firewalls, however, have a new problem: They don't have a proxy (yet) for PCS. It's a brand new protocol. Although some proxy-based firewalls (such as NAI's Gauntlet) have a generic proxy for such problems, now we're back to basic packet filtering, which defeats the purpose of having a proxy to begin with.

However, taking this example one step further, let's say the proxy-based firewall vendor eventually writes a PCS-proxy, and all is well in Coffeeville. Soon after, some mischievous helpdesk contractors resurrect their old copies of network DOOM, which also runs over port 666, and they attempt to start abusing an old addiction. Low-and-behold, network DOOM won't make it through the proxy-based firewall, but it will through the stateful packet-filtering–based one.

We will cover how this can be used maliciously a little later on, but suffice it to say that the proxy-based approach is a little more secure from a theoretical standpoint—but the products based on this approach can also be a big pain in the butt.

Pitfalls of Firewalling

One pitfall in the world of firewalls is that security can be configured so stringently that it can actually impair the process of networking. For example, some studies suggest that the use of a firewall is impractical in environments where users critically depend on distributed applications. Because firewalls can implement such strict security policies, these environments can become bogged down. What they gain in security, they lose in functionality. To some, this might be viewed simply as an inconvenience. However, the problem can bring about long-term effects that are far more damaging. For example, inevitably all administrators face the classic square off between user X who needs to do Y, and the security problems that surround her request. Although the dilemma touches on a number of information security principles, one of the largest being policy definition, it can also cross some organizational boundaries as well. If, for example, the technical staff loses its battle to block service Y, they then run the risk of having an organiza tion-wide precedent set. This can lead to the security personnel getting crushed by the business people, and sooner or later something is opened up on the firewall that really shouldn't be. On the other hand, smart organizations know to examine these situations on a case-by-case basis and act accordingly. Unfortunately, we don't all work for "smart" organizations….

Firewalls can help create sticky situations. The solution is to know how to avoid these situations, and know what to do when you do lose a battle. For example, if some bone-head VP gets the approval to allow third-party access to the payroll system through the Internet, rather then lose sleep over it, consider ways of controlling the damage. Segment the payroll systems onto a separate subnet, look to implement stronger system-level audit logs, work at getting an Intrusion Detection System (IDS) implemented on the questioned segment, and so on. Many times, perceived losses can be turned into long-term victories, if you play your cards right.

Tip

Although users might seem more like pesky annoyances then necessary evils, it's important to remind yourself that the network is there for one reason: connectivity. Although security is an important part of an administrator's responsibility, so is basic usability. At the end of the day if the users can't do their job, we're all going to be in trouble. Good administrators know which battles to fight, and which ones to work on from another angle…

Another more serious issue is that of a perceived and false sense of security. Administrators who are content that their firewalls will protect them from all evils are setting themselves up for a rude awakening. Part of the challenge of deploying a firewall is to help build a feeling of safety without overdoing it. Fun challenge, huh? The reason that this balance is so important is that, without secondary levels of defense, you are placing all your eggs in one basket. If your firewall is broken, your internal networks can easily be destroyed. Firewalls are part of a security model; they shouldn't be the security model because they have their own set of downfalls. Remember, tiered security models are your friend.

There is hope. Five years ago, we were fighting battles with the CIOs to get firewalls in the first place. Now we're fighting battles trying to convince them that just a firewall isn't enough. Hey, at least we're making progress.

Firewall Appliances

The word appliance became all the rage in late 1999 as the term appeared to be universally adopted by marketing departments across the globe. The concept of an appliance is a simple and arguably quite appealing one: a turnkey, integrated hardware/software solution that comes ready to run, securely, out of the box. Traditional firewalls were typically software products that ran on an underlying (mainstream) operating system. Before installing the firewall product, you had to first build and configure the underlying OS as well as secure it. Firewall appliances, on the other hand, offered the lure of "solid-state" technology (meaning "no moving parts"), and highly optimized kernels that could support high levels of packet processing.

Or so the story went. However, it soon became obvious that appliance was not synonymous with solid state, as vendors started shipping appliances that relied on hard drives and hidden operating systems. The talks of high optimization were tainted by people shipping stock BSD kernels and basic firewalling code. Unfortunately, it is probably more accurate to say that the term appliance now defines the difference between something you can kick (a machine in a 2U chassis) and something you can throw (a manual and a CD-ROM).

However, that's not to say that there aren't a lot of good appliance-like firewalls out there. Nokia, for example, took the Checkpoint FW-1 code and ported it to their IPSO operating system (an OS with BSD roots that was optimized for routing) to produce their "IP" series of firewall appliances. The units are quite reliable, and perform extremely well. Cisco has sincemoved the PIX to a solid-state design. Both the Cisco PIX and the Nokia IP series use Intel x86 hardware under the hood. Units like the Netscreen firewalls have always been in a slimline chassis and in appliance form as well.

Should you move to a firewall appliance? It really depends on what your needs are. Some people like the ability to use standard UNIX commands on their firewalls for examining logs, parsing tables, and so on, so using an appliance might stymie them a bit. However, by using a standard OS such as Microsoft Windows NT or Sun Solaris, you do increase the risk of an oversight or misconfiguration. These problems can allow the firewall machine itself to become a vulnerable target. For some, the appliance approach is a little more bulletproof, and appliance performance figures will soon match that of most Sparc-based firewalls, if they haven't already. For others, having the mainstream OS under the hood might be an advantage.

Note

The term solid state originally came from the world of electrical engineering. The term was used in reference to the move from vacuum tubes to transistors. However, the term has recently been bastardized by vendors and marketing departments alike, and is now commonly used to convey the concept of "no moving parts."

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.

Note

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.

Tip

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.

Tip

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.

Tip

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.

Sample Failures of Firewall Technology

Let me first start by saying that this section is not designed to be an all-encompassing view of how firewalls can be circumvented. In fact, quite the opposite. My goal is to simply provide you with clear, simple examples of how firewalls can fail you. I would also argue that these aren't even failures of the firewalls themselves, but rather of their deployers and the expecta tions placed on them.

I assume you are familiar with the tool netcat.

The "Whoops, Where Did My Web Server Go?" Problem

Picture this: You have a stateful packet-filtering–based firewall that allows inbound traffic through port 80 to a single NT-based Web server. That NT Web server is behind the firewall, with most of the more trivial services shut down. (Workstation service, server service, FTP service, Gopher service—all are disabled.) Your perimeter router is secured, and let us also assume that the firewall itself is properly configured and secured.

But somehow, using this configuration, an intruder is able to get administrative shell access, via Telnet, to your protected NT Web server in under two minutes. How is this possible?

Microsoft's Internet Information Server (IIS the Web server used natively on NT) installs a number of nasty sample scripts by default. Combine this with the RDS/MDAC problem (see Chapter 19 for further explanation), and intruders can not only execute commands remotely on the NT server (via standard HTTP requests), they can build FTP scripts. Using RFP's msadc.pl Perl exploit script on a vulnerable Windows NT/IIS installation combined with net cat and the echo command, an intruder can

1.       Create an FTP script that will retrieve a copy of netcat.

2.       Execute that FTP script using msadc.pl and FTP -s -a <scriptname>.

3.       Create a script to shut down the Web server, and bind netcat to port 80 using nc -l -p 80 -e cmd.exe.

4.       Telnet into the Web server (telnet 10.0.0.2 80) over port 80 to connect to an active copy of netcat (see Figure 10.1).

Figure 10.1. Firewall only allowing inbound data through port 80.

So although the configuration appears to be solid, the intruder is sitting there with an administrative shell on your NT machine. What went wrong? Firewalls are not a substitution for end-node security. Even if you deploy the tightest configuration possible on the firewall (short of disconnecting the network), a single open vulnerability on a single end-node can blow your whole model.

Now, a proxy-based firewall would have blocked the netcat shell because the Telnet traffic over port 80 would not have been viewed as valid HTTP requests. However, proxy-based firewalls would not have stopped the RDS/MSADC. It is valid traffic, and the attacker could have altered his or her attack accordingly. However, let's not pick on stateful packet-filtering–based firewalls exclusively.

Note

There is another point to made here: Blocking types of outbound traffic can be a good thing, although few administrators consider doing this. During one penetration test we ran into a savvy admin who had blocked outbound FTP access from his Internet-exposed Web servers. Even though we were able to execute commands on the target machines by manipulating faulty CGI scripts, we were unable to fetch our intrusion tools (such as netcat) via FTP. This slowed us down quite a bit.

Using SSH to Bypass Rule Sets

This scenario is a bit different. Let's say that our network policy prohibits the use of unen crypted POP from outside of the organization because it passes clear-text passwords. Let's assume that using our proxy-based firewall we've blocked external POP access to the organization's POP mail server, which inhibits external users from checking their mail while at home. Let us also assume that we allow the use of SSH (Secure Shell) outbound.

We discover one day that one of our more clever users is checking his mail from home, using POP remotely. Worse, we soon discover that he is doing so across the Internet via his cable-modem attachment. His POP password is now being sent across the Internet in the clear, validating our original concern. So how could this happen with us blocking inbound POP at the firewall?

There is neat little feature found in most SSH clients called "tunneling." Tunneling allows you to seamlessly transport other types of connections through established SSH sessions. In our scenario, this user would initiate an outbound SSH session from within the organization from the UNIX server running POP. He would connect to a server at his ISP, and set up a listening tunnel on the ISP's server on port 1828 that would redirect a session back to the POP server. This tunnel would then enable him to connect to the internal POP server from home, after he modified his POP client to connect on port 1828 (rather then 110) on his ISP's machine. As long as the SSH session remained active, the tunnel would work (see Figure 10.2).

Figure 10.2. Firewall blocking POP (port 110) inbound.

Effectively, our clever user bypassed our rule set. Although the POP request comes in encrypted from the ISP's machine (because it's over the SSH session), its path to the ISP machine is still out in the open. So where did we go wrong? Well, combine the fact that proxy-based firewalls can't "peek" inside of encrypted traffic with the rather useful tunneling feature of SSH, and you have the makings of our little problem. Although naive administrators might be tempted to blame the firewall for this problem, the simple fact of the matter is that firewalls have their weaknesses—blocking SSH inbound tunnels is one of them.

These are just two examples. Trust me, there are many more.

Note

The inability to eavesdrop on encrypted tunnels applies to SSL, as well. In fact, during one of our team's engagements, we found ourselves cut off from email because of the client's restrictive proxy. This proxy, however, allowed outbound SSL. Just for fun one of our team members took putty, an open-source SSH-client, and modified it to tunnel SSH through SSL. Voil[ag]a—we had our email connection, and the firewall admin was none the wiser. Encryption will continue to be both a blessing and a curse to security administrators in years to come.

Building a Firewall with the Firewall Toolkit (FWTK)

Although a bit dated, a good exercise and perfectly feasible firewall solution is to use the TIS Firewall Toolkit (TIS FWTK). TIS was acquired by Network Associates Inc., but the original toolkit has fortunately lived on. The FWTK is based on application proxy-based technology. The package (which is free for noncommercial use) includes proxies for the following services:

·        Telnet

·        FTP

·        Rlogin

·        Sendmail

·        HTTP

·        X Window system

For each such proxy, you must specify rules. You must edit three files to establish your rules:

·        /etc/services. This file is already on your system. It specifies what services your machine will support and what ports those services run on. (Here, you set the ports your proxies will run on.)

·        /etc/inetd.conf. This file is also already on your system. It's the configuration file for inetd. The inetd.conf file specifies what server is activated when outsiders request a particular service. (Here, you specify your proxies, using them to replace the default servers.)

·        /usr/local/etc/netperm-table. This is a FWTK file. In it, you specify who can use the services you provide.

You can use two schemes for permissions:

·        That which is not expressly allowed is denied.

·        That which is not expressly prohibited is allowed.

I recommend the first, which is far more prohibitive.

Granting or denying access with the FWTK is easy. You can apply wide-sweeping masks of addresses and hosts that are denied access. You can use asterisks to indicate an entire range of addresses:

  http-gw:      userid          root

  http-gw:      directory       /somewhere

  http-gw:      timeout 90

  http-gw:      default-httpd   www.myserver.net

  http-gw:      hosts           199.171.0.* -log { read write ftp }

  http-gw:      deny-hosts      *

(http-gw is the proxy for HTTP.)

As you can see, you must configure access rules for each service. This is one of the pitfalls of using application gateways. Another pitfall is that every application session must be proxied. This can be a laborious and cumbersome environment for inside users. (Inside users must also have their outbound traffic proxied. This can represent significant overhead because inbound traffic also has a resource impact on outbound traffic.)

Application gateways are more suitable if you have no outbound traffic—for example, when your site serves clients outside the firewalls with archived information. A typical example is when you have clients who pay a subscription fee to retrieve technical specifications from your server. The technical specifications are sensitive materials, and therefore, only your clients should be able to retrieve them. In this case, an application gateway is perfect.

Application gateways are less suitable for corporations, universities, ISPs, or other environ ments where more fluid communication (and more interfaces with the general public) is required. For example, in such environments, you cannot be certain that users will always connect from specific servers or networks. They might come in from a wide variety of IP addresses. If you're using an application gateway, and you need to authorize a user connection within Netcom, unless that address is static, you must allow everyone from Netcom.

If you haven't yet purchased a firewall (or if you simply want to learn about them), you should get the FWTK. By configuring it and testing your rules, you will learn much about how firewalls work.

Obtain a copy of the TIS Firewall Toolkit at ftp://ftp.tis.com/pub/firewalls/toolkit/README.

The FWTK requires a UNIX system and a C compiler. Moreover, although the FWTK is known to compile on SunOS and BSD without problems, configuration issues exist for Linux. To sort out these problems quickly, there is no better document than Creating a Linux Firewall Using the TIS Toolkit by Benjamin Ewy. That document is located online at http://www2.linuxjournal.com/cgi-bin/frames.pl/lj-issues/issue25/1204.html. Patches for use with the FWTK on Linux are located online at ftp://ftp.tisl.ukans.edu/pub/security/firewalls/fwtkpatches.tgz.

Note

Another more generic proxy-based technology is SOCKS. SOCKS has great significance because it is well established and support for it is already included in many browser packages, most notably Netscape Navigator. A good site for comprehensive coverage of SOCKS technology is http://www.socks.nec.com.

Commercial Firewalls

This next section provides details on firewall vendors, their products, and any special characteristics their firewall might have. I am not recommending these firewalls, but rather simply providing this list as a resource.

BorderManager

BorderManager is the premier firewall for Novell environments, but it will still protect UNIX- and NT-based systems. The product offers centralized management, strong filtering, and high-speed, real-time analysis of network traffic. Also, BorderManager offers the ability to create "mini-firewalls" within your organization to prevent internal attacks from departments or local networks.

Firewall Type: Stateful packet-filter–based

Manufacturer: Novell Inc.

Supported Platform: Novell NetWare

Further Information:

http://www.novell.com/products/bordermanager/index.html

FireBOX

Firewall Type: Stateful packet-filter based

Manufacturer: Watchguard

Supported Platform: UNIX

Further Information: http://www.watchguard.com

Firewall-1

Checkpoint's Firewall-1 is one of the most frequently deployed firewalls in the industry today. The product features packet filtering, strong content screening, integrated protection against spoofing, VPN options, real-time scanning for viruses, and a wide assortment of other features. It is one of the most feature-rich firewalls out there, but is also one of the most expensive.

Firewall Type: Stateful inspection-based

Manufacturer: Check Point Software Technologies Ltd.

Supported Platforms: Windows NT and UNIX

Further Information: http://www.checkpoint.com/

FireWall Server

Firewall Type: Proxy-based

Manufacturer: BorderWare

Supported Platforms: Custom (proprietary OS running on Intel hardware)

Further Information: http://www.borderware.com

Gauntlet Internet Firewall

Remember the TIS FWTK? It originally formed the basis for Gauntlet. The latest release of Gauntlet offers a hybrid application-proxy and packet-filtering approach, along with VPN, content filtering, and virus scanning features.

Firewall Type: Hybrid Proxy-based with stateful packet filters

Manufacturer: Network Associates

Supported Platforms: UNIX, Windows NT, DMS, ITSEC E3, and IRIX

Further Information: http://www.nai.com/asp_set/products/introduction/default.asp

GNAT Box Firewall

GNAT is a firewall appliance. You can manage the GNAT box with either a command-line or Web-based interface. GNAT filters incoming traffic based on IP source address, destination address, port, network interface, and protocol.

Firewall Type: Stateful packet-filter based

Manufacturer: Global Technology Associates

Supported Platforms: N/A (appliance)

Further Information: http://www.gnatbox.com/

Guardian

Guardian is an NT-based firewall.

Firewall Type: Stateful packet-filter based

Manufacturer: NetGuard Inc.

Supported Platform: Windows NT

Further Information: http://www.netguard.com

NetScreen

NetScreen is a firewall appliance that supports IPSEC, DES, and triple DES encryption.

Firewall Type: Stateful packet-filter–based

Manufacturer: NetScreen Technologies Inc.

Supported Platforms: N/A (Appliance)

Further Information: http://www.netscreen.com/

PIX Firewall

The PIX, along with Firewall-1, are the two most widely deployed firewall products today. The PIX is a firewall appliance that is devoid of any moving parts. It supports IPSEC, and can be administered through Telnet or SSH sessions, or through the Cisco Security Policy Manager (CSPM) framework product.

Firewall Type: Stateful packet-filter–based

Manufacturer: Cisco Systems Inc.

Supported Platforms: N/A (Appliance)

Further Information: http://www.cisco.com/warp/public/751/pix/

Raptor Firewall

Firewall Type: Proxy-based

Manufacturer: Axent

Supported Platforms: Solaris and Windows NT

Further Information: http://www.raptor.com/products/datasheets/prodsheet.html

SideWinder

Firewall Type: Proxy-based

Manufacturer: Secure Computing

Supported Platform: UNIX (custom build, however, ships with the product)

Further Information: http://www.securecomputing.com

Sonicwall

Firewall Type: Stateful packet-filter based

Manufacturer: SonicSystems

Supported Platforms: N/A (appliance)

Further Information: http://www.sonicwall.com

Summary

Firewalls are not bulletproof. Anyone relying on them for the majority of their security is setting themselves up for a nasty fall. However, in many cases, firewalls are quite necessary and can prove to be very useful. A firewall's success depends on the proper utilization of feature sets, proper configuration, and proper monitoring. As with any security product, testing it before purchasing it is key. If you can test them yourself, great; otherwise look to third parties and industry-recognized security sources for further information.

Books and Publications

Internet Firewalls and Network Security (Second Edition).ChrisHare and KaranjitSiyan. New Riders. 1-56205-632-8. 1996.

Internet Firewalls. ScottFuller and KevinPagan. Ventana Communications Group Inc. 1-56604-506-1. 1997.

Building Internet Firewalls. D.Brent Chapman and Elizabeth D.Zwicky. O'Reilly & Associates. 1-56592-124-0. 1995.

Firewalls and Internet Security: Repelling the Wily Hacker. WilliamR. Cheswick and Steven M.Bellovin. Addison-Wesley Professional Computing. 0-201-63357-4. 1994.

Actually Useful Internet Security Techniques. LarryJ.Hughes, Jr. New Riders. 1-56205-508-9. 1995.

Internet Security Resource Library: Internet Firewalls and Network Security, Internet Security Techniques, Implementing Internet Security. New Riders. 1-56205-506-2. 1995.

Network Firewalls. StevenM. Bellovin and William R.Cheswick. IEEECM, 32(9), pp. 50–57, September 1994.

Session-Layer Encryption. MattBlaze and SteveBellovin. Proceedings of the Usenix Security Workshop, June 1995.

IP v6 Release and Firewalls. UweEllermann. 14th Worldwide Congress on Computer and Communications Security. Protection, pp. 341–354, June 1996.

Internet Resources

Firewalls FAQ. http://www.faqs.org/faqs/firewalls-faq

There Be Dragons. Steven M. Bellovin. Proceedings of the Third Usenix UNIX Security Symposium, Baltimore, September 1992. AT&T Bell Laboratories, Murray Hill, NJ. August 15, 1992. http://www.zeuros.co.uk/generic/resource/firewall/papers.htm

Keeping your site comfortably secure: An Introduction to Internet Firewalls. John P. Wack and Lisa J. Carnahan. National Institute of Standards and Technology. http://csrc.ncsl.nist.gov/nistpubs/800-10/

SQL*Net and Firewalls. David Sidwell and Oracle Corporation. http://www.zeuros.co.uk/generic/resource/firewall/papers.htm

Covert Channels in the TCP/IP Protocol Suite. Craig Rowland. Rotherwick & Psionics Software Systems Inc. http://csrc.ncsl.nist.gov/nistpubs/800-10.ps

A Network Perimeter with Secure External Access. Frederick M. Avolio and Marcus J. Ranum. A paper that details the implementation of a firewall purportedly at the White House. http://www.alw.nih.gov/Security/FIRST/papers/firewall/isoc94.ps

Packets Found on an Internet. Steven M. Bellovin. Lambda. Interesting analysis of packets appearing at the application gateway of AT&T. ftp://ftp.research.att.com/dist/smb/packets.ps

X Through the Firewall, and Other Application Relays. Treese/Wolman. Digital Equipment Corp. Cambridge Research Lab. ftp://crl.dec.com/pub/DEC/CRL/tech-reports/93.10.ps.Z

Benchmarking Methodology for Network Interconnect Devices (RFC 1944). S. Bradner and J. McQuaid. http://archives.neohapsis.com/archives/rfcs/rfc1944.txt