How the PIXASA Firewall Works | Firewall Fundamentals

How the PIX/ASA Firewall Works

Note

With the implementation of the PIX and ASA software starting with version 7.0, many of the features and functionality of the firewall were changed dramatically. Version 7.0 was truly a major design shift. This chapter is written to include the 6.x software because, in addition to the new 7.x software, that is the version of software that most Cisco PIX firewalls are running. Where possible, we point out the new/changed features, commands and functionality that is provided via the 7.0 code. If no note specifies which version of software a command functions on, that means that the command is the exact same regardless of whether the firewall is running 6.x or 7.x software. For more detailed information about PIX 7.0 code, refer to the Cisco ASA and PIX Firewall Handbook (Cisco Press).

Fundamentally, the PIX/ASA firewall functions by filtering traffic that is transmitted through the firewall across the firewall interfaces. This allows the PIX/ASA to protect hosts and networks from unauthorized access while still permitting access that is deemed (and defined) by the administrator as acceptable. The firewall functionality performs these tasks by parsing a security policy, functioning in a firewall mode of operation, and performing stateful inspection of the data.

Firewall Security Policy

The firewall security policy (not to be confused with the general security policies discussed in Chapter 10, "Firewall Security Policies") on the PIX firewall is what determines the traffic that will be permitted or denied by the firewall. To facilitate this, the PIX implements a combination of the following elements to assist in making filtering decisions:

Separate the network into zones based on security levels
Use ACLs to permit or deny traffic
Apply Network Address Translation (NAT)
Apply authentication, authorization, and accounting (AAA) for through traffic
Apply web or FTP filtering

In addition, the Cisco ASA can perform the following:

Use the Advanced Inspection and Prevention Security Services Module (AIP SSM) to perform deep packet inspection on the data. The AIP SSM is beyond the scope of this book.
Use the CSC SSM to perform threat protection and content control for antivirus, antispyware, antispam, antiphishing, URL blocking, content filtering, and file blocking. The CSC SSM is beyond the scope of this book.
Apply QoS policies to give priority to certain types of network traffic. QoS is beyond the scope of this book.

Separate the Network into Zones Based on Security Levels

The PIX separates a network into separate zones based on their security level. These security levels range from 0 (completely untrusted) to 100 (completely trusted). Depending on the number of interfaces on a given PIX, there are at least two zones: 0 (outside interface) and 100 (inside interface). If there are additional interfaces on the PIX, they can be assigned a security level value from 1 to 99. Traffic from higher-security zones is allowed to pass to lower-security zones provided a translation rule is in place (the translation rule is optional for 7.x). Traffic between zones of equal security is also allowed to pass unimpeded, provided that the connections between resources have been enabled.

Use ACLs to Permit or Deny Traffic

A fundamental aspect of almost all firewalls, including the PIX and ASA, is the use of ACLs to define the list of traffic permitted or denied by the firewall. The PIX can use multiple ACLs that can be applied independently to each interface on the firewall. For PIX 6.x, the ACLs are always applied to inbound traffic on an interface. With PIX/ASA 7.x, this functionality has been expanded to allow the ACL to be applied to both inbound and outbound traffic on an interface.

It is important to understand that the concept of inbound and outbound traffic in the context of an ACL is based on the traffic direction on the given interface, not the network that the traffic may have come from. For example, it is easy to think of an outbound ACL as applying to traffic that is coming from the internal network (after all, the traffic is going out of the network). This is not correct, however. From the perspective of the firewall, that traffic would actually be inbound traffic on the internal network interface and would be most effectively filtered by using an ACL that is applied to inbound traffic on the internal network interface. An example of an ACL applying to outbound traffic is the traffic permitted to exit an interface to a demilitarized zone (DMZ) segment.

Apply NAT

PIX firewalls can also use NAT to facilitate the use of private IP addresses on the internal network, hide the local address of resources, and resolve IP routing problems due to overlapping IP address ranges on connected networks. NAT is typically used any time that traffic from a lower-security level interface is allowed to pass to a higher-security level interface. This implementation typically requires the use of both an address translation and an ACL.

The PIX uses two types of translation:

Static translation An external address is assigned on a 1:1 basis to an internal address. This is commonly referred to as traditional NAT.
Dynamic translation An external address (or address pool) is assigned to an internal address range (or ranges) and an address from that pool is dynamically assigned on a first-come, first-serve basis. If all addresses in the pool are taken then the PIX can dynamically switch to PAT, where a single external address can provide translation to multiple internal addresses by mapping TCP and UDP port numbers to unused port numbers on the translated address. In addition, PAT can be configured without a NAT address pool, allowing a single external IP address to perform all translations.

