IN THIS CHAPTER
Security is a process, not a product. | ||
| --Bruce Schneier, Counterpane Labs | ||
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, you’ll 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.
A firewall is 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 as 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. 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 McAfee, InfoExpress, F-Secure, and other vendors will become more critical in defending external assets. VPN access is another choice for remote users.
Most firewalls accomplish this by screening the source and destination addresses along with port numbers. For example, if you don’t want folks from www.samspublishing.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 samspublishing.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).
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 the accounting department 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. In recent 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. Finally, content filtering can do some antivirus screening, though it’s still a good idea to have an antivirus product on PCs and email servers.
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 have rolled 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.3to206.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. Although this doesn’t create a problem in itself, people should be wary of the kind of workload this might impose on their firewall. Also, it creates a single point of failure from a security point of view.
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 organizational 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.
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:
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.
June 2001: Cisco IOS was found to have a security hole whereby a cracker could execute privileged commands via the built-in HHTP server. Read more at http://www.cisco.com/warp/public/707/IOS-httplevel-pub.html.
July 2001: Check Point Firewall-1 and VPN-1 had a vulnerability in which crackers could pass their traffic into and out of networks when they should not have been able to. Find out more at http://www.computerworld.com/securitytopics/security/firewall/story/0,10801,62218,00.html.
October 2001: Cisco had to replace many PIX firewalls at customer sites because they would hang or shutdown because of hardware flaws. Have a look at http://www.computerworld.com/securitytopics/security/firewall/story/0,10801,65363,00.html.
August 2002: Symantec’s Raptor firewall had a problem in which a cracker could hijack sessions passing through the firewall. Read more about it at http://www.eweek.com/article2/0,3959,436818,00.asp.
This list is by no means conclusive—it’s 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 functionalities 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.
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
Let’s briefly examine each.
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, you’ll need 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 types 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, though enterprise class routers can usually deal with them. Second, some low-end routers can’t keep track of session state data though that is discussed more in the stateful section below. Administrators are then forced to keep all ports above 1024 open to handle TCP sessions and session negotiations properly. 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 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://packetstormsecurity.nl/papers/contest/RFP.txt. Since then, other studies have also been performed (your mileage may 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 than 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 multi-tier approach to network access control.
Another type of packet filter firewall that has become popular over the past couple of years is the personal firewall. The personal firewall protects only one machine instead of a whole network. This makes it appropriate for home use, or even corporate environments, where certain machines need added security.
Personal firewalls are loaded on whatever computer is being protected, and the personal firewall software will then monitor all incoming connections. It will accept, reject, or ask the user to decide what to do.
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. These firewalls can detect anomalous situations that violate protocol standards that a plain packet filter cannot. This allows the stateful firewall to block attacks that a packet filter might miss. 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 than 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.
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 levels (see Chapter 6, “A Brief TCP/IP Primer”). They examine IP source and destination addresses along with ports and status flags, compare them to their rulesets 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). The firewall will reject anything that does not match the protocol specs. 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 than 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.
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. We’ll call this protocol the Percolation Control System, or PCS for short. Now, let’s 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 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 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.
Many corporate programmers have been tasked with exchanging data with partners and customers. In the old days before firewalls were common, they might have just written socket-based programs that made a direct connection. With firewalls in place, they are unable to do this. Therefore, they figured out ways to bypass the firewall by using HTTP as their new transport protocol.
You might think that HTTP is harmless because it’s just serving up documents, right? Wrong—protocols such as SOAP (Simple Object Access Protocol) enable remote access to function calls via HTTP. The Web page http://www.xmlhack.com/read.php?item=630 contains an excellent discussion of SOAP’s “firewall-penetrating” abilities.
Security firewalls that deal with SOAP and other such technologies are brand-new. One such solution is Quadrasis’ SOAP Content Inspector, which can be found at http://www.quadrasis.com/solutions/products/easi_product_packages/easi_soap.htm. The integration of this kind of technology into traditional firewalls is at least a couple of years down the road.
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 run the risk of having an organization-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 what to do when you do lose a battle. For example, if some bonehead 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 than 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 why 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.
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.
Since that time, the firewall appliance has really caught on in the small networking environment. Dozens of vendors have firewall appliance boxes on the market. They tend to be easy to configure and easy to deploy, especially for people who are less than security experts. The default configuration often forbids inbound connections, but allows any outbound connections. This is what most home users want and need.
Should you move to a firewall appliance? It really depends on what your needs are. Some people like the capability 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 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.”
“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:
Understand that firewall platforms change—there is no superior firewall platform. For example, Vendor X might have its head in the clouds for a few revisions, and then get its act together for the next version of the product. By the same token, Vendor Y and Vendor Z 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.
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? All too often, people get caught up in extreme benchmarking numbers 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.
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.
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 jumping 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:
Identify your topology, application, and protocol needs.
Analyze trust relationships and communication paths in your organization.
Evaluate and choose a firewall product.
Plan and deploy the firewall correctly.
Test your firewall policies stringently.
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, it can quickly get messy. 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 than they initially seem and might defeat the purpose of the firewall to begin with. 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 24×7 Web server farms, 24×7 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 24×7 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 than to get stuck with a solution that won’t scale.
Just as it’s important to understand applications and protocols heading outbound from your organization, you also need to take the time to understand 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 affect 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 “from above.”
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 and 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 the following:
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 slower, 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. Also, logging is an important detail. If it gives you too little or the wrong information, you may have trouble handling incidents.
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, oftentimes even a basic deployment of FW-1 is intense on the pocketbook, costing five to ten times as much as other products. Take a look at all your options; sometimes the second-best will still secure you 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.
TIP
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.
Finally, after you’ve purchased your firewall, you’ll put your research to good use by implementing your firewall and its supporting ruleset(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 20, “Microsoft;” Chapter 21, “Unix;” and Chapter 22, “Novell NetWare,” for more information).
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, oftentimes 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—unless your network environment is extremely simple, or you are a ruleset 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 rulesets. For this, I recommend extensive test runs.
There are really two phases:
Testing the ruleset from the outside
Testing the ruleset from the inside
Consider using the Nmap tool, available from http://www.nmap.org, 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. Additionally, it’s a good idea to periodically review the rulesets on the firewall to make sure they’re meeting current requirements.
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 expectations placed on them.
I assume here that you are familiar with the tool netcat, a network testing tool. More information on netcat can be found in Chapter 21.
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 is the Web server used natively on NT and 2000) installs a number of nasty sample scripts by default. Combine this with the RDS/MDAC problem (see Chapter 20 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 netcat and the echo command, an intruder can:
Create an FTP script that will retrieve a copy of netcat.
Execute that FTP script using
msadc.plandFTP -s -a <scriptname>.Create a script to shut down the Web server, and bind netcat to port 80 using
nc -l -p 80 -e cmd.exe.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).
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 substitute 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 attack accordingly.
NOTE
There is another point to be 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.
This scenario is a bit different. Let’s say that our network policy prohibits the use of unencrypted 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 enable the use of SSH 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 a neat little feature found in most SSH clients called tunneling. Tunneling enables 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 than 110) on his ISP’s machine. As long as the SSH session remained active, the tunnel would work (see Figure 10.2).
The clever user has effectively bypassed our ruleset. 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 and VPNs, 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à—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.
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.
Manufacturer: ISS
Supported Platform: Windows 98 and up
Further Information:
http://www.iss.net/products_services/hsoffice_protection/index.php
BorderManager is the premier firewall for Novell environments, but it will also 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 capability 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:
Manufacturer: Watchguard
Supported Platform: Unix
Further Information: http://www.watchguard.com
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/
Manufacturer: BorderWare
Supported Platforms: Custom (proprietary OS running on Intel hardware)
Further Information: http://www.borderware.com
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/
Firewall Type: Stateful packet filter-based
Manufacturer: NetGuard Inc.
Supported Platform: Windows NT
Further Information: http://www.netguard.com
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/
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/cc/pd/fw/sqfw500/index.shtml
Manufacturer: Secure Computing
Supported Platform: Unix (custom build, however, ships with the product)
Further Information: http://www.securecomputing.com
Manufacturer: SonicSystems
Supported Platforms: N/A (appliance)
Further Information: http://www.sonicwall.com
Firewall Type: Proxy-based
Manufacturer: Axent
Supported Platforms: Solaris and Windows NT
Further Information: http://enterprisesecurity.symantec.com/default.cfm?EID=0&PID=na
Firewall Type: Packet filter-based (personal firewall)
Supported Platforms: Windows 98 and up
Further Information: http://www.tinysoftware.com/home/tiny2?la=EN
Manufacturer: Zone Labs
Supported Platforms: Windows 98 and up
Further Information: http://www.zonelabs.com/store/content/home.jsp
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.