Inside Network Perimeter Security: Stateful Firewalls

This chapter is from the book

Inside Network Perimeter Security, 2nd Edition

Learn More Buy

This chapter is from the book

This chapter is from the book 

Inside Network Perimeter Security, 2nd Edition

Learn More Buy

Stateful Filtering and Stateful Inspection

The definition of stateful filtering seems to vary greatly among various product vendors and has developed somewhat, as time has gone on. Stateful filtering can mean anything, from the ability to track and filter traffic based on the most minute of connection details to the ability to track and inspect session information at the application level. With this loose interpretation in mind, let's define these terms for the purpose of this chapter.

Stateful filtering has been used to define the stateful tracking of protocol information at Layer 4 and lower. Under this definition, stateful filtering products exhibit no knowledge of application layer protocols. At the most basic level, such products use the tracking of the IP addresses and port numbers of the connecting parties to track state. As mentioned previously, this is the only way that connectionless protocols can be tracked, but at best, this is only "pseudo-stateful." What about using this same method of stateful filtering for the tracking of the connection-oriented TCP? As mentioned previously, this method does not in any way track the TCP flags. TCP's flags define its connection states; therefore, although this method might be tracking some information from the various communication sessions, it is not truly tracking the TCP connection state.

More advanced forms of stateful filtering can also track sequence and acknowledgment numbers and the TCP packet flags. With the addition of these criteria, we can get truly stateful connection tracking for TCP, although we still lack the ability to differentiate traffic flows at the application level.

Stateful inspection, in contrast, has come to be used as a description of the devices that track state using all the Layer 4–type information listed previously, as well as the tracking of application-level commands. All this information can be combined to offer a relatively strong definition of the individual connection's state. Also, because Layer 7 information is being examined, extra insight into nonstandard protocol behaviors is available. This allows normally troublesome protocols such as FTP and H.323 to be securely passed by the device without complication.

In both stateful filtering and stateful inspection, the tracked state information is most often recorded into a state table that tracks the information until a connection is torn down (as with TCP) or until a preconfigured timeout is reached (TCP, UDP, and ICMP). Every vendor has its own implementation of these methods, and in the next several sections, we will look at some vendors' definitions of stateful filtering/stateful inspection as used in their products.

Stateful Firewall Product Examples

As stated previously, various firewall products handle the tracking of state in many different ways. This section lists some popular firewall products and provides explanations of how they handle state. We also show examples of each product's state table and examine a sample configuration of a stateful firewall.

Netfilter/IPTables

Netfilter and IPTables are the two main pieces of the most recent incarnation of a firewall product that is freely available for Linux distributions. IPTables is the construct that is used to build the firewall rule sets. Netfilter is the bridge between the Linux kernel and the IPTables rule structure. Netfilter/IPTables is the successor of the ipfwadm and IPChains products, with an ever-increasing list of features and functionality. Now thanks to its connection-tracking feature, IPTables offers stateful filtering capability.²

Connection tracking records the state of a connection based mostly on protocol-specific information. Administrators create rules specifying what protocols or specific traffic types should be tracked. When a connection is begun using a tracked protocol, IPTables adds a state table entry for the connection in question. This state table entry includes such information as the following:

• The protocol being used for the connection

• The source and destination IP addresses

• The source and destination ports

• A listing with source and destination IP addresses and ports reversed (to represent response traffic)

• The time remaining before the rule is removed

• The TCP state of the connection (for TCP only)

• The connection-tracking state of the connection

Following is an example of a state table entry for IPTables:

tcp 6 93 SYN_SENT src=192.168.1.34 dst=172.16.2.23 sport=1054 dport=21 [UNREPLIED]
src=172.16.2.23 dst=192.168.1.34 sport=21 dport=1054 use=1

