Adaptive Security Algorithm

Adaptive Security Algorithm (ASA) is the foundation on which the PIX Firewall is built. It defines how PIX examines traffic passing through it and applies various rules to it. The basic concept behind ASA is to keep track of the various connections being formed from the networks behind the PIX to the public network. Based on the information collected about these connections, ASA allows packets to come back into the private network through the firewall. All other traffic destined for the private network and coming to the firewall is blocked.

ASA also defines the information PIX saves for any given connection made through it (this is called state information in the case where TCP is being used as the transport protocol). It can include a variety of information from the IP and the transport headers. The ASA algorithm also defines how the state and other information is used to track the sessions passing through the PIX. To achieve this behavior, PIX keeps track of the following information:

• IP packet source and destination information

• TCP sequence numbers and additional TCP flags

• UDP packet flow and timers

The following sections discuss how ASA deals with the TCP and UDP traffic passing through the PIX Firewall.

TCP is relatively easy to inspect, because it is connection-oriented. All the firewall has to do is keep track of each session being formed, utilized, and terminated. ASA only allows for the packets conforming to the state, in which the firewall believes the connection should be in, to go through the firewall. All other packets are dropped. However, TCP has a couple of inherent weaknesses that require ASA to perform a few modifications on the TCP packets passing through it to ensure security:

• The Initial Sequence Number (ISN) generated by TCP for its connections is not random. This can result in TCP session hijacking (see case study in Chapter 14, "What Is Intrusion Detection?," for an example of how this can be done). The ASA algorithm takes care of this problem by calculating a more random sequence number, inputting this number as the sequence number in the outgoing packets and storing the difference between the two random numbers. When return traffic for that particular packet is received, it replaces the changed sequence number with the correct one before forwarding the packet to the host on the inside private network.

• SYN flooding is a reality in TCP environments. To somewhat mitigate the problem of SYN floods occurring for servers sitting behind the firewall, ASA keeps track of the synchronization requests coming in through the firewall. If the synchronization does not result in a full-blown session in a given amount of time and/or the number of such half-open sessions increases beyond a certain limit (both are configurable), the firewall starts closing such connections.

A recent enhancement to the PIX ASA implementation (in version 5.2 and later) causes the PIX to proxy for connection attempts to servers or other resources sitting behind it (SYNs) after the number of incomplete connections through the PIX reaches a configurable limit (a limit on embryonic connections). The PIX responds to SYN requests with SYN ACKs and continues proxying the connection until the three-way TCP handshake is complete. After that, it allows the connection through to the server or resource sitting behind it on the private or DMZ network. This way, only legitimate connections are allowed to be made through the PIX, and the rest are dropped based on configurable timeouts on the PIX. This is an important feature, because it limits the exposure of the servers sitting behind the PIX to SYN floods.

Figures 8-1 and 8-2 are a step-by-step overview of how a TCP connection through the PIX is handled. Figure 8-1 illustrates the TCP transmission (initialization) process and Figure 8-2 illustrates the TCP termination process.

Figure 8-1 shows the sequence of events that take place as a host sitting behind the PIX initiates a TCP connection to the outside world. The SYN packet from the host is used to create the connection entry in the PIX because this is the first packet for the connection that this host is initiating. The PIX creates the entry after examining the rules set up for such an entry to be created. The PIX performs the necessary address translation on the packet and forwards it after saving the packet's state information—the IP addresses, the port information, the TCP flags, and the sequence number. The PIX also further randomizes the sequence number before forwarding it. PIX keeps track of the delta in the original and the new sequence number so that it can restore it in the return packet.

Figure 8-1 TCP Initiation and Transmission

Private Network

Source Addr Dest Addr Source Port Dest Port Initial Seq. # Ack Flag

200.150.50.11

1026_

49091

1026

92513

49092

Syn-Ack

No Data

1026

92513

49092

Syn-Ack

= TCP Header = IP Header

PIX Checks Whether a Translation Exists or Not. If not, It Creates One Upon Verifying NAT, Global Pool, Access Control and Authentication or Authorization, If Any. If OK, a Connection Is Created.

Start the embryonic

Connection Counter.

PIX Follows Adaptive Security Algorithm:

• Sequence Number Check

• Translation Check

If the Code Bit Is Not Syn-Ack, PIX Drops the Packet.

Public Network

192.150.50.24_

200.150.50.11_

1026_

49769

200.150.50.11

200.150.50.11 192.150.50.24

1026

92513

49770

200.150.50.11

Syn-Ack

The return traffic sent to the host arrives at the PIX with the TCP flag set to SYN-ACK and the sequence number incremented by 1. PIX ASA looks through its state information tables and verifies that the information provided by this packet is what it would have expected from a return packet to the one that was originally sent. Because this is indeed the case, PIX changes the sequence number to take out the change it had made while randomizing the sequence number of the initial packet that was sent out, modifies the IP addresses and port information in accordance with its NAT tables, and forwards the packet on to the host that originated the first packet.

After the TCP initial three way handshake is complete, PIX tracks the packet flow for the TCP connection established through it, allowing only legitimate packets belonging to the flow to come back.

Figure 8-2 shows how the PIX ASA processes a TCP termination. After the host has completed exchanging information and wants to terminate the TCP connection, it sends a TCP packet with the flag set to FIN. This signals the end of the connection to the remote host to which it was connected. ASA sees the FIN packet passing through and waits for the FIN-ACK to arrive. After this happens, it closes the connection.

Figure 8-2 TCP Termination

Private Network

Source Addr Dest Addr Source Port Dest Port Initial Seq. # Ack Flag

200.150.50.11

1026

59005

98097

1026

98097

59006

FIN-Ack

No data

1026

98097

59006

FIN-Ack

= TCP Header = IP Header

After FIN-Ack Bit Is Received, PIX Will Close This Connection. Any Packet, If Any, From 200.150.50.11 Will Be Silently Dropped.

Public Network

192.150.50.24

200.150.50.11

1026

59765

98097

200.150.50.11

200.150.50.11 192.150.50.24

1026

98097

59766

FIN-Ack

UDP is more difficult to track through a firewall. It is connectionless, and no state machine is involved that would allow the ASA to determine the initiator of a connection or the current state. ASA consequently tracks UDP sessions based on a timer. Whenever a UDP session is generated through the PIX, ASA creates a connection slot based on the source and destination IP addresses and port numbers in the packet and starts a timer. All return traffic for that particular connection slot is allowed to go through until the timer expires.

This timer, which is an idle timer, expires when no UDP traffic flows through the PIX in a certain UDP session for a configurable amount of time. Although this allows some amount of security, the control is not as rigid as in TCP processing.

Figure 8-3 is a step-by-step overview of how a UDP session is processed by the ASA through a PIX Firewall.

Figure 8-3 UDP Transmission

Private Network

Public Network

Source Addr Dest Addr Source Port Dest Port

Figure 8-3 UDP Transmission

Source Addr Dest Addr Source Port Dest Port

= TCP Header = IP Header

The Firewall Checks For a Translation Slot. If Not Present, the Firewall Creates One After Verifying NAT, Global, Access Control, and Authentication or Authorization, If Any. If OK, a Connection Is Created.

All UDP Responses Arrive From Outside and Within UDP User-Configurable Timeout (Default = 2 Minutes).

(Src IP, Src Port, Dest IP, Dest Port) Check

Translation Check

= TCP Header = IP Header

0 0

Post a comment