Advanced Protocol Handling

Advanced Protocol Handling

The PIX Firewall offers a number of advanced features to support the many protocols available on the Internet, while maintaining a safe internal environment. Some of these features are configurable using skills already covered or by using the fixup protocol commands, covered in the upcoming section “The fixup protocol Command.” Others are in place and can’t be modified or disabled, such as the attack guards covered in the later section “Attack Guards.” All involve some form of higher-layer awareness than would be available from traditional access control lists (ACLs), which, by definition, are limited to Layer 3– and Layer 4–filtering capabilities. The PIX Firewall Adaptive Security Algorithm (ASA) uses application layer (OSI Layers 5–7) inspection to establish and maintain its stateful access control and traffic-monitoring security.

Application Inspection

The PIX Firewall ASA performs stateful application inspection to provide secure use of external applications and services. In some cases, this involves monitoring for and defending against threatening traffic patterns or activity. In other cases, application inspection is used to facilitate outside connections for specific protocols.

Establishing and maintaining outside connections is easy enough with many applications because all address and port information is established by the inside client in its initial transmission to the outside host. But some sessions require special attention from the PIX Firewall application inspection function. Specifically, those applications and protocols that embed IP address information in the data portion of the packet or those that open additional channels on dynamically assigned ports create impossible problems for standard access list filtering.

Because the application inspection feature can look at the upper layer portions of the packet, it can work with NAT to identify embedded address information. NAT can then translate those embedded addresses and, equally important, update any checksum or other fields affected by the translation. Without this attention to detail, the packets could easily be rejected by the destination host or the firewall.

Note, like CBAC in Chapter 6, this application-inspection function is meticulously programmed for a limited number of common programs or protocols. Application inspection uses upper-level field information and a knowledge of the application/protocols processes to make “informed” decisions about what’s expected and what returning traffic should be allowed.

This application-aware capability allows application inspection to monitor and permit dynamic port number usage by those supported protocols that open additional TCP or UDP ports to improve performance. These applications use the initial session well-known port numbers to negotiate additional dynamically assigned port numbers, which are then opened by the PIX for only the life of the session. The alternative would be the permanent opening of ranges of port numbers and the inherent vulnerability associated with that.

The fixup protocol Command

Application inspection is frequently referred to as fixup because the fixup protocol command can be used to configure the application inspection for many of the supported protocols. Note, other protocols are supported that don’t support configuration. The show fixup command displays the applications/protocols and their default port settings that use the fixup protocol command. These defined port numbers are the ones the PIX Firewall listens to for each respective service. The following output is the default fixup protocol commands enabled on a PIX Firewall version 6.2.

Pix(config)# show fixup
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol ils 389
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060
fixup protocol skinny 2000

If necessary, the port numbers can be changed for each service, except rsh and sip. Remember, if a protocol like HTTP is set to use another port number, any connections established to that port number will be interpreted as if they’re HTTP data.

Using the fixup protocol Command

Use the configuration mode fixup protocol commands to change, enable, or disable the access of supported services or protocols through the PIX Firewall. The command is global and any changes apply to both inbound and outbound connections. The command can’t be restricted by any port address changes in static command statements. The basic syntax looks like the following, where protocol is limited to the 11 supported options in the preceding output.

Pix(config)# fixup protocol protocol [port_options]

The clear fixup command resets the fixup default settings, but it doesn’t remove the default fixup protocol commands. To disable a fixup for a specific protocol, use the no fixup protocol protocol command without any options. The no fixup protocol is stored in the configuration.

Changes made using the fixup command only affect future connection sessions. For any change to take effect immediately, you must use the clear xlate command to remove all existing application inspection entries.

The next pages look at the applications supported by the PIX Firewall application inspection features and a few examples of working with the fixup protocol commands. For more information, a search on fixup on the site offers a wide selection of documents. Particularly for “hot” technologies such as VoIP, checking the latest documentation for the fixup protocol is always wise.

Supported Applications and Protocols