The first line starts out listing the protocol in question, followed by the protocol's numerical designation (6 for TCP). The next value, 93, represents the time remaining before the entry is automatically cleared from the state table. Then is shown the state that the TCP connection is in. The source and destination IP addresses follow, and then the source and destination ports are listed. Because this is an initial connection (as demonstrated by the connection's TCP state), this line lists that IPTables sees this connection as [UNREPLIED] and hasn't increased its timeout value yet. Next in the listing, we see a reversal of the original source and destination address and port information to allow return traffic. After the connection is established, the state table entry is altered, as you can see in the next example:

tcp 6 41294 ESTABLISHED src=192.168.1.34 dst=172.16.2.23 sport=1054 dport=21
src=172.16.2.23 dst=192.168.1.34 sport=21 dport=1054 [ASSURED] use=1

The [UNREPLIED] marker is removed after the first return packet. Upon establishment of the connection, the [ASSURED] marker is placed on the entry, and the timeout value (41294) is greatly increased.

Now let's consider the rules of IPTables.

To begin, we'll look at the syntax and how it works. This first sample rule is considered an output rule because it defines which traffic can leave through the firewall (-A specifies that this rule will be appended to already existing rules):

iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT

This output rule determines which outbound communication will be accepted (as specified by the –j option). This particular rule deals only with the TCP protocol, as specified by the –p tcp option.

It specifies in the -–state section that NEW and ESTABLISHED traffic is allowed out of our network. This rule, as listed, allows no egress protection. All new outbound TCP traffic will be allowed because the NEW option is specified. NEW tells the firewall to watch for packets with a lone SYN flag that are initiating a connection and to create entries in the state table for every such occurrence. The ESTABLISHED option allows traffic that is part of an existing session that has previously been recorded in the state table to pass as well, which means that any standard TCP communications will be able to leave the network.

Another part of the command worth mentioning is –m state. The –m denotes what module should be used for the rule in question—in this case, the standard state module that comes with IPTables. Now let's examine the rule that will allow the return traffic for our connection back into our network:

iptables –A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT

This command appears identical to the preceding one, except that it is an input rule, and only ESTABLISHED is listed under the –state section of the command. This means that only return traffic will be allowed inbound to our network, as defined by the state table. Iptables determines whether incoming traffic is return traffic for the connection entered into the state table by checking it against the reversed connection information located in the state table entry. No new connections will be able to enter our network from the outside.

Even though most of the requirements of TCP stateful tracking are available in Iptables, one exception to this is the tracking of sequence and acknowledgment numbers, which can be added with the tcp-window-tracking patch.³

From our previous definition of the items held in the state table, you can see that the items needed to do a pseudo-stateful job of tracking ICMP and UDP are present. Examples of basic UDP output and input rules would be as follows:

iptables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT

These rules appear identical to those specified for TCP, except for the –p udp option listing.

ICMP rules look about the same:

iptables -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT

The main differences are the –p icmp specification for protocol and a new entry in the --state section: RELATED.

The RELATED option is the means by which Iptables allows traffic that is already in some way associated with an established traffic flow to initiate a new connection in the state table and be passed through the firewall. This related traffic might be an ICMP error message that is returned for a UDP or TCP connection already held in the state table. It could also be the initialization of an inbound FTP data channel on TCP port 20, after state table information had already been logged for an inside station starting a control channel connection on TCP port 21.

As listed, our rule allows ICMP traffic inbound and outbound that is related to existing ESTABLISHED traffic flows. Therefore, errors returned in response to existing TCP and UDP connections will pass. Because the NEW option is listed for outbound traffic, requests from ICMP programs such as ping will be able to leave our network, and the ESTABLISHED option specified for inbound traffic will allow the replies to said traffic to return back through. However, inbound ping requests will not be allowed in because the NEW option is not specified inbound.

The rules of conduct for defining related traffic are included in connection-tracking modules. They facilitate the examination of application-specific commands, such as the way the ip_conntrack_ftp module facilitates the inspection of FTP's port command to allow the secure handling of standard FTP traffic. (For more information on how stateful firewalls handle FTP traffic, see the "File Transfer Protocol and State" section, earlier in this chapter.) These modules can be added on as new protocols are used in your environment.

