Chapter 5. Firewalls

Courage is resistance to fear, mastery of fear—not absence of fear.

—Mark Twain

The Internet is an exciting and wonderful place to browse and explore. It has been likened to the Wild West, The Great Frontier, and other grandiose achievements of mankind. In reality, the World Wide Web is merely a collection of routers and servers that make up the largest wide-area network (WAN) in recorded history. This collection of networking gear provides mail servers, websites, and other information storage and retrieval systems and is all connected to the Internet and accessible to every person who is also connected. It has even been said that the Internet contains the collective institutional knowledge of mankind.

Wow! What awesome potential! The entire collective knowledge of mankind is stored on magnetic media just waiting for people to download and learn. Entire books have been written on the Internet’s potential and its impact on our lives. We are concerned with this network’s security, so we must ask what kinds of safeguards are in place to protect such an unbelievable amount of information.

Is there some organization that polices the Internet much in the same way the State Police cruise the highways? How about a federal agency that snoops around and double checks every possible device connected to the Internet? The answer to these questions is no; there is no unifying organization that is responsible for protecting the Internet. The job of securing and maintaining the doorways to the Internet halls of knowledge is left up to the person or persons responsible for publishing the information in the first place. Each website is fronted by a corporate Internet connection or Internet service provider (ISP), whose job it is to make sure that hackers (the bad guys) do not make a mess of the carefully stored and catalogued information of the website in question. And just how does one protect a website, mail server, FTP server, or other information sources accessible from the web? The answer is one word: Firewall. The sole purpose of these dedicated hardware devices is to provide security for your network.

A firewall is a security device that sits on the edge of your Internet connection and functions as an Internet Border Security Officer. It constantly looks at all the traffic entering and exiting your connection, waiting for traffic it can block or reject in response to an established rule. The firewall is law and protection in a lawless global web. It is ever vigilant in its mission to protect the internal network resources connected to it.

The Internet has made so much information available to individual users as, over the years, access to this information has evolved from an advantage to an essential component for both individuals and businesses. However, making your information available on the Internet can expose critical or confidential data to attack from everywhere and anywhere in the world—the Internet is literally a worldwide network. This means that, when I connect to the Internet in Raleigh, North Carolina, I can be subject to attacks from Europe, Asia, and so on. Firewalls can protect both individual computers and corporate networks from hostile intrusion from the Internet, but you must understand your firewall to use it correctly.

This 24-hour/365-day-a-year “electronic Robocop” has a very important job: to keep the bad guys out and let the good guys get to the resources they need to do their jobs. Sounds pretty simple, right? On paper it sounds like a walk in the park, but in reality, configuring a firewall “properly” is far from easy.

In some cases, a badly configured or feature-inadequate firewall can be worse than no firewall at all. This is difficult to believe, isn’t it? Nonetheless, it is true. This chapter dissects a firewall’s duties to understand what makes it operate and how it does its job.

Firewall Frequently Asked Questions

Before looking at the overall operation of a firewall, the following sections examine and answer some of the fundamental questions surrounding them.

Who Needs a Firewall?

This is perhaps the most frequently asked security question. If you plan on connecting to the Internet, you need a firewall. It does not matter if you connect from home or your company is connecting—you need a firewall, period! The increased penetration of broadband Internet services to the home and their always-on Internet connections make home security even more important.

Why Do I Need a Firewall?

You read about security threats in the papers or hear about them on the evening news almost every day: viruses, worms, denial-of-service (DoS) attacks, hacking, and new vulnerabilities to your computer. For example, SoBig, Blaster, LovSan, SQL Slammer, Code Red, NIMDA, and MyDoom have all appeared on the evening news. Unless you have not read a newspaper or watched the news in the last year, you surely have heard at least one of these names.

It is no secret: hackers are out there, and they are out to get us. Often, we do not know who they are, but we do know where they are and where we do not want them to be (in our network). Like pirates of old roamed the seas, hackers roam the wide expanses of the Internet. You do not want them to enter your network and roam among the computers that connect to it.