Some fixup protocols support multiple applications, while other applications benefit from application inspection without having a fixup protocol for Configuration options. Features provided often include extending NAT capabilities to IP addresses embedded within the data payload, including adjusting related checksum values, dynamic implementation of additional port connections, and event logging. The following represents a partial list of supported applications.

Basic Internet Protocols

The PIX Firewall uses application inspection to assist common Internet protocols, such as the following. Those followed by an asterisk have fixup command configuration support.

  • Domain Name System (DNS)

  • File Transfer Protocol (FTP)*

  • Hypertext Transfer Protocol (HTTP)*

  • NetBIOS over IP

  • Simple Mail Transfer Protocol (SMTP)*

Voice over IP (VoIP)

The VoIP application inspection supports the following protocols used by Cisco IP Phones, Cisco CallManager, and other Cisco IP Telephony products. Version 6.2 of the PIX OS adds PAT support for H.323 and SIP. This helps to expand your address space to accommodate the large number of endpoints involved when implementing VoIP networks. Those followed by an asterisk have fixup command configuration support.

  • H.323*

  • Session Initiation Protocol (SIP)*

  • Skinny Client Control Protocol (SCCP)*


Multimedia applications represent troublesome challenges to a firewall because multimedia protocols dynamically open additional port connections to improve performance. The PIX Firewall application inspection feature opens and closes UDP ports for secure multimedia connections. Other firewall implementations typically must open a large range of UDP ports, creating security risks, or they must configure one port for inbound multimedia data requiring client reconfiguration.

The PIX-enhanced ASA supports multimedia—with or without NAT—without compromising security. This represents a major advantage over firewall installations that must choose between NAT and multimedia, which either limits multimedia applications to registered users or exposes inside network addresses to the Internet.


While NAT works well with multimedia applications, don’t use PAT while running these applications through the PIX Firewall. Multimedia protocol attempts to dynamically access additional port connections can conflict with port mappings used by PAT.

The multimedia applications supported by the PIX Firewall application inspection include the following. Those followed by an asterisk have fixup command configuration support.

  • CU-SeeMe

  • Intel Internet Phone

  • IRC

  • RealAudio

  • Real Time Streaming Protocol*

  • Streamworks

  • VDO Live

  • Vxtreme

  • Windows Media (Netshow)

Database and Directory Support

The database and directory applications supported by the PIX Firewall application inspection include the following. Those followed by an asterisk have fixup command configuration support.

  • Network File System (NFS) and Sun Remote Procedure Call (RPC)

  • Oracle SQL*Net (V1/V2)*

  • Internet Locator Service (ILS)*

Management Protocols

The PIX Firewall application inspection-supported management protocols include the following. Those followed by an asterisk have fixup command configuration support.

  • Internet Control Message Protocol (ICMP)

  • Remote Shell (RSH)*

  • X Display Manager Control Protocol (XDMCP)

Fixup Protocol Examples

The next three topics—FTP, SMTP, and VoIP—are included as examples of the application-inspection features and fixup commands. The Cisco site has more details and examples for any of the other supported protocols or applications.


The default application inspection for FTP sessions performs the following four tasks:

  • NATs any IP addresses embedded within the application payload

  • Prepares dynamic secondary data connections for FTP data transfer

  • Tracks FTP command-response sequence

  • Generates a detailed audit trail

The following output shows the command syntax, plus an example of the Strict option and adding port 3021 for the PIX to listen to for FTP traffic. Our only concern is with the FTP listening ports because the PIX stateful inspection will dynamically prepare the data connection as needed.

Pix(config)# fixup protocol ftp [strict] [port]

Pix(config)#fixup protocol ftp strict 21
Pix(config)#fixup protocol ftp 3021

The Strict option causes each FTP command and response sequence to be monitored for various RFC violations, including web browsers embedding commands in FTP requests. Any connections discovered to contain embedded commands or that have been manipulated are dropped. Each FTP command must be acknowledged before a new command is allowed.

SMTP—Disabling Fixup Protocol Example

The Mail Guard feature provides safe access for Simple Mail Transfer Protocol (SMTP) connections from the outside to an inside e-mail server. Mail Guard allows a mail server to be safely deployed on the inside network, without the need for an external mail relay (or bastion host) system.

SMTP servers respond to client requests with numeric reply codes and optional human readable strings. The SMTP servers are vulnerable to mischief because of the simplicity of these messages and because some mail systems, such as Microsoft Exchange, don’t fully comply with RFC 821. Mail Guard enforces a safe minimal set of SMTP commands to avoid an SMTP server system from being compromised. Mail Guard performs the following three primary tasks:

  • Restricts SMTP requests to seven commands included in RFC 821: HELO, MAIL, RCPT, DATA, RSET, NOOP, and QUIT.

  • Monitors the SMTP command and response sequence looking for a series of common anomalous signatures. Unacceptable characters or commands are replaced by Xs, which are then rejected by the internal server.

  • Generates a detailed audit trail by logging all SMTP connections.

The SMTP application inspection command syntax and an example of disabling the Mail Guard feature are as follows:

Pix(config)# fixup protocol smtp [port[-port]]

Pix(config)# no fixup protocol smtp 25

The pervasiveness of Exchange servers in the workplace is reason enough to be aware that Mail Guard could cause Exchange servers and Microsoft Outlook clients to have problems in communicating through a PIX Firewall. It might be necessary to disable the SMTP application inspection and use an access list instead.

The following example demonstrates disabling Mail Guard, while allowing outside access to the DMZ e-mail server. The static command assigns a global address to the server. The ACL let_in allows outside users access to the e-mail server global address via SMTP port (25). The DNS server needs to point to the address, so mail can be sent to this address.

Pix(config)# static (dmz,outside) netmask
Pix(config)# access-list let_in permit tcp any host eq smtp 
Pix(config)# access-group let_in in interface outside
Pix(config)# no fixup protocol smtp 25

Voice over IP (VoIP)

VoIP involves using H.323 gateways to convert traditional voice analog traffic into IP data packets. The challenges of highly time-sensitive packets in a LAN environment are compounded exponentially when VoIP has to deal with firewalls and NAT. Fortunately, the PIX Firewall application-layer inspection (fixup) features smooth out most of these wrinkles across all the protocols.

  • H.323

  • Media Gateway Control Protocol (MGCP)

  • Session Initiation Protocol (SIP)

  • Skinny Client Control Protocol (SCCP)

  • Real-Time Transport Protocol (RTP)

  • RTP Control Protocol (RTCP)

This section looks at three protocol suites that provide or facilitate call signaling, call control, and media communications. Depending on the VoIP protocols used, the communications between the devices might use either one channel or many different channels. The channels are Transmission Control Protocol (TCP)/User Datagram Protocol (UDP) ports used for the connections between two network devices.

Session Initiation (or Initiated) Protocol (SIP)

Session Initiation (or Ini-tiated) Protocol (SIP) is a signaling protocol for Internet conferencing, telephony, events notification, presence, and instant messaging. The protocol initiates call setup, routing, authentication, and other feature messages to end-stations in an IP network. The PIX Firewall application-inspection capabilities support SIP VoIP gateways, VoIP proxy servers, and dynamically allocated UDP ports.

Use the fixup protocol command to change the default port assignment for SIP or to add additional ports the PIX will “listen” to. The command syntax is as follows:

Pix(config)# fixup protocol sip [port[- port]]
Pix(config)# no fixup protocol sip [port[- port]]


H.323 is a suite of protocols defined by the International Telecommunication Union (ITU) enabling multimedia conferences over LANs, even though hosts are using different applications. PIX Firewall software versions 6.2 and higher support PAT for H.323. The PIX Firewall supports the secure use of H.323 Version 2 to provide the following features:

  • Fast Connect or Fast Start Procedure for faster call setup.

  • H.245 tunneling for resource conservation, call synchronization, and reduced setup time.

  • Conferencing—the conference is established only after the endpoints agree to participate.

  • Call redirection.

