Section 1-2. Inspection Engines for ICMP, UDP, and TCP

1-2. Inspection Engines for ICMP, UDP, and TCP

The following sections outline the basic stateful inspection of each type of applicable protocol.

ICMP Inspection

ICMP is a connectionless protocol, because it allows one host to send another host a message without expecting a reply. Because of this, a firewall can't examine or track the state of ICMP traffic between two machines. However, beginning with PIX 7.x, a firewall can track the state of ICMP packet exchanges, offering an approximation of a stateful inspection.

A firewall must rely on some of its basic mechanisms for inspecting ICMP trafficthe xlate table and ACLs. Note that no connections are used with ICMP, so no conn entries are created for ICMP traffic. Figure 1-5 shows how a Cisco firewall reacts when it needs to handle ICMP traffic between two hosts on different interfaces.

Figure 1-5. How a Firewall Handles ICMP Traffic

Host PC-1 sends an ICMP packet to host PC-2. The firewall needs an xlate entry for one or both of the hosts. This is created from either a static xlate or a dynamic assignment, depending on the configuration. The ICMP packet must also be permitted by any ACL that is applied to the firewall interface toward PC-1.

As an example of this process, PC-1 (foreign address 172.16.1.100) tries to ping host PC-2 (global address 172.18.1.200). PC-2 has a static xlate entry that translates global address 172.18.1.200 on the outside to local address 192.168.199.100 on the inside.

The debug icmp trace command reveals debugging information for all ICMP traffic passing through the firewall. Similar information could be gathered from Syslog messages generated by the firewall. In this case, message IDs 305009, "Built static translation," and 609001, "Built local-host," might be seen. The debug icmp trace command output for this scenario is as follows:

 Firewall# debug icmp trace ICMP trace on Warning: this may cause problems on busy networks 1: ICMP echo-request from outside:172.16.1.100 to 172.18.1.200 ID=768 seq=3328   length=40 2: ICMP echo-request: untranslating outside:172.18.1.200 to inside:192.168.199.100 3: ICMP echo-reply from inside:192.168.199.100 to 172.16.1.100 ID=768 seq=3328   length=40 4: ICMP echo-reply: translating inside:192.168.199.100 to outside:172.18.1.200 

On line 1, the echo request ICMP packet is received on the outside interface. Line 2 shows the xlate entry being used which is an "untranslation" toward the inside host PC-2. Line 3 records the echo reply returning toward PC-1. Line 4 shows that the xlate entry has been used again, in the forward direction toward PC-1.

As soon as the xlate entries are in place and the ACLs permit the traffic, the two hosts are free to send ICMP packets to each other. In fact, other hosts might also be able to send ICMP packets to them too, if the xlate entry exists for the destination host and the ACL permits it.

If NAT is used, the xlate entries remain in effect for the duration of a connection or until the static NAT entry is removed from the configuration. For dynamic Port Address Translation (PAT), however, the firewall simply allows the ICMP packets to continue until a fixed 30-second idle time has expired. The following output demonstrates this scenario.

NOTE

As a part of the ICMP inspection engine, PIX releases 7.0 and later have much tighter control over ICMP activity. The firewall permits only a single reply to any ICMP request that passes through it. Although the ICMP xlate entry might remain active until the 30-second idle timer expires, any actual ICMP return traffic after the first reply packet is dropped.

If NAT is used for the xlate entry, the firewall allows the ICMP connection to remain open for 2 seconds after the one ICMP reply packet is seen. Dynamic PAT is slightly different; the ICMP connection is closed immediately after the first reply packet.

 Firewall# show xlate local 172.21.4.2 debug 14340 in use, 34527 most used Flags: D - DNS, d - dump, I - identity, i - inside, n - no random,        o - outside, r - portmap, s - static ICMP PAT from inside:172.21.4.2/1024 to outside:10.10.10.10/62204 flags r   idle 0:00:29 timeout 0:00:30 Firewall # show xlate local 172.21.4.2 debug 14360 in use, 34527 most used Flags: D - DNS, d - dump, I - identity, i - inside, n - no random,        o - outside, r - portmap, s - static Firewall # 