To implement a module such as ip_conntrack_ftp to allow standard outbound FTP communications to be properly initialized through our IPTables firewall, it first has to be loaded with a command such as the following:

modprobe ip_conntrack_ftp

Next, a specific rule has to be created to inspect the related traffic. This can be accomplished in the case of FTP by making an INPUT rule that allows inbound TCP port 20 traffic with the state option of RELATED. This will allow the inbound port 20 traffic to connect if the inspection process deems it related to an existing connection in the state table. Here is a listing of such a rule:

iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT

An OUTPUT rule will be needed as well to allow response traffic to return:

iptables -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT

Notice that the –sport 20 option representing the source port in the INPUT rule has changed to the –dport 20 (or destination port) option in the OUTPUT rule. This change is due to the reversal of communication roles for outbound versus inbound traffic.

Check Point FireWall-1

The Check Point FireWall-1 (FW-1) is one of the most popular stateful firewalls in use today. It is software based and can be loaded onto hardware server solutions of various platform types, including Windows, Solaris, and Red Hat Linux. It is also offered as a hardware appliance solution by Nokia. FireWall-1 uses a state table for the basic tracking of connections at the protocol level and an INSPECT engine for more complicated rules involving application layer traffic and nonstandard protocol behavior.

When deciding whether to allow a packet to pass, FireWall-1 tests it against the following data structures, in the order specified:

• First, FireWall-1 checks to see whether a connection is already logged in the state table for this particular incoming packet. If so, it is forwarded without further scrutiny.

• Next, if the state table did not contain an entry for the packet, the packet is compared against the security policy. If a rule allows the packet to pass, it will be forwarded on, and an entry for its communication session will be added to the state table.

TCP traffic is handled at a protocol level, much like previously shown examples. When a communication ensues, because the first packet of a connection will not be reflected in the state table, it is tested against the security policy. If it is accepted based on one of the rules, it is added into the state table.

The rules that might allow traffic to pass are either one of the implied rules set up in the FireWall-1 section of the Global Properties of SmartDashboard or are part of the rulebase created and maintained in FireWall-1's SmartDashboard GUI interface. For an example of a rule's listing and what the SmartDashboard interface looks like, refer to Figure 3.6.

As shown in Figure 3.6, designing a rule set for firewall products such as FireWall-1 can be less demanding than some of the less user-friendly choices, such as IPTables. FireWall-1 allows you to use a GUI interface to represent your networks and systems as objects. You can elect to allow or disallow traffic for specific services by selecting appropriate options and referencing relevant objects. Rule order is one of the most critical things to keep in mind when designing such a rule set. It is vital to list specific rules at the top of the rule list before more general rules that might inadvertently apply to unwanted traffic types.

FireWall-1 enforces timeouts for TCP connections to ensure that improperly terminated sessions that lack the common FIN packet exchange do not remain in the state table indefinitely. The initial timeout on a half-open connection (before the three-way handshake has been completed) is logged at 60 seconds by default. Upon completion of the three-way handshake, this timeout is increased to 60 minutes to allow for latency in communications. After the closing of the connection is initiated with a FIN packet, the timeout is dropped to 50 seconds to ensure that the state table entry is more quickly cleared if the graceful FIN exchange is not completed successfully.

Figure 3.6 Check Point FireWall-1 NG offers a user-friendly GUI interface called SmartDashboard (formerly Policy Editor in previous versions) for editing its rule set.

FireWall-1 handles UDP traffic in much the same way that other stateful firewalls do. It uses a pseudo-stateful method of tracking outbound UDP connections, and it allows inbound UDP packets that match one of the currently recorded communication flows. This process is accomplished through the recording of the IP addressing and port numbers that the communication partners use. A timer is used to remove the session from the state table after a predetermined amount of inactivity (see Figure 3.7).

For a better understanding of FireWall-1's tracking of state, look at its state table. Listing 3.1 is the Check Point FireWall-1 state table as decoded (it normally appears as rows of difficult-to-decipher numbers) by a Perl script (fwtable.pl) available from Lance Spitzner's website at http://www.spitzner.net/fwtable.txt.⁴

Figure 3.7 The Stateful Inspection section of the Global Properties dialog box for FireWall-1 NG contains many settings that define how FireWall-1 handles state.

Listing 3.1 A Check Point FireWall-1's State Table as Translated by fwtable.pl

Src_IP        Src_Prt Dst_IP  Dst_Prt IP_prot Kbuf Type Flags  Timeout
192.168.1.202 1783  192.168.1.207 137   17   0  16386 ffffff00 18/40
192.168.1.202 1885  192.168.1.207 80   6    0  28673 ffffff00 43/50
192.168.1.202 1884  192.168.1.207 80   6    0  28673 ffffff00 43/50
192.168.1.202 1797  192.168.1.207 23   6    0  16385 ffffff00 35/50
192.168.1.202 1796  192.168.1.207 22   6    0  16385 ffffff00 35/50
192.168.1.202 1795  192.168.1.207 21   6    0  16385 ffffff10 35/50
192.168.1.202 1798  192.168.1.207 25   6    0  16385 ffffff00 35/50
192.168.1.202 1907  192.168.1.207 80   6    0  28673 ffffff00 43/50

IP addresses, port numbers, and even timeout values can be clearly seen in the FireWall-1 state table represented by fwtable.pl.

FW-1 supports the stateful inspection of many popular protocols. These include the following TCP protocols: H.323, FTP-BIDIR, RTSP, IIOP, SQLNET2, ENC-HTTP, Netshow, DNS_TCP, SSH2, FW1_CVP, HTTP, FTP-Port, PNA, SMTP, FTP-PASV, FTP_BASIC, SSL_V3, Winframe, CIFS, FTP, INSPECT, CitrixICA, and RSHELL. It also pseudo-statefully inspects the following UDP protocols: CP-DHCP-reply, SNMP Reads, SIP, H.323 RAS, NBDatagram, DNS, CP-DHCP-request, NBName, and Freetel. FW-1 has additional capabilities to track RPC traffic of many varieties. It has the capability to allow many nonstandard protocols, including not only RPC, but also H.323, FTP (standard), and SQLNET2. For example, FireWall-1 statefully handles traffic based on remote procedure calls (RPCs), such as Network File System (NFS), whose ports are randomly generated by the portmapper service. The portmapper service runs on TCP and UDP ports 111 and handles the automatic generation of RPC programs' access ports. Because these ports are generated randomly, it would be nearly impossible to write a secure rule that could effectively permit such traffic. FireWall-1 solves this problem by tracking all specified portmapper traffic and actually caching the port numbers that portmapper maps to the RPC programs in use. This way, such traffic can be effectively tracked.

A new feature of FW-1 NG is the Smart Defense component. It is available in Feature Pack 3 and higher or can be loaded as a hotfix with Feature Pack 2. It allows advanced application layer examination (akin to Deep Packet Inspection) for a list of known attacks, worms, and types of malicious behavior. Applying this additional level of support to your existing FW-1 policy is as easy as switching to the SmartDefense tab in SmartDashboard and checking the protection options you want to employ. For additional information on the many elements of SmartDefense, check out the SmartDefense Technical White Paper on Check Point's website (http://www.checkpoint.com/products/downloads/smartdefense_whitepaper.pdf).

The Cisco PIX Firewall

The PIX firewall statefully inspects traffic using Cisco's Adaptive Security Algorithm (ASA). The ASA is used to make a representative hash of each outgoing TCP and UDP packet and then store it in a state table. When the TCP and UDP traffic return, because a representative entry is recorded in the state table, the traffic will be allowed to pass. ICMP traffic is a different matter. Inbound ICMP traffic is denied through the outside interface of the PIX, and a specific access list must be created to allow any such traffic. Outbound ICMP is allowed, but it will not work by default, because the inbound responses will be blocked, like the echo-reply response to a ping command. Here's an example of an access list that will let ICMP traffic from a given test address cross through the PIX (as commonly used for troubleshooting new PIX installations):