You know that you must protect your network from these attackers, and one of the most efficient methods of protecting your network is to install a firewall. By default, any good firewall prevents network traffic from passing between the Internet and your internal network. This does not mean that the firewall will stop all traffic—that defeats the purpose of being on the Internet. It does mean that the firewall is configured to allow only web browsing (HTTP/port 80) to access it from the Internet. Along the way, the firewall provides Stateful Packet Inspection (SPI) rules to every incoming packet (as discussed previously in Chapter 2, “Security Policies and Responses.”)

The alternative to having a firewall is allowing every connection into your network—nor would there be any sort of packet inspection to determine whether an attack is hidden within one of the incoming packets. Not having a firewall is ill advised and will make your organization wide open to everyone on the Internet.

Do I Have Anything Worth Protecting?

I often hear people say: “I understand that if I had something worth protecting, I would definitely need a firewall. However, I do not have anything an attacker would want, so why should I worry about a firewall?”

Networks and their resources are important to the way our society conducts business and operates. In practical terms, this means that there is value to your network and having it operate effectively. This increased role of networks means that you definitely have something worth protecting to some degree, as documented in the following list:

• Downstream liability—This sounds like a confused fishing show title, but it is perhaps the next big step in the legal evolution of the Internet. Downstream liability involves allegations that an attacker has taken control of a target computer (yours) and used it to attack a third party. Assume that it is your company’s computer that has been compromised by a hacker. Your company’s failure to protect its own systems has resulted in the damaging of a third party; the attacker used your computer as a weapon against the third party. Your company is therefore negligent because it has failed in its duty to protect against reasonable risks—specifically, no firewall was in place. The prudent person’s obligation here is to use reasonable care. A more detailed definition can be found in Prosser, Wade, and Schwartz’s Cases and Materials on Torts: “...requiring the actor to conform to a certain standard of conduct, for the protection of others against unreasonable risks.” Who says Hollywood liberalism doesn’t contribute to society?

• Lost data—You have probably heard the stories of companies that lost all their business data in the September 11^th attacks, and many of them did not recover. What if your company experienced the same loss because you did not have a firewall and an attacker deleted your data because they could? What would happen to your business? Would it cost money to re-create everything? Would you suffer lost sales?

• Compromise confidential data—Every organization has data it considers confidential and, if lost, might cause financial problems, legal difficulties, or extreme embarrassment. These things might be caused by the loss of customer information such as credit card numbers, secret plans for the new weight loss formula, or secret plans that end up in the hands of a competitor. The list goes on, and when you have been hacked, you must assume the worst. Perhaps, this is why most cybercrimes go unreported.

• Network downtime—Have you ever gone to an ATM machine or a grocery store to get cash and paid with your cash card in the swipe card readers? The networks allowing these devices to operate usually work fine; however, if they were not protected, an attacker might cause them to go down. The loss of revenue from these networks can quickly grow if they are unavailable. Downtime is the bane of any network, and a cost is always associated with these types of events.

Ultimately, everyone has something worth protecting, and failure to do so is ill advised; it is just a matter of time before something happens. The next question is, “What does a firewall do to protect my network?”

What Does a Firewall Do?

A firewall examines traffic as it enters one of its interfaces and applies rules to the traffic—in essence, permitting or denying the traffic based on these rules. As shown in Figure 5-1, a firewall filters both inbound and outbound traffic.

Figure 5-1. Firewall in Operation

Firewalls, like access control lists (ACLs), can filter traffic based on source/destination IP addresses, protocol, and the state of a connection. In other words, normally you might not allow FTP into your network (via the firewall), but if a user inside your network begins an FTP session, it is allowed because the session was established from inside the network. By default, firewalls trust all connections to the Internet (outside) from the trusted internal network (inside).

A firewall can also log connection attempts with certain rules that might also issue an alarm if they occur. Finally, firewalls allow you to perform Network Address Translation (NAT) from internal private IP addresses to public IP addresses. The section, “Firewall Operational Overview,” discusses the roles of a firewall; however, here we tie the firewalls back to Chapter 2’s security policies discussions by examining how a firewall enforces your security policy.