A ping has created a dynamic xlate entry, and that entry has been idle for 29 seconds. Notice that the timeout value is 30 seconds, which is a fixed value for ICMP entries. 1 second later, the xlate entry has been deleted from the table.

A Case Study in ICMP Inspection

Without the stateful inspection of ICMP traffic offered in PIX 7.x, the decision to allow ICMP traffic does have its shortcomings. This is because of the nature of the ICMP protocol.

For example, it might seem natural to always expect an ICMP echo request to come first and an echo reply to be returned. After all, that's how the whole ping process works and how the PIX 7.x ICMP inspection engine operates. Suppose ICMP inspection is disabled, as it is in releases before PIX 7.x, and ICMP echo packets are permitted to pass through a firewall.

You might be surprised to learn that a host on the outside can then send something odd to an inside hostunsolicited ICMP echo reply packets without any echo requests! This can happen even if the firewall is using dynamic PAT of the inside host addresses. It is all possible because ICMP has no inherent connection or state information.

The following configuration displays a capture on the firewall to briefly show that only ICMP echo reply packets are being sent toward the inside host 192.168.199.100. Chapter 10, "Verifying Firewall Operation," explains captures in more detail.

 Firewall# show capture test 6 packets captured 23:09:21.471090 172.16.1.100 > 192.168.199.100: icmp: echo reply 23:11:01.497212 172.16.1.100 > 192.168.199.100: icmp: echo reply 23:11:01.498112 172.16.1.100 > 192.168.199.100: icmp: echo reply 23:11:01.498951 172.16.1.100 > 192.168.199.100: icmp: echo reply 23:11:01.499791 172.16.1.100 > 192.168.199.100: icmp: echo reply 23:11:01.500828 172.16.1.100 > 192.168.199.100: icmp: echo reply 6 packets shown Firewall# 

Now look at the following xlate and ICMP debug activity to see how the firewall reacts to the unsolicited echo replies:

 Firewall# 67: ICMP echo-reply from outside:172.16.1.100 to 172.18.1.200 ID=0 seq=3369   length=80 68: ICMP echo-reply: untranslating outside: 172.18.1.200 to inside:192.168.199.100 69: ICMP echo-reply from outside: 172.16.1.100 to 172.18.1.200 ID=1 seq=3369   length=80 70: ICMP echo-reply: untranslating outside: 172.18.1.200 to inside:192.168.199.100 71: ICMP echo-reply from outside: 172.16.1.100 to 172.18.1.200 ID=2 seq=3369   length=80 72: ICMP echo-reply: untranslating outside: 172.18.1.200 to inside:192.168.199.100 73: ICMP echo-reply from outside: 172.16.1.100 to 172.18.1.200 ID=3 seq=3369   length=80 74: ICMP echo-reply: untranslating outside: 172.18.1.200 to inside:192.168.199.100 75: ICMP echo-reply from outside: 172.16.1.100 to 172.18.1.200 ID=4 seq=3369   length=80 76: ICMP echo-reply: untranslating outside: 172.18.1.200 to inside:192.168.199.100 

The reply packets are sent to the inside host, and the xlate entry is used to do it. Now imagine other possibilities in which an outside host could use various ICMP message types to annoy an inside host or communicate with a backdoor Trojan horse that has been installed. At the very least, the outside host could keep the xlate entry from ever idling out just by sending bogus ICMP packets toward the inside.

With PIX 7.x ICMP inspection enabled, the same test case is performed. A ping is sent from an inside host toward an outside target, and the firewall creates a dynamic PAT ICMP xlate entry. The firewall accepts only a single echo reply packet and closes the ICMP connection.

The xlate entry stays active for a full 30 seconds until it idles out. During that time, an outside host attempts to send ICMP traffic to the PAT address. The firewall immediately rejects the traffic because it doesn't match any of the ICMP state information that was originally recorded. As well, the ICMP connection has already been closed, and a new inbound connection is not created, even though the inbound access list has an entry that permits any ICMP traffic to any inside host.