access-list ICMP-ACL permit icmp test address inside address range
access-group ICMP-ACL in interface outside

The first command creates an access list called ICMP-ACL that permits ICMP traffic from a specified test address to our inside address range. The second line applies that ACL inbound on the outside interface.

The command that the PIX firewall uses to configure the stateful examination of traffic flows for a given protocol is the fixup command. The fixup command starts an advanced application-specific examination of outbound traffic of the protocol type listed to the designated port. The Cisco PIX firewall supports this application-level examination of traffic for the following protocols through the standard fixup command: CTIQBE, ESP-IKE, FTP, HTTP, H.323 (now supporting version 3 and 4), ICMP ERROR, ILS, MGCP, PPTP, RSH, RTSP, SIP, SIP UDP, SKINNY (now supporting PAT), SMTP, SNMP, SQLNET, and TFTP. The fixups for these protocols can be added or removed from a PIX configuration and reconfigured for various port specifications. They are considered extraneous to the operations of the PIX.

The PIX also offers built-in fixup support for these protocols: RTSP, CUSEEME, DNS, SUNRPC, XDMCP, H.323 RAS, TCP, and UDP. These integrated fixups are not seen in the PIX's configuration. They work in the background in conjunction with the normal fixups for the advanced inspection of these particular types of traffic. Even if a fixup is not installed for a particular TCP or UDP traffic type, the PIX will still track the session in its state table and allow its return traffic re-admittance to the network.

Not all fixups are created equal. Each fixup tracks application layer information at different levels. This level of inspection might vary from making sure the traffic passes through NAT successfully to the monitoring for specific application-level commands. For example, the SMTP fixup is the most stringent of them all. Since PIX software version 4.2, the SMTP fixup has supplied a protection feature called "mailguard." This fixup allows only SMTP commands to pass through it successfully. Non-SMTP traffic commands are dropped, but the PIX still returns an OK to the sender as if the information were passed. This helps protect poorly defended mail servers from outside attacks. Other fixups, such as FTP and H.323, allow the return of nonstandard communication traffic by monitoring the application-level commands that control the formation of their data channels.

Because the standard fixup command allows the specifying of the port number to be examined for the protocol, alternative configurations are supported. (This is not true for the built-in fixups.) For example, if you need to access a web server that is running on port 8080, use the following command:

Pixprompt(config)#fixup protocol http 8080

Such a fixup command will allow the creation of state table information for the listed outbound traffic type. Multiple fixups can be listed if more than one port number is used per protocol. The PIX's state tables contain ASA hashes based on the source and destination addresses, port numbers, sequence numbers, and TCP flags. Because PIX firewalls use truly random TCP sequence number generation, the connection is kept more secure.⁵

When the reply returns, the PIX checks the response against the state table and information that it knows about the behavior of the protocol in question. If the information checks out, it is allowed to pass. All other information is dropped unless it is specifically allowed using an access list.

The table listing connection state for a Cisco PIX can be viewed using the show conn command. Such a table can be seen in Listing 3.2.

Listing 3.2 The Output from a Cisco PIX Firewall's show conn Command

TCP out xx.yy.zz.129:5190 in 172.16.1.33:1960 idle 629:25:50 Bytes 6737 flags UIO
TCP out xx.yy.zz.254:23 in 172.16.1.88:1053 idle 0:11:33 Bytes 226696 flags UIO
TCP out xx.yy.zz.254:23 in 172.16.1.76:1146 idle 256:09:15 Bytes 78482 flags UIO
TCP out xx.yy.zz.254:23 in 172.16.1.100:1660 idle 145:21:19 Bytes 9657 flags UIO
TCP out xx.yy.zz.254:23 in 172.16.1.100:1564 idle 641:51:05 Bytes 132891 flags UIO
UDP out xx.yy.zz.12:137 in 172.16.1.12:137 idle 0:00:03 flags

