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 10.1.1.1.
static (inside,outside) 10.1.1.1 10.1.1.1 netmask 255.255.255.255 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 10.1.1.1 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 10.1.1.1".
FWSM/context1/pri/act(config)# sho local-host 10.1.1.1
IPv4 local hosts:
local host: <10.1.1.1>, tcp conn(s)/limit = 0/100, embryonic(s)/limit = 50/50 udp conn(s)/limit = 0/0
Xlate(s):
Global 10.1.1.1 Local 10.1.1.1
We can see there are there are 0 legitimate TCP connections and 50 embryonic TCP connections to the host located at 10.1.1.1.
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.