The following Syslog information demonstrates this rejection and the follow-up by the firewall.

 Feb 22 2005 00:52:15 : %PIX-6-305011: Built dynamic ICMP translation from   inside:192.168.198.4/33 to outside:128.163.93.131/0 Feb 22 2005 00:52:15 : %PIX-6-302020: Built ICMP connection for faddr   128.163.93.129/0 gaddr 128.163.93.131/0 laddr 192.168.198.4/33 Feb 22 2005 00:52:15 : %PIX-6-302021: Teardown ICMP connection for faddr   128.163.93.129/0 gaddr 128.163.93.131/0 laddr 192.168.198.4/33 Feb 22 2005 00:52:21 : %PIX-3-106014: Deny inbound icmp src outside:128.163.93.129   dst outside:128.163.93.131 (type 8, code 0) Feb 22 2005 00:52:45 : %PIX-6-305012: Teardown dynamic ICMP translation from   inside:192.168.198.4/33 to outside:128.163.93.131/0 duration 0:00:30 

Notice that the ICMP connection was built and torn down within the same second of time, immediately after the echo reply was received. The last line shows that the xlate entry stayed active until the 30-second idle timer expired.

UDP Inspection

User Datagram Protocol (UDP) is also a connectionless protocol. A host might send unsolicited UDP packets to another without expecting any reply in return. This can occur with protocols such as Real-Time Transport Protocol (RTP) for voice traffic. However, some protocols such as DNS use UDP for a two-way exchange, but no actual connection is established.

For most UDP traffic, a firewall cannot examine or track the state of the information exchange. UDP is inspected only through the use of the xlate table, ACLs, and conn table entries. Even though UDP is connectionless, a Cisco firewall creates conn entries as pairs of hosts communicate with UDP packets. Figure 1-6 shows how a firewall reacts to handle UDP traffic between two hosts on different interfaces.

Figure 1-6. How a Firewall Handles UDP Traffic

In Figure 1-6, the hosts pass messages back and forth, as if there is a connection between them. Host PC-1 begins the session by sending a UDP packet to PC-2. If the ACLs applied to the firewall interfaces permit this traffic, the firewall proceeds to define a UDP connection. To forward the traffic, the firewall needs an existing xlate table entry or needs to create one.

With the first packet in the session, the firewall creates a new connection entry in the conn table. This entry identifies the source and destination addresses and UDP ports so that all packets that pass between the pair of hosts can be identified with this specific connection.

UDP packets can now be passed back and forth between PC-1 and PC-2. The firewall allows the connection to continue as long as packets pass through that connection. If no packets have passed through the connection before the UDP idle connection timer expires, the UDP connection is closed by being deleted from the conn table. By default, a UDP connection idles out after 2 minutes.

This means that UDP connections never close by themselves, because they have no mechanism to do so. Instead, any UDP connections that are created by a firewall must just wait to idle out and close.

You should be aware of one exception a Cisco firewall makes in how it handles UDP connections: DNS traffic usually occurs as one request from a host for a name resolution and one valid response from a DNS server. Naturally, a host might send several duplicate requests to several different DNS servers, and it might get back several responses. In the end, only one reply really matters to the requesting host.

Suppose a DNS server is on the inside of a firewall, and all DNS traffic (UDP port 53) is permitted to reach it from the outside. If an outside host sends a legitimate DNS request, the firewall creates a UDP connection entry. While that connection is open to the outside host, that host might have free access to begin pestering the DNS server with bogus requests until the server becomes overwhelmed. This activity could go on and on, as long as the UDP connection never becomes idle.

Likewise, a client on the inside might send a DNS request to a DNS server on the outside. The firewall would create a UDP connection between the client and server, permitting the legitimate DNS reply. While the connection is "open," other malicious hosts on the outside could spoof the source address of the DNS server, targeting the inside client as the destination. Any number of bogus DNS replies could be sent inward, bombarding the unsuspecting client.

A Cisco firewall implements a feature called DNS Guard that prevents this from happening. The firewall observes DNS requests that pass through it over UDP connections. After a request is forwarded, the firewall allows only the first DNS reply to return to the requesting host. All replies after that are dropped, and the UDP connection triggered by the DNS request is immediately closed or deleted.