Firewalls Are “The Security Policy”

What kind of traffic is allowed into or out of your network? How do you secure your network against attacks? What is your security policy? What happens to the people who do not follow the security policy? Who is responsible for writing and updating the security policy?

All these questions are valid, and they all deserve answers. Having a network that connects to the Internet via a firewall is only the first step to security; because this book is about first steps, this would be a perfect place to start. You should now know that the security policies form the basis of how these rules are put into production.

Do you remember the old saying, “No job is ever finished until the paperwork is done?” Well, no security solution is even remotely close to complete until you establish a written narrative of the rules and regulations that govern your organization’s security posture. This written version of your security rules and regulations is known as a security policy. Now, this “policy” document is very different in nature and scope than a security plan,” so be sure that you understand what makes a policy unique from every other security document an organization maintains. And just what is it that makes a security policy different from a security plan? Drum-roll please....

PUNISHMENT! That is correct, a security policy includes what is permissible and what will happen to you if you do not live by the law of the land. If you do not follow the rules, you can be

• Fired or dismissed

• Demoted

• Demoted and fined

• Fired, dismissed, and demoted

• Demoted, dissed, and dismissed

• All of the above

All kidding aside, the security policy document spells out in clear language exactly what the law is, who enforces it, and what happens to you if you break it. It is all about the consequences of user actions.

Having said that, how can a firewall be the security policy? Simple—a firewall does what it does by following the “rules” configured by a network engineer or Information Security Officer (ISO). These rules should align perfectly with a written narrative version found in the security policy document you have on your shelf, next to the box of 5-inch Floppy Disks at the back of the server room or sitting useless in some manager’s office. Grab that old dusty binder and check it out. You should see that the security policy document contains information and a listing of the network rules, as covered in Chapter 2. The interesting thing is that all the rules in the policy document should also be configured on the firewall.

The configuration rules entered on a firewall should align perfectly with the rules outlined in an organization’s security policy. If you were to examine the firewall’s configuration file, you might see something like Example 5-1, which is a portion of a Cisco PIX Firewall Configuration.

Example 5-1. Sample PIX Firewall Rules

The conduit permit statements in Example 5-1 are most likely in keeping with some security policy statement that dictates what services are allowed, by name, to enter the protected network and the destinations to which those services are allowed to travel. These statements are your network’s security plan, and the security policy defines them.

In an effort to expand on the Firewall-Policy analogy, examine some additional security policy bullet points and how a firewall aligns with them:

• A security policy outlines what action will be taken in response to circumstances that arise.

• A security policy document is constantly evolving and changing to meet new security needs.

• A security policy dictates both acceptable and unacceptable usage parameters.

If you perform a point-by-point comparison of a security policy with a firewall configuration, you see that firewalls act in conjunction with a written security policy document, as shown in Table 5-1.

Table 5-1. Comparing Security Policies and Firewall Configurations

The intention of this section is not to convince you that a firewall is a replacement for a security policy document, but to get you thinking about security as an all-encompassing philosophy of plans, policies, and security devices. You must put a great deal of thought into a complete solution—not simply rely on a single aspect to protect your network. When you are ready to plan your firewall’s configuration and develop the rules permitting or denying traffic, you should use your security policy as the starting point. Firewalls are the physical and logical manifestations of your security policy.

Firewall Operational Overview

Every long journey begins with the first step. Before delving too deep into other areas of security appliance behavior, it is essential to understand how a firewall performs its magic.

Most firewalls (most, not all) rely on Stateful Packet Inspection (SPI) to keep track of all outbound packets and the responses these packets might generate. Keeping track of the hosts on the protected network that are generating outbound packets keeps rogue or unsolicited WAN packets from entering an external interface.

In other words, a firewall that uses SPI, as discussed in Chapter 3, “Overview of Security Technologies,” watches all traffic that originates from an inside host, tracks the conversation from that host to the desired destination, and ensures that the inbound response to that request makes it back to the host that started the whole thing in the first place.