Use the fixup protocol command to change the default port assignment for H.323 or add additional ports the PIX will “listen” to. The command syntax and default settings are as follows:

Pix(config)# fixup protocol h323 {h225 | ras} [port[- port]]
Pix(config)# no fixup protocol h323 {h225 | ras} [port[- port]]

Pix(config)# show fixup
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
Skinny (Simple) Client Control Protocol (SCCP)

Secure handling of SCCP in VoIP networks is necessary to use Cisco IP Phones, Cisco CallManager, and other Cisco IP Telephony products. When coupled with an H.323 Proxy, an SCCP client can coexist with H.323-compliant terminals. The PIX application-inspection capabilities ensure proper NAT translation of all SCCP signaling and media packets passing through the firewall.

PIX Firewall version 6.2 introduced support for DHCP options 150 and 166 (discussed in Chapter 18), which allow the PIX Firewall to send the location of a TFTP server to Cisco IP Phones and other DHCP clients.

Use the fixup protocol command to change the default port assignment for SCCP or add additional ports the PIX will “listen” to. The command syntax is as follows:

Pix(config)# fixup protocol skinny [port[- port]]
Pix(config)# no fixup protocol skinny [port[- port]]

Two problems still exist for SCCP:

  • If the Cisco CallManager server address is configured for NAT and outside phones register to it using TFTP, the connection will fail because PIX Firewall currently doesn’t support NAT TFTP messages.

  • The PIX Firewall currently can’t handle fragmented SCCP packets, such as those that occur with a voice-conferencing bridge. The SCCP inspection checks each packet and drops what appear to be bad packets because the internal checksums aren’t accurate.

Other Supported Protocols and Applications

This section looks at PIX Firewall support for secure use of the following additional important protocols and applications.

Configurable Proxy Ping (ICMP)

The configurable proxy pinging feature, covered in Chapter 18, allows controlling ICMP access to the PIX Firewall interfaces. While ICMP access through the firewall is denied by ASA, access to the interfaces is unrestricted. The icmp {permit | deny} command allows configuring access on a per-interface/per-message–type basis. This feature can shield the PIX Firewall interfaces from detection by users on an external network.

While a temptation exists to deny all ICMP access to the firewall interfaces, permitting ICMP Unreachable (type 3) messages will allow ICMP Path MTU discovery, which is required by IPSec and PPTP traffic.

Internet Group Management Protocol (IGMP)

Internet Group Management Protocol (IGMP) is the protocol that facilitates forwarding router multicast transmissions, which can provide the broad-reach data distributions in an internetwork without the inherent congestion associated with broadcasts and multiple unicasts. IGMP dynamically registers specific LAN hosts in a multicast group with a multicast-enabled router. The enabled routers and supporting Cisco Group Management Protocol (CGMP)–enabled LAN switches efficiently distribute the multicast transmissions to the registered hosts.

PIX Firewall version 6.2 introduced Stub Multicast Routing (SMR) to allow the firewall to function as a stub router, an IGMP proxy agent. The firewall, like any stub router, isn’t a full multicast router, but simply forwards IGMP messages between hosts and multicast routers.

NetBIOS over IP

The NetBIOS over IP support allows connections from the internal network to the external network. This support is important to Microsoft clients on the internal network that need to access external network servers running older versions of Windows, such as Windows NT. This allows the organization security policies to include Microsoft servers across the Internet and inside an intranet, while still allowing access controls native to the Microsoft environment.

RIP Version 2

As covered in Chapter 19, the PIX Firewall is not a router and, as such, won’t forward routing information to other interfaces. Instead, the PIX only “listens” in Passive mode and can be configured to broadcast a default route.

The PIX Firewall supports Cisco IOS software standards, including support for RIP v2, which provides optional MD5 authentication of encryption keys. The RIP v2 support includes one key and key ID per interface. While the key has an infinite lifetime, best practices would indicate more frequent changes consistent with the security policy. Don’t forget, using Telnet to change the configuration might inadvertently expose the key and the key ID on the network.

Part III: Virtual Private Networks (VPNs)