As a part of the UDP fixup process, a firewall also inspects and reacts differently to certain predefined UDP protocols. Individual application inspection engines are available, providing additional security over that of the generic UDP inspection engine. Section 6-6, "Application Inspection," in Chapter 6 describes this in further detail.

TCP Inspection

TCP is a connection-oriented protocol. Before two hosts can exchange TCP traffic, they must perform a three-way handshake to establish a TCP connection. Then, as packets are exchanged, the connection state is always updated with parameters that tell the far-end host what data to expect and how much data can be returned. To close a TCP connection, the two hosts must perform a modified three-way handshake.

Because TCP is connection-oriented, a firewall can track the exact state of the information exchange at any given time. For each TCP connection, the firewall examines source and destination address and port pairs, along with the TCP sequence number, the acknowledgment value, and the TCP flags. Packets that have unexpected values can't be part of an existing connection, so the firewall drops them.

TCP connections are inspected through the use of the xlate table, ACLs, and conn table entries. The conn entries also have flags that reflect the current state of the TCP connections. For example, the state of the three-way handshake to initiate a connection is marked by flags that indicate which end sent the first SYN bit and which host is expecting the next SYN or SYN-ACK bit handshake. Like-wise, the handshake to close a TCP connection is tracked by the state of FIN bit exchanges.

Figure 1-7 shows how a firewall handles TCP traffic between two hosts on different interfaces. Here, the packet exchange between hosts PC-1 and PC-2 is a bit more complex than ICMP or UDP because of the orderly fashion in which TCP connections must progress to maintain their states.

Figure 1-7. How a Firewall Handles TCP Traffic

PC-1 initiates the TCP connection by sending a SYN bit in its packet to PC-2. The firewall creates a dynamic xlate entry if one does not already exist. As well, a new conn entry is created for the TCP connection between this pair of hosts. The firewall expects PC-2 to reply with a packet that has the SYN and ACK bits set.

At this point, the connection is only half-open, and it is considered an embryonic connection (not fully formed). If the SYN bit reply is not received within 30 seconds, the embryonic idle timer expires, and the connection is closed. Before PIX 7.x, the embryonic idle time was fixed at 30 seconds; beginning with PIX 7.x, it defaults to 30 seconds but can be configured.

Finally, PC-1 must also complete the three-way handshake by sending a packet with the ACK bit set. If this handshake is properly followed, the firewall begins allowing TCP packets to flow through the connection. Each of these packets is examined to see if the TCP sequence number, acknowledgment number, and flags are being updated with the expected values.

NOTE

When a TCP connection is initiated, a host sends the first SYN packet, along with an ISN so that the far-end host knows how to respond. The ISN value is sometimes predictable, giving malicious users on the outside the ability to hijack a connection by masquerading as the actual initiating host.

A Cisco firewall intercedes on behalf of the inside host when a TCP connection is initiated. When the first TCP packet is forwarded on the outside network, the firewall generates a random ISN value. For each connection, the firewall maintains a translation between the inside sequence number and the outside sequence number. This adds a level of security, because outside hosts can never guess the true TCP ISN values that the inside hosts are using.

TCP connections can close in several ways:

• The two hosts can send FIN bits to each other in a two-way handshake. The firewall tracks this exchange to be sure that the connection is behaving correctly.

• One host can send a reset (RST) bit, requesting that the far-end host close and delete the connection immediately.

• The firewall also maintains an idle timer for each connection. If no packets have been sent through the connection before the idle timer expires, the firewall immediately closes the connection and deletes it from its conn table. By default, the idle timeout is 60 minutes.

Additional TCP Connection Controls

One host begins a TCP connection with another host by sending it a TCP packet with the SYN flag. A malicious host can begin so many TCP connections with another host that the target host can run out of memory or resourceseven though none of the connections are actually established or completed. Each of the connections begins by having the SYN flag set, as if it were legitimate.