Two primary exceptions apply to this situation. First, if the hosts on the different networks are not using NAT at all, as is typically the case with VPN connections, translations are not required. Instead, the command nat 0 acl is used to specify the traffic (based on the ACL) that should not be translated and rather should be directly transmitted through the firewall.

The PIX 7.x code also changes this functionality in that translations are no longer required; however, an ACL is still necessary. In this case, the traffic is either permitted or denied as determined by a corresponding ACL.

Apply AAA for Through Traffic

Certain types of traffic, in particular HTTP traffic, can also require authentication and authorization of the user attempting to initiate this traffic. This can be used to ensure that only permitted users are able to pass the traffic in question through the firewall. In addition the PIX can be configured to forward accounting information to a RADIUS or TACACS+ server for reporting of usage.

Apply Web or FTP Filtering

The PIX and ASA can perform some rudimentary filtering of web (HTTP and HTTPS) and FTP traffic by default. This functionality can be greatly enhanced through the use of third-party content-filtering systems, allowing for granular filtering and control of access to specific websites, FTP server, and many other Internet-based applications (such as instant messenger and peer-to-peer file-sharing applications). In particular the following Internet filtering products are supported for seamless integration with the PIX/ASA:

Websense Enterprise
Secure Computing SmartFiler (formerly Sentian by N2H2)
CSC-SSM (although it is not as feature rich as the previous two solutions are and is really tailored more to the small/medium environment that needs basic filtering functionality)

Firewall Modes of Operation

Traditionally, PIX firewalls operated in a single mode of operation, known as routed mode. This is the most common firewall mode of implementation and treats the firewall as a router hop on the network. Devices on one side of the firewall are considered to be on different subnets than devices on the other side of the firewall.

With the advent of PIX/ASA 7.x and the ASA security devices, a new mode of operation known as transparent mode was implemented. In transparent mode, the firewall operates more like a bridge than a router, transparently allowing traffic to traverse the firewall without requiring additional router hops or manipulation of the data. Essentially, the same network exists on both sides of the firewall. Because the firewall interfaces do not have IP addresses assigned to them (at least not in the conventional sense, you still need to assign an IP address to perform remote management of the firewall), the firewall is commonly referred to as operating in stealth mode (because it is not easily detectable).

For most implementations, the firewall will be configured to operate in routed mode (and this is the default operating mode). Some notable exceptions that lend themselves to transparent mode are instances where you want a firewall that can filter traffic that would be otherwise blocked by routed mode (for example, unsupported routing protocols or multicast traffic). In addition, transparent mode firewalls can use EtherType ACLs to allow the firewall to filter some types of non-IP traffic. Transparent firewalls can also be used in situations where you do not want or need to re-IP address devices on each side of the firewall, instead of leaving them as previously configured with no additional configuration required.

Stateful Inspection

Stateful packet inspection lies at the heart of how PIX/ASA firewalls function. This functionality is provided through a process known as the Cisco adaptive security algorithm (ASA). The ASA uses a stateful approach to security. Every inbound packet is checked exhaustively against the ASA and against connection state information in memory. The ASA applies the following default rules (although this is by far not an exhaustive list) to traffic coming into the PIX:

Allow any traffic connections that originate from the inside, higher-security, network to an external, lower-security network unless specifically denied by an ACL.
Allow any traffic for which application inspection has been configured and the traffic has been determined to be acceptable traffic.
Drop and log attempts to initiate connections to a translation slot (for example, a server protected by the firewall) from the outside unless there is an ACL that permits that connection.
Drop and log source routed IP packets.
Deny all Internet Control Message Protocol (ICMP) traffic from lower-security interfaces through the firewall except if explicitly permitted. This prevents responses to outbound ICMP traffic from being able to be successfully delivered (for example, if an external host is pinged using an ICMP echo, the result will appear to be a request timed out because the ICMP echo-reply packet will be blocked on the external interface and never reach the original source host).
Permit all ICMP traffic to the firewall itself (this can be disabled or controlled with ICMP inspection).
For PIX 6.x traffic may not exit the PIX firewall on the same network interface it entered. For PIX 7.x, this is a configurable option.

The ASA allows connections from a higher-security interface to a lower-security interface without an explicit configuration for each internal system and application, as shown in Figure 6-1.

Figure 6-1. Cisco PIX ASA Operation

