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
[View full size image]
1 A Outbound
PPd OWW«lkWH8 ¿¿¡¿2Ä ÄlmwsHf
_ T ~ jm Siicurtiy 1 HURI - 1CK1
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 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.
Was this article helpful?
Struggling to Optimize Your Site for the Search Engines? Uncover What You Need to Know to Perform Basic SEO on Your Site, and Help Get it Listed in the Powerful Search Engines. Are YOU Ready to Climb Your Way Up The Search Engine Rankings and Start Getting the FREE Traffic You're Looking For? Hundreds of places claim they can give you top rankings, but wouldn't you rather just learn how to do it on your own so you can repeat the process on any future site you build?