The dual purpose of packet inspection and filtering of packets is one of the most fundamental responsibilities of a firewall. The following list includes the most common rules and features of firewalls:

• Block incoming network traffic based on source or destination—Blocking unwanted incoming traffic is the most common feature of a firewall and is the main reason for a firewall: stopping unwanted traffic from entering your network. This unwanted traffic is usually from attackers, thus the need to keep it out.

• Block outgoing network traffic based on source or destination—Many firewalls can also screen network traffic from your internal network to the Internet. For example, you might want to prevent employees from accessing inappropriate websites.

• Block network traffic based on content—More advanced firewalls can screen network traffic for unacceptable content. For example, a firewall that is integrated with a virus scanner can prevent files that contain viruses from entering your network. Other firewalls integrate with e-mail services to screen out unacceptable e-mail.

• Make internal resources available—Although the primary purpose of a firewall is to prevent unwanted network traffic from passing through it, you can also configure many firewalls to allow selective access to internal resources, such as a public web server, while still preventing other access from the Internet to your internal network. In many cases, this can be accomplished by using a DMZ, which is where the public web server would be located (DMZs are discussed later in the section, “Essentials First: Life in the DMZ.”)

• Allow connections to internal network—A common method for employees to connect to a network is using virtual private networks (VPNs). VPNs allow secure connections from the Internet to a corporate network. For example, telecommuters and traveling salespeople can use a VPN to connect to the corporate network. VPNs can also connect branch offices to each other. Some firewalls include VPN functionality and make it easy to establish such connections.

• Report on network traffic and firewall activities—When screening network traffic to and from the Internet, it is also important to know what your firewall is doing, who tried to break into your network, and who tried to access inappropriate material on the Internet. Most firewalls include a reporting mechanism of some kind or another. A good firewall can also log activity to a syslog or other type of archival storage receptacle. Perusing firewall logs after an attack has occurred is one of a number of forensic tools you have at your disposal.

Firewalls in Action

Are you thoroughly confused at this point? Look at the Figure 5-2 for a bit more clarity of this process. Please refer to the list, which explains the steps shown in the figure a bit more in-depth.

Figure 5-2. Firewall in Operation

Before looking at the list of steps illustrated in Figure 5-2, it is important to point out that many firewalls just have two physical interfaces in them, and 99 percent of them are based on Ethernet. These interfaces are called inside (protected) and outside (unprotected) and are deployed in relation to your network. Thus, in practice, the outside interface connects to the Internet, and the inside interface connects to your internal network:

1. Host A, an Apple PowerBook G4, opens a web browser and wants to view a web page from the www.avoidwork.com web server.
   

   Host A sends the request outbound through the firewall.

2. The firewall sees the request originated with Host A and is destined for www.avoidwork.com.
   

   a. The firewall notes the outbound request and expects that the reply will come only from the www.avoidwork.com web server.

   b. A session marker is placed in the firewall’s session state table that will track the communication process from start to finish.

   c. Connection metrics are also placed in the marker that is being maintained by the firewall for this conversation.

3. The reply to Host A’s web page request is sent back from the www.avoidwork.com web server to Host A via the firewall.
4. The firewall checks its session state table to see if the metrics being maintained for this session match the outbound connection. If all the stored connection details match exactly, the firewall allows the inbound traffic.

Consider one last issue regarding stateful firewalls in general. If a firewall maintains connection state context regarding inbound and outbound connections, the possibility of a hacker “spoofing” or “forging” a packet with the intention of penetrating your network becomes difficult. When attackers try to send packets to get through a firewall, incorrect or missing connection state information means that the session is terminated and most likely logged for later review.

Implementing a Firewall

The choice of available firewalls is almost mind-boggling these days; they come in every shape, size, and parameter. When I am designing a firewall solution for a customer, the first thing I want to know is what will the firewall’s responsibilities be?

The type of firewall you install depends on your exact requirements for protection and management, as well as the size of your network or what is to be protected by the firewall. Firewalls usually fall into one of the following categories:

