Showing results for 
Search instead for 
Did you mean: 
Rama Darbha

The FWSM is capable of using TCP intercept to defend against certain types of SYN floods. This feature was introduced way back during the days of FWSM version 1.1.

What is a SYN flood?

A SYN flood is a form of denial of service (DOS) attack in which an attacker sends a succession of SYN requests to a targeted victim. After the victim responds with a SYN+ACK, the attacker never responds with an ACK to this connection request. As a result, this connection is considered "embryonic" (aka, half-open) since it is never completed. It remains as an open socket on the victim. If enough of these sockets are opened, the victim will no longer be able to establish new connections.

Since firewalls are stateful devices, they track the state of connections. As a result, they will also see the connection as embryonic. Luckily, some firewalls have certain attack mitigation features that can limit the number of SYN packets on a per client bases. Therefore, protecting the internal servers from this type of behaviour.

What is TCP intercept and SYN cookies?

TCP intercept is a feature on the FWSM where the firewall will intercept inbound TCP connection attempts. Its proxies the SYN+ACK on behalf of the internal server in order to validate the legitimacy of the connection initiator. SYN cookies are the proxied SYN+ACK packets by the firewall. SYN cookies are a special feature that prevents a server from dropping packets after its SYN queue is full. The server responds with a SYN+ACK and throws away the SYN packet. If a subsequent ACK is returned from the client, the entire connection is then rebuilt from that ACK. In the case of the FWSM, it proxies the responisiblities of the server.

Configuring TCP intercept and SYN cookies on the FWSM

TCP intercept can only be configured on the FWSM through a translation configuration. Below is an example where the connection limit is set to 100 and the embryonic connection limit has been set to 50 for the host at

static (inside,outside) netmask tcp 100 50

If a subnet is used instead of a host in the above static configuration, the TCP per connection limits are applied to each host in the subnet.

How the FWSM performs TCP intercept and SYN cookies

The FWSM must hit the embryonic connection limit before TCP intercept is engaged. Using the above configuration, the FWSM must see 50 embryonic connections to a specific host located at before TCP intercept is engaged.

Once TCP intercept is enabled, you will see the counter labeled  "SYN_COOKIE: Total number of Syn Cookie Entries inserted by NP3"  increase. This is a counter that shows that NP3 has informed NP1/NP2 to  engage TCP intercept and use SYN cookies to prevent a possible attack. This counter increases once we see the 51st SYN packet.

Every time NP1/NP2 intercept a TCP connection attempt and respond with a  SYN+ACK (ie. a SYN cookie), we will increment the counter labeled  "SYN_COOKIE: Total number of SYNs intercepted".

SYN cookies will be engaged as long as the embryonic limit is exceed for the host. The current embryonic state can be viewed using the output of "show local-host".

FWSM/context1/pri/act(config)# sho local-host
IPv4 local hosts:
local host: <>, tcp conn(s)/limit = 0/100, embryonic(s)/limit = 50/50 udp conn(s)/limit = 0/0
    Global Local

We can see there are there are 0 legitimate TCP connections and 50 embryonic TCP connections to the host located at

Interpreting the Output of "show np 1 syn-cookies"
Below is the output that shows SYN cookie activity on the FWSM with the feature enabled.

FWSM/context1/pri/act(config)# show np 1 syn-cookie
             Fast Path Syn Cookie Statistics Counters (NP-1)                 
SYN_COOKIE: Syn cookie secret wheel index                        : 12
SYN_COOKIE: Total number of SYNs intercepted                     : 20 <-- There were 20 total SYN packets seen since SYN cookies were engaged
SYN_COOKIE: Total number of ACKs intercepted                     : 7 <-- There were 7 ACKs returned to a preexisting SYN+ACK since SYN cookies were engaged
SYN_COOKIE: Total number of ACKs dropped after lookup            : 0

SYN_COOKIE: Total number of ACKs successfully validated          : 7  <-- There were 7 successful ACKs, which  means 7 successful legitimateconnections since SYN cookies were triggered
SYN_COOKIE: Total number of ACKs Dropped: Secret Expired         : 13 <-- There were 13 connections where an ACK was not seen
SYN_COOKIE: Total number of ACKs Dropped: Invalid Sequence       : 0
SYN_COOKIE: Total number of Syn Cookie Entries inserted by NP3   : 1  <-- The FWSM crossed the embryonic connection limit threshold once
SYN_COOKIE: ACKs dropped: Syn cookie ses not yet established     : 0
SYN_COOKIE: Leaf allocation failed                               : 0
SYN_COOKIE: Leaf insertion failed                                : 0

The above shows that TCP intercept was engaged. We can see in the above that the embryonic connection limit threshold was crossed only once. Since it was crossed, there have been a total of 20 total SYN packets seen to a host who's embryonic limit is exceeded. Of these 20 total SYN packets, 7 were legitimate connections and 13 were connections where an ACK was never seen. You can use these numbers to assess the severity of the attack based on the number of legitimate requests.

The configured embryonic connection limit is applied to each NP. So in our example, NP1 and NP2 will allow 50 embryonic connnections each before TCP intercept is engaged.

Utilizing "show perfmon"

This command can be used to view the rate at which inbound connections are being intercepted by the TCP intercept feature.

FWSM/context1/pri/act# sho perfmon

Context: context1
PERFMON STATS:    Current      Average
Xlates               0/s          0/s
Connections          0/s          0/s
TCP Conns            0/s          0/s
UDP Conns            0/s          0/s
URL Access           0/s          0/s
URL Server Req       0/s          0/s
TCP Fixup            0/s          0/s
HTTP Fixup           0/s          0/s
FTP Fixup            0/s          0/s
AAA Authen           0/s          0/s
AAA Author           0/s          0/s
AAA Account          0/s          0/s
TCP Intercept        10/s          0/s

On the FWSM, there is no way to use "show perfmon" to separate the number of legitimate connections from bogus connections. Use the output of "show np 1 syn-cookies" to compare

Additional Notes

1. SYN Cookies will only be effective if NP1 and NP2 are not oversubscribed.
2. SYN Cookies will only be effective if there are already enough active  embryonic connections to the victim. If you want TCP intercept to always be engaged, you may need to manually initiate this limit.

3. SYN Cookies do not preserve TCP options.


Excellent intformation


Antoher awesome doc! radarbha, you are really spoiling us! :-)

Sorry if this Q is a bit newbie, but does this cause a hit on the CPU??

Thank you, I am sure that I speak for many others that are trying to learn about these wonderful devices, that this information is priceless.

Rama Darbha

Golly Wog,

SYN cookies will not affect CPU. If you refer back to the doc:

You'll see that TCP intercept is performed at NP3 while SYN cookies are performed at NP1 and NP2. That means that the TCP intercept feature will be initiated by NP3, and when the connection is validated the two sides of the connection are put together on NP3. Since none of the traffic is even seen by the Control Point, there should be minimal CPU impact due to this feature.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: