Traffic that traverses a network always has a source and destination address. This commun-ication is based on the seven layers of the OSI reference model. Layers 5 through 7 (the upper layers) handle the application data, and Layers 1 through 4 (lower layers) are responsible for moving the data from the source to the destination. The data is created at the application layer (Layer 7) on the source machine. Transport information is added to the upper-layer data, and then network information is added, followed by data-link information. At this point, the information is transmitted across the physical medium as electronic signals.
The upper-layer data combined with the transport information is called a segment. As soon as the network information is added to the segment, it is called a packet. The packet is encapsulated at the data link layer (Layer 2) with the addition of the source and destination
MAC address, at which point it is called a frame. Figure 5-1 shows how the data is encapsulated at each layer of the OSI reference model.
Figure 5-1 Encapsulation of Upper-Layer Data
The two transport protocols most commonly used by TCP/IP are Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). These protocols are very different. Each has its strengths and weaknesses. For this reason, they are used in different ways to play on their strengths:
■ TCP—A connection-oriented transport protocol that is responsible for reliability and efficiency of communication between nodes. TCP completes these tasks by creating connections as virtual circuits that act as two-way communications between the source and destination. TCP is very reliable and guarantees the delivery of data between nodes.
TCP also can dynamically modify a connection’s transmission variables based on changing network conditions. TCP sequence numbers and TCP acknowledgment numbers are included in the TCP header. These features allow the source and destination to verify the correct, orderly delivery of data. Unfortunately, the overhead required for TCP can make it slow and keeps it from being the optimum transport protocol for some connections.
■ UDP—A connectionless transport protocol that is used to get the data to the
destination. UDP provides no error checking, no error correction, and no verification of delivery. UDP defers the reliability issues to the upper-layer protocols and simply sends the data without verifying delivery. UDP is a very simple and very fast protocol.
The upper layers determine which of the transport protocols is used when data is encapsulated at the source node.
How the Cisco Security Appliance Handles Traffic 115
Figure 5-2 illustrates the TCP communication between nodes that do not have a firewall between them. The TCP “three-way handshake” is a four-step process that requires three different transmissions to negotiate the connection:
1. The source sends a segment to the destination, asking to open a TCP session. A TCP flag is set to SYN, indicating that the source wants to initiate synchronization or a
handshake. The source generates a random TCP sequence number. In this example, we will use 125.
2. The destination receives the request and sends back a reply with the TCP flags ACK and SYN set, indicating an acknowledgment of the SYN bit (receive flow) and initiation of the transmit flow. It generates and sends its own random TCP sequence number, 388, and replies to the original TCP sequence number by adding 1, sending back a sequence number of 126. The source receives the SYN/ACK and sends back an ACK to indicate the acknowledgment of the SYN for the setup of the receive flow. It adds 1 to the value of the TCP sequence number generated by the destination and sends back the number 389.
3. The acknowledgment is received, the handshake is complete, and the connection is established. Note in Figure 5-2 that the source begins to send data to the destination as soon as the connection is established.
Figure 5-2 TCP Communication Between Nodes Without a PIX Firewall
Source 10.10.10.10
Step 1
Step 3
Destination 192.168.1.1
Step 2
Step 4
Now look at how this communication is handled by the Cisco PIX Firewall (see Figure 5-3).
You first notice that the number of steps required for the same transaction has changed from four to eight and the number of transmissions has increased from three to six, although everything appears to be the same to both the source and destination.
Figure 5-3 TCP Communication Between Nodes with a PIX Firewall
The following is a list of actions taken by the Cisco PIX Firewall when processing a TCP handshake and opening a TCP session (refer to Figure 5-3):
1. The source machine initiates the connection by sending a packet with the SYN flag set.
It is a Cisco Security Appliance en route to the destination. The Security Appliance verifies the connection against the running configuration to determine if translation is to be completed. The running configuration is stored in memory, so this process occurs very quickly. The Security Appliance checks whether the inside address, 10.10.10.10, is to be translated to an outside address—in this case, 192.168.1.10. If the translation is to be completed, the Security Appliance creates a translation slot if one does not already exist for this connection.
2. All the session information is written to the state table, and the Cisco Security Appliance randomly generates a new TCP sequence number. This connection slot is marked in the state table as an embryonic (half-open) connection.
How the Cisco Security Appliance Handles Traffic 117
3. After the connection is verified against the security policy, the Security Appliance allows the connection outside using the translated source address and the newly generated TCP sequence number.
4. The destination receives the connection request (SYN) and replies with an SYN ACK.
5. The Security Appliance verifies the SYN ACK from the destination and matches the acknowledgment number against the randomly generated sequence number. It verifies the connection slot and forwards the connection back to the source using the original source address and original sequence number plus 1.
6. Any packets that do not match the session object exactly are dropped and logged.
7. The source completes the connection by responding with an ACK. The acknowledgment number is not randomized as it passes through the Security Appliance, and the
connection slot is marked as active-established.
8. The embryonic counter is reset, and data is transmitted between the nodes.
The process used by the Security Appliance to handle UDP traffic is completely different from the process that it uses for TCP traffic. This is due to UDP’s characteristics. UDP is a connectionless protocol that does not negotiate a connection. Without any setup or termination, it is very difficult to determine the state of a UDP session. Because of the inability to determine session state, it is very easy to spoof UDP packets and hijack a UDP session. Some applications use UDP rather than TCP for data transfer. Many of these are real-time applications or applications that either have no reliability requirements or have their reliability requirements handled by the application rather than by the transport protocol. These applications include network video, Common Internet File System (CIFS), NetBIOS, Domain Name System (DNS), and remote-procedure call (RPC) applications.
The default security policy allows UDP packets to pass from a higher security level to a lower security level. For UDP packets to pass in the other direction, they must be allowed by the security policy. It is very important to restrict inbound UDP access as much as possible. Due to UDP’s limitations, many applications that operate over UDP are targets for exploitation by hackers.
A Cisco Security Appliance handles UDP traffic in the following manner:
1. The source machine initiates the UDP connection. It is received by the Security Appliance en route to the destination. The Security Appliance applies the default rule and any necessary translation, creates a session object in the state table, and allows the connection to pass to the outside interface.
2. Any return traffic is matched with the session object, and the session timeout is applied.
The session timeout is 2 minutes by default. If the response does not match the session object or is not within the timeout, the packet is dropped. If everything matches, the response is allowed through to the requesting source.
3. Any inbound UDP sessions from a lower security level to a higher security level must be allowed by the security policy, or the connection is dropped.