• Personal firewall—A personal firewall is usually a piece of software that is installed on a single PC to protect only that PC. These types of firewalls are usually deployed on home PCs with broadband connections or remote employees. Of course, any time someone wants to deploy a firewall, it is a good idea. Some of the more well known personal firewalls can be found at these websites:

http://www.zonelabs.com

http://www.tinysoftware.com

http://www.firewallguide.com

Operating system manufacturers such as Apple and Microsoft have responded to this need by integrating personal firewalls within them. Apple’s OS X (Panther) comes with an IP Firewall, and Windows XP has a similar firewall.

• All-in-one firewall—These kinds of firewalls are widely used by broadband (cable or DSL) subscribers who have the benefit of a single device that offers the following features and functionality: router, Ethernet switch, wireless access point, and a firewall. If this type of firewall appeals to you, please make sure that you take care to determine the firewall’s abilities, and be skeptical of the security you can gain from these devices regardless of who makes them.

• Small-to-medium office firewalls—These firewalls, such as the Cisco PIX 501 or 506, are designed to provide security and protection for small offices.

• Enterprise firewalls—These firewalls, such as the Cisco PIX 515, are designed for larger organizations with thousands of users. As a result, they have additional features and capacity, such as more memory and extra interfaces.

Cisco firewalls all run the same version of operating system that have the same reporting and management capabilities regardless of model. Larger models are needed when there are demands for larger numbers of connections and capacity.

Normally, a firewall is installed where your internal network connects to the Internet. Although larger organizations also place firewalls between different parts of their internal network that require different levels of security, most firewalls screen traffic passing between an internal network and the Internet. For example, if a large organization allows business partners to connect directly to its network, you typically find a firewall controlling what is allowed into their network from their partners. This placement of an internal firewall is definitely considered best practice.

No matter what type of firewall you choose, you must define the filters that will support your security policy.

Determine the Inbound Access Policy

As network traffic passes through a firewall, the traffic is subject to the rules defined within the firewall. Because 99 percent of all networks use private IP addresses on the inside of their networks, you can expect almost every firewall to be using Network Address Translation (NAT)—as discussed in Chapter 3.

If all your LAN traffic were destined to the Internet, the inbound access policy would be straightforward in its design. The firewall permits only inbound traffic in response to requests from hosts on the internal LAN. The firewall tracks all outbound requests in its state table, as previously discussed.

However, there will come a time when specific requests from the outside must be allowed and controlled through the firewall. Notice that I did not say that this was a good idea or that you should do it.

Allowing direct access from the Internet (outside) through your firewall is perilous, but common practice. The key to security in these types of implementations is to strictly define the traffic types you will allow and the port number. For example, permitting IP to any location inside your network is inappropriate. For example, you should permit Internet HTTP (port 80) traffic to your web server (IP address: 10.10.10.10). This allows only HTTP port 80 traffic to the web server from the Internet, which is much smarter. Do you think you should do anything else?

Of course you should, if you are now a believer in a layered security model to protect your network. Because many vulnerabilities and attacks use HTTP and port 80, the firewall cannot detect many of them because you have permitted that traffic through—see how this is a catch 22? A strongly recommended practice is to add layers of security in the form of a personal firewall, Intrusion Detection System (IDS), and virus software. Also, before you implement these configurations, make sure that your security policy outlines the best practices and what steps are needed to maintain security. If you do not have a security policy, this is a great catalyst to make the decision to start one!

Determine Outbound Access Policy

All firewalls screen traffic that is coming into a firewall, but a well-implemented and designed firewall also screens outgoing user traffic.

Recall the earlier discussion of proxy servers and how they can be used to control and monitor traffic that leaves your network. They are a good example of a device that defines an outbound access policy.

Additionally, recall the earlier discussion about placing a firewall between your network and connections to business partners. This type of firewall usage and placement is also where you would apply and control traffic bound from your network to theirs.