The ASA is always in operation and monitors all return packets to ensure they are valid. This is done by checking the state table to determine whether the packet in question is a response to a legitimate outbound connection. If it is, the packet is automatically permitted (this is the definition of stateful packet inspection). In addition, the ASA actively randomizes the TCP sequence numbers while ensuring that they stay within an acceptable range to minimize the risk of TCP sequence number attack.

The ASA can also perform application inspection for certain types of traffic to determine whether it should be permitted or denied.

Application Inspection

Application inspection is provided on the PIX firewall as a component of the ASA through the use of fixups or inspections. For PIX/ASA 7.0, the fixup command has been replaced by the use of the policy-map command. Functionally, the process is similar between a fixup and a policy map.

Application inspection allows the firewall to perform additional inspection of certain types of applications. In doing so, the firewall can make filtering decisions based not on the protocol in use (for example, SMTP) but on the actual application (for example, only allowing HELO, MAIL, RCPT, DATA, RSET, NOOP, and QUIT commands for SMTP traffic).

Application inspection is performed on the following protocols/applications (PIX/ASA versions older than 7.1 may not support all of these applications):

ctiqbe This inspection allows for Cisco IP Softphone and other Cisco Telephony Application Programming Interface/Java Telephony Application Programming Interface (TAPI/JTAPI) applications to work across the firewall.
dns This inspection allows you to define the maximum Domain Name System (DNS) length. The default value is 512, which can cause issues with some Microsoft DNS servers (http://support.microsoft.com/kb/828263).
esmtp This inspection enables you to define the commands that will be allowed for SMTP and ESMTP applications functioning across the firewall. Microsoft Exchange servers can experience problems with certain ESMTP inspection configurations (http://support.microsoft.com/?kbid=895857).
ftp This inspection will prepare secondary channels for FTP data transfer, track the FTP command-reference sequence, and generate and audit trail and NAT-embedded IP addresses.
gtp This inspection performs application inspection for the GPRS Tunneling Protocol (GTP) that is used for providing secure access over wireless networks.
h323 This inspection provides support for H.323-compliant applications such as Cisco CallManager and VocalTec Gatekeeper. This allows it to NAT embed IP addresses and dynamically allocate negotiated connections over different ports than the initial connection was established.
http This inspection provides for enhanced HTTP inspection (for example, ensuring compliance with RFC 2616). It also allows the firewall to use URL screening through third-party content-filtering software such as Websense or Secure Computing. Finally, it provides for the ability to perform Java and ActiveX filtering.
icmp This inspection allows the firewall to perform stateful inspection of ICMP traffic in a manner similar to how TCP and UDP traffic are inspected (for example, by ensuring that only one response is generated for one request and that the sequence numbers used are correct). Without this command, it is recommended that ICMP traffic not be permitted through the firewall.
icmp error This inspection allows the firewall to create xlates for intermediate hops that send ICMP error message.
ils This inspection provides NAT support for Microsoft NetMeeting, SiteServer, and Active Directory products that use Lightweight Directory Access Protocol (LDAP) to communicate with an Internet Locator Server (ILS).
mgcp This inspection is used to support Call Agent and other media gateways.
netbios This inspection performs inspection of NetBIOS traffic on UDP ports 137 and 138.
pptp This inspection inspects PPTP protocol packets and dynamically creates the generic routing encapsulation (GRE) connections and xlates required to permit the PPTP traffic.
rsh This inspection allows for RSH clients and servers to negotiate port numbers for communications with each other.
rtsp This inspection allows the firewall to permit RTSP packets such as those used by RealAudio, RealNetworks, Apple QuickTime 4, RealPlayer, and Cisco IP/TV.
sip This inspection is used to allow SIP Voice over IP (VoIP) calls to function through the firewall by allowing the dynamic embryonic connections required by SIP to be created.
skinny This inspection is used to allow Skinny Client Control Protocol (SCCP) VoIP services to function through the firewall.
snmp This inspection is used to implement SNMP inspection in conjunction with the use of the snmp-map command. You can also use this inspection to change the ports that SNMP is listening on.
sqlnet This inspection is used to ensure that the data stream for Oracle applications is consistent on either side of the firewall and inspects the packets to determine which embedded ports need to be opened for SQL*Net Version 1.
sunrpc This inspection can be used to change the port that the firewall is listening for Sun Remote Procedure Call (RPC) traffic and allows for the creation of dynamic ports that are required for Sun RPC communications.
tftp This inspection is used to create the dynamic connections and translations required to facilitate TFTP file transfers.
xdmcp This inspection is used to allow the dynamic connections and X Window System sessions required to permit X Display Manager Control Protocol (XDMCP) communications.