Examining and Defining Firewall Technologies
This section covers the following topics:
- What is a firewall?
- Characteristics of a firewall
- Firewall advantages
- Firewall disadvantages
- Role of firewalls in a layered defense strategy
- Types of firewalls
- Cisco family of firewalls
- Firewall implementation best practices
What Is a Firewall?
According to Cisco, a firewall is:
“a system or a group of systems that enforce an access control policy between two networks.”
With a definition this loose, anything that controls access between parts of the network, at whatever layer of the OSI model, can be a firewall! Although vague, the preceding definition is essentially accurate but we could define some key characteristics of a firewall. In Chapter 4, we look at the means to lockdown default services on the router in the context of the router’s responsibilities as a perimeter security device.
The key word here is “perimeter.” In Chapter 3, we find that it is typically at the perimeter, or edge, of a network where we deploy routers. They are often the first bastion of defense against attack because many enterprises, both large and small, use routers as their first connection to an Internet Service Provider’s IP cloud.
If we can define the word “perimeter,” and accept that a firewall defends this perimeter, then we have a good appreciation for what a firewall does. Chapter 3 defines a perimeter as a “trusted network boundary.” The context is the discussion of the three deployment scenarios for a router acting as a firewall. (Pretty dangerous stuff, considering we’re only now defining the word firewall!) Putting these thoughts together into a working definition, we arrive at this definition of a firewall:
A firewall is a system or a group of systems that establish a trusted network boundary (a perimeter) and then manages traffic across that boundary.
Implicit in this definition is a sense of direction. In Chapter 2, “Building a Secure Network Using Security Controls,” we observe that establishing the perimeter made it fairly simple to define ingress and egress flows of traffic because ingress (or inbound) would be defined as traffic that flows from a less-trusted to a moretrusted security zone. Egress (or outbound) traffic would be the opposite direction.
So there you have it! A firewall doesn’t even have to be a device. It could be software deployed on an application server, the perimeter being the point of ingress and egress to the application stack served by that device. It could be software installed on a network device that inspects application layer traffic as it flows across to ensure that it is protocol-compliant. Find the perimeter, and you find the firewall.
The Cisco material mixes its metaphors, so this Exam Cram is forced to do likewise to a certain extent. The word “perimeter” is used in some contexts as the network’s edge, and in the context of network security as a trusted network boundary. (Remember the “blurring of the perimeter” in Chapter 2?) Make sure you understand that in some contexts, the network edge and the trusted network boundary are one and the same thing.
Characteristics of a Firewall
Now that we have defined what constitutes a firewall, let’s look at some common characteristics of firewalls:
- Enforces the Access Control Policy of an Organization. The security policy’s access control policy component defines what is permitted or denied across the firewall.
- Must Be Hardened Against Attacks. Compromising the firewall itself should be remotest of all possibilities because compromising the firewall would compromise its enforcement of access control policies.
- Must Be the Only Transit Point Between Networks. How can a firewall enforce ingress and egress policies when not all traffic is forced to flow through it?
An improperly configured or badly oversubscribed firewall may create an inadvertent network performance problem because of its deployment at a network chokepoint.
Firewalls can aid in the design of secure network architecture because their incorporation creates natural zones of security with differing levels of trusts.
First, the good news. In addition to the characteristics presented in the previous section, other advantages of firewalls include the following:
- Firewalls defend networks against the exploitation of protocol flaws and sanitize the protocol in some cases.
- Firewalls defend sensitive hosts and applications against exposure to untrusted users.
- Firewalls defend against attackers sending malicious code or data to clients and servers.
- With proper design, a firewall makes policy enforcement visual, simple, robust, and scalable.
- Network access control can be simplified by offloading security management to a few points in the network.
Now, the bad news. Firewalls aren’t a perfect solution, sometimes because the people who design and configured them aren’t. Besides the aforementioned traffic bottlenecks, here are some other disadvantages:
- Firewall misconfiguration can cause single points of failure.
- Many applications are not firewall-friendly because their specific attributes are not well understood and are therefore hard to securely pass through a firewall.
- End-users may try to find ways around an overly restrictive firewall.
- Tunneled traffic (covert channels) is difficult to detect and protect against.
Role of Firewalls in a Layered Defense Strategy
According to Cisco, a firewall has three basic roles in the Cisco Self-Defending Network:
- Perimeter Security. Secures the boundaries between zones.
- Communications Security. Provides information assurance (C-I-A).
- Core Network Security. Ensures that only compliant traffic traverses the perimeter:
- Protects against malicious software.
- Protects against traffic anomalies.
- Enforces network security policies.
- Ensures survivability.
- Endpoint Security. Enforces compliance to identity and device security policies.
Types of Firewalls
According to Cisco, there are five main categories of firewalls:
- Static Packet-Filtering Firewalls
- Application Layer Gateways
- Dynamic (or Stateful) Packet-Filtering Firewalls
- Application Inspection Firewalls
- Transparent Firewalls
We will look at all five, devoting most of our attention to the first three.
Static Packet-Filtering Firewalls
Figure 5.2 illustrates the basic functionality of a static packet-filtering firewall. Static packet-filtering firewalls work at layers 3 and 4 and filter packets one at a time.
Static packet-filtering routers are relatively unintelligent. By using ACLs, they can either permit or deny traffic up to the layer 4 of the OSI model, but they don’t see the PDUs (Protocol Data Units) that carry the data as part of a dynamic conversation. For example, they can permit traffic if it matches the wellknown TCP port number for HTTP, port 80, but they can only filter the packets singly and have no appreciation for how a TCP connection is built, carries and re-transmits data as required, and is torn down.
A static packet-filtering firewall is like unknowledgeable fans at a tennis match. They can watch single volleys go across the net, but they don’t see the ball in the context of game, set, and match. If you think of the tennis ball as a TCP segment, for example, the analogy is complete. These fans may be qualified to let volleys with the green-colored (destination port 80) balls across the net, but the finer points of how the game is started (begin TCP session), played (data flow),and ended (session torn down) is beyond them. You could even give the fans further responsibilities, telling them that the green ball (TCP port 80) is only allowed from player A (source IP address) to player B (destination IP address), but they will still only be able to examine each volley separately.
Static packet-filtering firewalls are very useful for simple, not particularly granular, rules … “big chunk” rules like, “Absolutely no TCP Port 80 traffic is allowed inbound past the perimeter.”
Be careful how you use ACLs, however. In Figure 5.3, a static packet filtering firewall is configured to permit Internet users to access the web server in the DMZ.
Refer to “A” in Figure 5.3. The ACL is applied inbound on the Internet facing interface, FastEthernet 0/0/1 in the figure.
access-list 101 permit tcp any host 192.168.1.20 eq 80
interface FastEthernet 0/0/1
ip access-group 101 in
Recall from your CCNA studies that when you create an ACL, you also create an implicit rule at the very end of the ACL, whether you enter it or not: access-list 101 deny ip any any
All traffic that doesn’t match the access control list entries (ACE) before this last statement will therefore be implicitly denied. This also means that you have to have at least one permit somewhere in the ACL; otherwise, all traffic is doomed for failure!
The effect is that only destination port 80 traffic will be allowed in through the firewall and only to IP address 192.168.1.20, the public IP address of the web server in the DMZ. Replies from the web server will be allowed out, because there is no interface ACL applied outbound on the Internet-facing interface. “Great!” you say. Mission accomplished. But what about the inside PC? Can it make connections out to the Internet server (point “B” in Figure 5.3)? Yes, but replies will be blocked on the implied rule in access-list 101. This happens because the firewall is only looking at packets one at a time. It doesn’t see the return packets from the Internet server as part of a conversation that was started from the inside PC and allowed outbound. Stupid firewall! How could you solve this problem with the existing network topology? You could do one of the following:
- Add ACEs to access-list 101, allowing the source port number of every conceivable Internet application that your users are allowed to access inbound through the firewall.
- Apply access-list 101 outbound on the DMZ interface instead of inbound on the Internet interface.
- Upgrade to a dynamic packet filtering firewall.
The first choice is impractical, not to mention it creates a large vulnerability. The second choice is feasible, but the effort would have to be replicated for every internal interface on your network, and might create a management nightmare. The third choice might be the best one and might even be accomplished with a Cisco IOS software upgrade and some small re-configuration and without the need for additional hardware.
So, where would you deploy a static packet-filtering firewall? A good example would be a Cisco IOS router configured with ACLs as a static packet-filtering firewall at the network edge. This customer-managed Internet router, connected to an ISP router, could enforce perimeter security as part of a layered defense strategy. It wouldn’t be very good at communications security, core network security, or endpoint security (of the four firewall roles covered previously), but that isn’t its intended role.
Advantages and Disadvantages of Static Packet-Filtering Firewalls
Advantages of static packet-filtering firewalls include the following:
- Simple permit/deny rules
- Little or no impact on network performance
- Simple to configure
- Supported on most routers
- Good first level of defense at a lower OSI layer (“big chunk” rules)
- 90% of effectiveness of high-end firewalls at an appreciably lower cost
Disadvantages of static packet-filtering firewalls include the following:
- Difficult to catch IP spoofing
- Filtering fragmented IP packets is problematic
- Implementation and maintenance of complex ACLs
- Some applications/services cannot be filtered
- Stateless (only one packet at a time)
Application Layer Gateways
Figure 5.4 illustrates the basic operation of an application layer gateway.
An application layer gateway (or proxy server) is a firewall that proxies a client’s connection to a server at layers 5 and 7 (session and application) of the OSI model.
When describing layered network architecture, it is often convenient to group layers 5, 6, and 7 of the OSI model into a single application layer. Thus, the TCP/IP protocol stack can line up, layer-by-layer, with the OSI model for layers 1 to 4, with a single layer 5. It is at this single, composite application layer that application layer gateways operate.
Referring to Figure 5.4, here are the steps that illustrate the operation of an application layer gateway:
- At the application layer, the client first connects to the application layer gateway.
- (Optional) The user is authenticated to the proxy at the application layer.
- The application layer gateway proxies (acts on behalf of) the client’s connection to the application server.
- The application layer gateway accepts replies from the application server.
- The application layer gateway forwards the replies to the client.
If the proxy server is not operational, the client will not be able to connect. No proxy = no service.
Advantages and Limitations of Application Layer Gateways
Advantages of application layer gateways include the following:
- Persons, and not devices, are authenticated.
- DoS attacks are made more difficult because it is harder for hackers to spoof as theirs isn’t a direct path to the target system.
- Option to monitor and filter application data.
- Option to configure detailed logging.
Limitations of application layer gateways include the following:
- Software processing of packets can be CPU-intensive.
- Can be memory and disk-intensive, too. (We have to store the cached connection information somewhere!)
- Requires a proxy per application.
- Limited number of application supported.
- Sometimes requires additional client configuration or software.
As a general recommendation, only use application layer gateways in key situations where increased security is an acceptable tradeoff for less performance.
Recall that there are six bits in a TCP segment header that, depending on which combination of bits is set, describe the state of a TCP session. TCP defines rules for the combinations of bit settings that are allowed. A stateful packet-filtering firewall will also understand these rules. The bits are as follows:
- URG = Urgent
- ACK = Acknowledge
- PSH = Push
- RST = Reset
- SYN = Synchronize
- FIN = Finish (or finalize)
Dynamic (or Stateful) Packet-Filtering Firewalls
Figure 5.5 illustrates the basic operation of a dynamic (or stateful) packet-filtering firewall.
A dynamic packet-filtering firewall is like a knowledgeable tennis fan or umpire. They understand all the rules of the game and can permit or deny volleys that don’t follow the rules. They can filter all the way up to layer 4 of the OSI model like the static packet-filtering firewall can, but they also understand that:
- A game starts with an opening serve from the player who has service (requester send SYN).
- The in-bounds serve is supposed to be returned by the opponent (responder sends SYN, ACK), but sometimes it is rejected (responder sends RST) because the opponent is not ready.
- If the initial player receives the ball back from the opponent (SYN, ACK), they will return the ball (thank you very much!) with an (ACK) and the volley continues. The initial three-way handshake (SYN; SYN, ACK; ACK) is complete.
- Either the initial server or the opponent can tear down the volley (the TCP session) at any time by sending a (FIN) to their opponent, beginning a four-way handshake that culminates in the session’s (the volley’s) termination. In this manner, the firewall builds a database of connections that are built across it and the state that they are in. This is called the state table. Here’s what a stateful firewall does with every packet that is lobbed across it:
- The packet is checked first to see if there is a pre-existing connection between the end systems’ (client and server) sockets.
A socket is made up of an IP address + a port number. The two sockets (source and destination) uniquely identify the circuit between the connection partners.
- If the state table indicates that there is an existing connection between the sockets, the state table is further referenced for that connection and the flags (SYN, ACK, RST, and so on) in the packet are checked to see if they are valid for that connection. For example, once a connection is set up, the firewall would refuse any further SYNs between the sockets, as they are used only when the connection is first being set up.
- If a connection doesn’t already exist, the firewall will allow it to be built as long as no ACL denies the initial SYN. The connection state is put into the state table (see the following note).
It is important to note that stateful firewalls only consult an interface ACL once: when the connection is being set up with the initial SYN. All subsequent packets are checked against the state table. As long as the packet matches the correct state per the state table, as well as other information like sequence numbers, the packet is allowed through the firewall. Therefore, unlike static packet-filtering firewalls, an interface ACL on a stateful firewall only needs to permit that first SYN. There is no need to have another ACL to allow the correct response (for example, SYN, ACK, or RST), as would likely be the case with a static packet-filtering firewall.
In this fashion, the stateful firewall is plug-and-play. You only need to permit a connection to be initiated in one direction, and the firewall will dynamically create a rule to allow the return flow. This makes configuration that much simpler. Referring again to Figure 5.3, the network would function as designed if the static packet-filtering IOS router/firewall was replaced with a dynamic packet-filtering firewall.
Dynamic packet-filtering firewalls can enforce perimeter security. They also can ensure core network security insofar as they can detect anomalies in traffic patterns. Often they employ VPN technologies and can therefore manage some of C-I-A implicit in communications network security.
Uses and Limitations of Dynamic Packet-Filtering Firewalls
Uses of dynamic packet-filtering firewalls include the following:
- Intelligent first level of defense
- Primary defense mechanism
- Augmenting static packet filtering
- Improving routing throughput
- Proof against spoofing and DoS attacks
Limitations of dynamic packet-filtering firewalls include the following:
- Doesn’t filter at the application layer.
- Not all protocols are stateful like TCP (for example: ICMP, UDP, some routing protocols).
- Some applications use multiple channels and dynamic port numbers negotiated above the transport layer (for example: FTP, RealAudio, some multimedia).
- Cannot authenticate users to connections (because this occurs at a higher layer of the OSI model).
As a general recommendation, deploy stateful firewalls as the premier defense mechanism of a secure network architecture.
Application Inspection Firewalls
Figure 5.6 illustrates a firewall that works at the application layer.
At first glance, you might assume that application layer gateways and application inspection firewalls are synonymous. They are not. Though they both work at the application layer (really, layers 5, 6, and 7) of the OSI model, an application inspection firewall will perform deep packet inspection at the application layer in order to determine that protocols that are proceeding across the firewall are compliant with the organization’s security policy. At the same time, the application inspection firewall can ensure that the protocol is standards-compliant and also look for signs of unauthorized protocols tunneled inside the application session. For example, the eDonkey protocol that is used by the popular P2P application, Kazaa, could be blocked when it appears inside an HTTP session.
Here’s another example. Refer to Figure 5.6. The network security policy says that anonymous FTP is allowed to the FTP server in the DMZ, but that no one is allowed to alter, move, create, copy, or delete files or directories. This would be typical of a public mirror site supporting a Linux distribution, perhaps on a university’s network. We could instruct the computer science student who is managing the FTP server, that the server’s patch revision must be up-to-date and that it is configured correctly to allow only anonymous FTP with access control per the security policy. The application inspection firewall could be configured to inspect the FTP command channel (recalling that FTP uses two channels: one for command/control and another for data) and block unauthorized activity at the application layer.
For this to occur, the firewall needs to have an intrinsic understanding of how the application layer protocol works. This higher intelligence is not found on all firewall products and can distinguish one vendor’s products from another. It is often bundled with dynamic packet filtering as part of a Unified Threa Management (UTM) product.
The final category of firewalls is transparent firewalls. A transparent firewall, as its name implies, starts making forwarding and filtering decisions at the data link layer (layer 2) of the OSI model. It works in a secure bridging mode at layer 2, while offering rich layers 2 through 7 security services.
Figure 5.7 illustrates the basic layer 2 functionality of a transparent firewall.
The four other firewall categories mentioned previously are all fundamentally IP firewalls. A transparent firewall, on the other hand, can filter and forward other protocol suites (such as AppleTalk, Novell IPX, DEC VMS, and so on) based on identifying information in the Ethernet frame header. It can also guard against some common layer 2 attacks such as ARP table poisoning, DHCP spoofing, and MAC flooding by virtue of its layer 2-aware design. Like a switch, the transparent firewall is invisible at layer 3, requiring no readdressing of the network.
Cisco Family of Firewalls
The Cisco family of firewalls includes the following:
- Cisco IOS firewalls
- Cisco PIX 500 Series firewalls
- Cisco ASA 5500 Series Adaptive Security appliances
The following are features of Cisco IOS firewalls:
- Zone-based policy framework
- Application layer firewalling for email, web, and other traffic
- IM and P2P application filtering
- VoIP inspection and firewalling
- Virtual Routing and Forwarding (VRF) support
- Wireless integration (if equipped)
- Stateful failover
- Local URL filtering: whitelist and blacklist support
- National Institute of Science and Technology (NIST) Federal Information
Processing Standard (FIPS) 140 and Common Criteria certifications
- Dynamic Multipoint VPN (DMVPN)
The following are features of Cisco PIX 500 Series firewalls:
- Advanced application-aware firewall services
- VoIP and multimedia security
- Site-to-site and remote access IPsec VPN
- Five models:
- PIX 501 (SOHO / ROBO)
- PIX 506E (ROBO / SMB)
- PIX 515E (SMB / Enterprise)
- PIX 525 (Enterprise)
- PIX 535 (Enterprise / SP)
The following are features of Cisco ASA 5500 Series Adaptive Security appliances:
- Intelligent threat defense
- Secure Sockets Layer (SSL) and IPsec VPN
- Content Security Services
- Cisco Unified Communications (voice and video)
- Key component of the Cisco Self-Defending Network
- Five models:
- ASA 5505 (SOHO / ROBO)
- ASA 5510 (ROBO / SMB)
- ASA 5520 (SMB / Enterprise)
- ASA 5540 (Enterprise)
- ASA 5550 (Enterprise / SP)
Firewall Implementation Best Practices
According to Cisco, this is a summary of the most important best practices for integrating firewalls into a comprehensive security policy:
- Place firewalls at key network security boundaries.
- Although firewalls are the primary security device, it is unrealistic to assume that the firewall is all that is needed for security.
- Adopt a “deny all” strategy by default. Deny all traffic except that which is expressly needed. (See Chapter 2, “Building a Secure Network Using Security Controls.”)
- Do not forget physical controls on firewall access.
- Regularly monitor firewall logs for signs of intrusion. (See Chapter 4, “Implementing Secure Management and Hardening the Router.”)
- Make sure that changes to the firewall’s configuration occur within an overall change management policy.
- Firewalls are primarily technical controls against outside attack. Do not let internal security lapse as a result.
- Adopt strong administrative controls and physical controls to complement the firewall’s technical controls.