You might also want to use your main firewall to control what IP addresses are allowed to exit; specifically, you should allow only IP addresses that are found on your internal network out, thus preventing spoofing of IP addresses.

Perhaps, there are also certain places on the Internet where you do not want users to go. Alternatively, you might want to specify the locations they are allowed to go to because every other destination will be denied by default.

The next section looks at the next aspect of firewall and network security the Demilitarized Zone (DMZ).

Essentials First: Life in the DMZ

The Demilitarized Zone (DMZ) is a term used in the military to define a buffer area between two enemies. Perhaps the most commonly acknowledged DMZ in the world has been the DMZ between North and South Korea, which separates them because they have not yet signed a permanent peace treaty since the Korean War. Perhaps this is an interesting piece of military and political trivia that you did not know, but how does it relate to securing your network and firewalls?

Connecting web, mail, and FTP servers to the Internet can be dangerous and, in some cases, simply not advised. If your company has a self-hosted public website complete with e-mail servers, you might consider using a two-interface (Inside and Outside) firewall and have the firewall create translation rules that direct the inbound traffic to the correct servers on your private network. While that might seem like a pretty safe thing to do, it could be disastrous if a talented hacker sets his sights on you. Well, some really smart people got together a long time ago and said, “Hey—let’s put a third interface in the firewall and call it a DMZ.” Adding the third interface to a standard firewall made things both easier and quite a bit safer when deploying Internet accessible servers and services (www, e-mail, and so on).

Sending traffic from the Internet inbound directly to your private network is a bad idea. It is so bad that it is amazing that some organizations even consider it. If you were going to sell computers out of your house, you would not want people coming all the way inside your house to buy one, would you? Of course not; you would want to set up a little shop in the garage or the front porch, thus preventing people that you do not know from wondering all over your house and tampering with your comic book collection or going into your fridge and making a sandwich.

A DMZ is an interface that sits between a trusted network segment (your company’s network) and an untrusted network segment (the Internet), providing physical isolation between the two networks that is enforced by a series of connectivity rules within the firewall. The physical isolation aspect of a DMZ is important because it allows only Internet access to the servers that are isolated on the DMZ and not directly into your internal network, as shown in Figure 5-3.

Figure 5-3. DMZ Placement and Function

In Figure 5-3, the segment connected to the DMZ interface houses the mail, web, and FTP servers. Rules applied to the DMZ interface prevent traffic from the Internet from going beyond the segment attached to it.

The biggest benefit to a DMZ is in isolating all unknown Internet requests to the servers on the DMZ and no longer allowing them into your internal network. However, there are some additional benefits to deploying a firewall with a DMZ that will help you better understand what is happening in your network and thereby increase security:

• Auditing of DMZ traffic

• Locating an Intrusion Detection System (IDS) on the DMZ

• Limiting routing updates between three interfaces

• Locating DNS on the DMZ

This section discussed what a DMZ is and provided a general example of how one is used. The following case studies examine a requirement for a DMZ and why one should be used in a network given a specific set of criteria.

Case Studies

This chapter has presented several interesting aspects of how firewalls operate and how they can be deployed. The introduction of this information needs to be reinforced with some real-world case studies that provide some answers to questions you might still have and clarify the important aspects of what has already been covered.

Case Study: To DMZ or Not to DMZ?

The Carpathian Corporation has decided that it no longer wants to pay its ISP to host its web and mail servers. The IT department has decided that it will use two older servers to provide these services to its clients and company staff. The IT staff is planning on hosting these servers at its corporate office and are unclear whether it should purchase a firewall that has a DMZ interface.

If the Carpathian Corporation wants to continue with its proposed plan for “self hosting,” it needs to consider the security-related issues that are relevant to the solution being suggested. It is taking the right steps by asking what security ramifications should be addresses. The Carpathian IT staff needs to take a good look at the risk factors involved with providing for its own Internet services (www and mail) and where the pitfalls might be:

• Question/Security Issue #1—Will Internet traffic be allowed to travel to servers on the private network, or is there another solution?

Answer—The web and mail servers will be attached to the DMZ segment. They will not be dual homed or have conflicts of security in its implementation.

