An interesting feature which only receives a casual mention in the ASA classes that I teach is the TCP Map, an optional configurable component of the larger Modular Policy Framework.  We will cover the components of this highly granular feature in this article.

Before we examine the details of the TCP Map component, let’s briefly define the concept of “map”.  Briefly stated, a map is a collection of conditions which, when matched, result in actions taken by the device. On the Cisco IOS Router, for example, we have had route maps, crypto maps, and dialer maps for years – key features which have allowed for greater flexibility in packet path selection, encryption, and dial-on-demand routing, respectively.

The screenshot below shows the section inside of the ASA Service Policy Wizard where a TCP Map would be used.

Most of the subsections of this screen are well-documented; the Maximum Connections, Randomize Sequence Number, and TCP Timeout are features that have been present since early OS releases of the PIX Firewall. The Time to Live section should be configured with caution as a Security Advisory exists for this feature (see the references below). If the box for Use TCP Map is selected, the grayed-out area below becomes available for either selecting a previously configured map or clicking the New… button to take you to the screen shown below.

The checkboxes shown above, along with the options to allow/deny, are part of an overall TCP “normalization” feature of the ASA; this functionality is similar to what exists on the Cisco IPS sensors. A normalizer is also known as a “packet scrubber”; in other words, TCP packets that have flags or options set as they enter the ASA can have these cleared before they exit the ASA.

Before we explore the individual components of this screen, you should note that the PIX and ASA firewalls do TCP connection proxying; by default, the initial TCP sequence number in a connection request is randomized. As a result, a different set of sequence/acknowledgements will be seen on either side of the security appliance. An important parameter to consider with this is the Queue Limit, ranging in value from 0 to 250.

Below the queue we see the Reserved Bits section whose four bits should normally be set to 0; consequently, the default setting is “Clear and allow” which means that the TCP packet will be allowed to pass with the bits zeroed out. With the “Allow only” setting, the TCP packets are allowed to keep their reserved bit settings and with “Drop” the packets will be discarded.

Next we see a series of checkboxes of which three deal with unusual conditions:

  • Drop SYN packets with data
  • Drop packets that exceed maximum segment size
  • Clear urgent flag

The third of these is sometimes seen in implementations with out-of-band (OOB) data; this is occasionally seen with computers using BSD (Berkeley System Development) versions of Unix. The Drop Connection on Window Variation checkbox is associated with an IPS signature defined some years ago and noted below in the references. As the reference indicates, this condition is non-RFC compliant.

The Enable TTL evasion protection checkbox prevents an exploit whereby the attacker retransmits a packet with a different TTL to avoid intrusion prevention. As noted below, this feature should be used with caution, particularly with certain versions of code. The Verify TCP checksum will ensure that the TCP checksum is correct, avoiding problems with reception at the destination. Finally, the Check if retransmitted data is the same as original option could be used to reduce the number of unnecessary duplicate packets.

Author: Doug McKillip


In this article

Join the Conversation