Notice that standard IP address and port information is tracked, along with the time that entries will remain in the table. Also notice on the last entry for a UDP connection that no flags are listed. Despite the fact that this output shows current connections and can give you a good idea of what information is in your PIX's state table, this is not a true dump of the state table because it lacks the information provided by the stored ASA hash. You will notice, for example, that sequence numbers are not listed in this output.

To learn more about the way the PIX firewall operates and to better understand the configuration of a stateful firewall, we will look at a PIX firewall configuration using software version 6.3(4). The configuration will only include those items that have to do with passing standard protocol information.

First, in the PIX configuration listing are commands that define the interfaces:

nameif ethernet0 outside security0
nameif ethernet1 inside security100

This is a simple configuration with only two interfaces: an inside interface and an outside interface. Notice the security levels (shown as security0 and security100). By default, all traffic can flow from a higher security numbered interface to a lower one on a PIX, but none can flow from a lower interface to a higher one. By default, this PIX cannot receive inbound traffic connections, but it can send anything out. These default behaviors can be adjusted by using NAT and access lists.

To allow an inbound connection, two criteria must be met:

• A static NAT mapping must be configured to allow the inbound traffic flow to bypass NAT translation, assuming that NAT is used in your environment. If it is not, this criterion can be ignored.

• An access list must be made to allow the type of traffic in question. For highest security, inbound traffic should only be allowed when using a firewall with a DMZ port; public servers can be placed on their own screened subnet.

Because NAT will not be an issue, you only need to add an access list to disallow outbound connections. This prevents the traffic types that you want to disallow. You can also create an egress filter to verify that only authentic local traffic is leaving your network.

The nameif interface commands are followed by the backbone of the PIX configuration: the fixup commands (as mentioned earlier in the section). These commands list the protocols and their associated port numbers that the PIX will inspect. Listed next are some popular choices:

fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060

The next lines of this listing show the IP addresses and subnet masks assigned to both the inside and outside ports. These are displayed here as a point of reference for the NAT-related commands to follow:

ip address outside 192.168.2.178 255.255.255.240
ip address inside 172.16.1.10 255.255.0.0

In the next portion of the listing, we create two address pools of outside addresses for our NAT pool, reflected by the first line, (outside) 2, and for PAT, (outside) 1. If we were only using PAT, the first line would not be necessary.

global (outside) 2 192.168.2.180-192.168.2.190 netmask 255.255.255.240
global (outside) 1 192.168.2.179

Next, we define the inside addresses for pool 2 and pool 1. The first statement lists the pool of inside addresses that will be NAT address translated. All other IP addresses will be forced to use PAT.

nat (inside) 2 172.16.1.96 255.255.255.248 0 0
nat (inside) 1 0.0.0.0 0.0.0.0 0 0

The second line demonstrates a wildcard so that any IP address (other than those listed on the previous line) will be PAT translated. We know that this is a PAT translation command because it maps to the previous global (outside) 1 command, which only has one public address.

PIX firewalls allow return traffic in conjunction with the NAT statement. The NAT and state tables combine to let the firewall know which traffic is returning as part of an already started conversation.

The next statements are the defaults of a PIX configuration and were not added in this example. However, they are displayed to show the default timeouts for the NAT translation table (xlate), the connection listings (state table, conn), and user authentication traffic listings (uauth):

timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 sip
0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute

These timeouts can be adjusted at any time by simply retyping the preceding commands with new timeout values.

The PIX Device Manager (PDM) has simplified PIX firewall management. The PDM is a GUI interface that's used to edit most of the PIX firewall's settings. It allows the editing of firewall access rules, NAT translation settings, host and network objects, and general firewall configuration changes. It also has a Monitoring section (see Figure 3.8) that allows the viewing of statistical information about the PIX and its performance as well as provides the ability to generate attractive exportable graphs.

To use the PDM, you simply have to add the appropriate PDM image to your PIX. This is done by copying the PDM file to the PIX's flash memory with the following command:

copy tftp://ipaddress/pdmfilename flash:pdm.