• Security Issue #2—How will the IT staff ensure that inbound network traffic will stay confined to the segment containing the web and mail servers?

Answer—The DMZ interface rule set will not allow external traffic to reach the private network, by nature of configured connectivity rules. This will keep the inbound Internet traffic confined to the DMZ segment only.

• Security Issue #3—What measures will be taken to hide the private network from the inbound network traffic?

Answer—The DMZ interface will not have routes to allow this to occur.

The Carpathian IT Staff is into the “What is a DMZ and why do we need one?” frame of mind. The answers should be obvious at this point: use a firewall with a third or DMZ interface. The previous section gave us the basic mechanics of the DMZ interface and a typical deployment scenario.

Case Study: Firewall Deployment with Mail Server Inside the Protected (Internal)

This chapter has described the business needs of deploying a mail server on your internal network and the ramifications of allowing this to happen with regards to the security of your network. Ultimately, however, deploying a mail server internally is still common practice and deserves a look at a basic implementation of this solution.

This scenario presents a small to medium-sized corporate network, as shown in Figure 5-4. As the configuration in Example 5-2 shows, there is only a mail server inside, but it could also be a web server or DNS.

Figure 5-4. Firewall Deployment with Mail Server Inside

Example 5-2. PIX Firewall Inside Mail Server Configuration

Case Study: Firewall Deployment with Mail Server in DMZ

This chapter has taken care to describe the business needs of deploying a mail server on your internal network and discussed the ramifications of allowing this to happen with regard to the security of your network. Ultimately, however, deploying a mail server internally is still common practice and deserves consideration of a basic implementation of this solution.

This scenario presents a small to medium-sized corporate network, as shown in Figure 5-5. As the configuration in Example 5-3 shows, only a mail server exists on the DMZ; however, it could also be a web server or DNS.

Figure 5-5. Firewall Deployment with Mail Server in DMZ

Example 5-3. PIX Firewall DMZ Mail Server Configuration

Firewall Limitations

A firewall is a crucial component of securing your network and is designed to address the issues of data integrity or traffic authentication (via stateful packet inspection) and confidentiality of your internal network (via NAT). Your network gains these benefits from a firewall by receiving all transmitted traffic through the firewall. The importance of including a firewall in your security strategy is apparent; however, firewalls do have the following limitations:

• A firewall cannot prevent users or attackers with modems from dialing into or out of the internal network, thus bypassing the firewall and its protection completely.

• Firewalls cannot enforce your password policy or prevent misuse of passwords. Your password policy is crucial in this area because it outlines acceptable conduct and sets the ramifications of noncompliance.

• Firewalls are ineffective against nontechnical security risks such as social engineering, as discussed in Chapter 1, “Here There Be Hackers!”

• Firewalls are a bottleneck of traffic because they concentrate traffic and security in a single spot, resulting in a potential single point of failure.

Chapter Summary

This chapter covered the world of firewalls and their role in securing a network. Not everyone believes in the value of these devices, and our discussions in this regard allowed us to answer these naysayers and show them the folly of their ways. We provided further proof of the importance of firewalls by expanding on their pure technical aspects, while expressing the fundamental truth that firewalls are the manifestation of a company’s security policy.

Operationally, this chapter covered how firewalls function, where and when to implement them, and how to design the access policies that are necessary to define access into your network. Furthermore, the chapter introduced the DMZ interface as an evolution in firewalls and how they provide special locations for various Internet servers. The chapter concluded with several brief case studies demonstrating firewalls in action, followed by some of their limitations.

Chapter Review Questions

The following questions assist in reinforcing the concepts covered in this chapter.

1. Who needs a firewall?

2. Why do I need a firewall?

3. Do I need a firewall?

4. How is a firewall an extension of a security policy?

5. What is the name of the table in a firewall that tracks connections?

6. What fundamental does a DMZ fulfill?

7. What are four benefits of a DMZ?

8. Can firewalls enforce password policies or prevent misuse of passwords by users?