While an initial SYN packet goes unanswered with a SYN packet reply, the TCP connection is not yet established. As previously discussed, this condition is called an embryonic, or half-open, connection.

A Cisco firewall can monitor and control the number or volume of embryonic connections by watching the initial SYN packets that arrive on one interface, destined for a host on a different interface.

When the embryonic connection limit is exceeded, the firewall performs TCP intercept and acts as a proxy. The firewall intercepts the incoming SYN packet, and the connection state information is recorded in memory. The SYN isn't actually sent to the target host; instead, the firewall answers with a SYN packet reply on the target's behalf. If the source responds with a SYN-ACK packet, indicating that the connection is legitimate, the firewall sends a copy of the original SYN packet to the target. In effect, this delays the connection's formation but allows the target to become aware of a true connection request. The TCP three-way handshake can proceed to establish the connection.

NOTE

For inbound connections (from a lower-security interface to a higher-security interface), the embryonic connection limit is defined, along with the static xlate entry (the static configuration command). This can prevent a denial-of-service attack coming from the outside.

For outbound connections, the limit is defined along with the dynamic NAT or PAT xlate entry (the nat configuration command). This can prevent an attack coming from the inside, targeting hosts on the outside.

Finally, TCP connections that are established normally stay open until the two hosts exchange a two-way handshake of packets with the FIN flag set. If a FIN packet is sent but is not answered with another FIN packet, the TCP connection is in the half-closed state. A firewall can allow connections to remain in this state until the half-closed timer expires (the default is 10 minutes). After that occurs, the connection is deleted from the conn table without waiting for the handshake to complete.

TCP Normalization

Beginning with PIX 7.x, the TCP inspection engine can be configured to inspect and operate on several additional TCP parameters. TCP normalization is a feature that allows packet inspection based on configurable options defined in a modular service policy. This feature is covered in detail in section 6-5, "Defining Security Policies in a Modular Policy Framework," of Chapter 6.

You can enable the following types of TCP normalization inspection:

• Consistent retransmissions of TCP packets

• TCP checksum verification

• TCP maximum segment size (MSS) exceeded

• Misuse of TCP header reserved bits

• Packets with the SYN bit set while containing data

• Spoofed retransmission of packets dropped after time-to-live (TTL) expiration

• Handling of the TCP urgent flag

• Unexpected changes in TCP window values

• Handling of various TCP options

Other Firewall Operations

Cisco firewalls can also perform other functions while traffic is being inspected:

• Content filtering A firewall can work with external servers to permit or deny users' access to web content. Section 6-4, "Filtering Content," in Chapter 6 discusses this in further detail.

• Failover Two physical firewalls can operate as a failover pair, in which one of the two is always active. This provides greater availability in case one of the firewalls fails. Chapter 7, "Increasing Firewall Availability with Failover," covers failover in greater detail.

• DHCP A firewall can act as a DHCP client to receive dynamic IP addressing information from a service provider. It also can act as a DHCP server to provide dynamic information to a set of clients on a protected network. Section 3-3, "DHCP Server and Client," in Chapter 3, "Building Connectivity," covers this topic in further detail.

• Syslog A firewall can generate logging information about a wide variety of activity, to be collected by a logging server. Chapter 9, "Firewall Logging," covers Syslog functionality in greater detail.

• Management You can manage a Cisco firewall in a variety of ways. You can use Simple Network Management Protocol (SNMP) to query some firewall parameters and receive notifications. Also, several GUI front-end applications are available to help you configure and monitor firewalls. Chapter 4, "Firewall Management," covers these features in further detail.

• Packet capture A Cisco firewall can be configured to capture packets passing through an interface. This can be a useful troubleshooting tool or a way to examine specific traffic that is present in a network. Chapter 10 covers this and other troubleshooting tools in greater detail.

• Emulation of multiple firewalls Beginning with PIX 7.x or Firewall Services Module (FWSM) 2.2, a Cisco firewall can be configured to run multiple security contexts. Each context is an independent virtual firewall emulated on a single hardware platform. Section 4-1, "Using Security Contexts to Make Virtual Firewalls," in Chapter 4 discusses multiple-context mode in detail.