Here, ipaddress is the IP of the TFTP server holding the PDM image you are copying, and pdmfilename is the name of the PDM file. If there is already a PDM file on your PIX, it will be erased. Your PIX will need to be configured to allow HTTP access from any clients needing to do PDM administration. This is done as follows:

Pix(config)#http 10.0.0.1 255.255.255.255 inside

Here, 10.0.0.1 is the station you want to manage the PIX with. This is followed by a 24-bit mask so that it is the only station allowed to make contact. This could be any legal IP address mask allowing access from one to an entire network segment of addresses. Finally, the statement is ended with the name of the interface you want to manage the PIX through—preferably the inside interface!

Figure 3.8 The PIX Device Manager's Monitoring tab allows the generation of aesthetically pleasing graphs that can be exported.

Now all you have to do is type HTTPS://10.0.0.100 into the URL line of any web browser (where 10.0.0.100 is the IP address of the interface you specified in the HTTP access line). Be sure to specify HTTPS in your web browser! Trying to access the PIX via HTTP is disallowed and will return a "Page cannot be displayed" message. If your configuration was successful, you should be prompted to accept a certificate and then receive a pop-up window asking for authentication information. You can use any username and password you already have configured in your PIX for management, or if none are configured you can leave the Username box blank and type the PIX's enable password in the password box. You should be greeted with the PDM's home startup screen, as shown in Figure 3.9.

If you click the Configuration button, you will be taken to the area in the PDM where most of the important firewall rule and NAT management takes place. The Access Rules tab (see Figure 3.10) is where the firewall rules configured in your PIX can be viewed and edited.

Figure 3.9 The PDM home page shows many useful pieces of information about your PIX, including version, license, and status information.

Figure 3.10 The Configuration section of the PDM allows viewing and editing of the access rules that make up the firewall policy.

If no specific rules have been added to the PIX, the Access Rules tab will appear, as shown in Figure 3.10, with the implicit permit rule for outbound traffic.

The Translation Rules tab shows the NAT configuration for the PIX firewall, per interface (see Figure 3.11). When the radio button Translation Rules is enabled, all NAT commands specified in the PIX and their associated global commands are displayed. Clicking the Manage Pools button allows you to edit the NAT pools for the given interface.

Figure 3.11 The PDM Translation Rules screen shows all NAT information for the PIX.

If the radio button Translation Exemption Rules is selected, the configuration of any NAT 0 commands in the PIX are displayed.

The Hosts/Networks tab is where objects can be viewed and edited for use in the PDM. These objects will be used to populate the access rules when creating a firewall policy.

Finally, you can perform many basic PIX administration tasks on the System Properties tab, including interface configuration, DHCP server and client configuration, logging and AAA settings, various management settings, and more. The PDM is an excellent tool to ease the administrative burden of the firewall for a PIX novice—or even a seasoned professional.

Now that 10Gb networking is being incorporated into the enterprise and Internet connection speeds are getting faster, the speed with which a firewall can statefully process information is becoming increasingly important. An exciting addition to the PIX line is the FireWall Services Module (FWSM). This is a full PIX firewall on a card that fits into an available slot in the 6500 series Cisco enterprise switches. It supports most of the features of the standard PIX but takes advantage of the port density and speed of the 6500. The bandwidth for connectivity is supplied by the backplane of the 6500 (which by default supports 32Gbps), letting the FWSM support an astounding throughput of up to 5.5Gbps! If that's not enough throughput for you, up to three more FWSMs can be added to the 6500 series chassis for a combined throughput of 20Gbps. The FWSM uses the VLAN interfaces of the 6500 for ingress and egress of traffic. In turn, the FWSM can support as many as 250 virtual interfaces!

Virtual firewalls can be configured, allowing management of separate policies by different groups of administrators. The FWSM supports active-passive and active-active configurations as well as management via the PDM. When considering a means to protect intra-VLAN communication on a 6500 series switch or considering a solution in an enterprise environment that requires the maximum in throughput, you would be remiss not to take into account the power and flexibility of the FWSM.