Introduction

At this point I have covered SYN Cookie from LTM perspective, in this article I will explain the important differences between LTM and AFM SYN Cookie.

LTM Vs AFM

AFM is a security platform, so it adds some extra options when configuring SYN Cookie that you cannot find in LTM. These additional abilities are added to AFM because in AFM SYN Cookie is just another DoS vector, so this allows you to configure characteristics reserved for DoS vectors. In fact AFM SYN Cookie is configured as a DoS vector called TCP Half Open.

It is very important to note that when LTM and AFM SYN Cookie are configured at the same time in your BIG-IP then AFM SYN Cookie will work since it has precedence:

Fig12. AFM Vs LTM

 

However, before starting describing SYN Cookie in AFM be aware that comparing to other DoS vectors TCP half open has a couple of limitations:

-       Blacklisting is not allowed.

-       TCP SYN flood attackers handled by SYN Cookie are not included in IPI

You have learned main details about LTM SYN Cookie, now the best way to see the advantages of AFM is by listing them:

• One of the most important advantages of AFM SYN Cookie is that it allows more granularity than LTM SYN Cookie since we can define a different threshold for each virtual server. This means that you can configure different SYN Cookie thresholds for each virtual server, for each VLAN and globally for the device. Remember that LTM SYN cookie only allows us to define a sole threshold for all virtual servers.

Fig13. AFM granularity

 

• AFM handles SYN Cookie as another DoS vector, so administration is easier since you do not need to create parallel configurations for different types of countermeasures.
• AFM whitelist is unified, there is only one whitelist for DoS and SYN cookie. This ease the security administration.
• TCP Half Open DoS vector also allows you to use Auto-Threshold, so you can rely on AFM in order to define the best threshold attending to your environment, after a learning period of course.
• AFM provides extra information about SYN Cookie in form of events and stats.

Logging

As I pointed out one of the important advantages of AFM is that it provides extra information about SYN Cookie. In order to get this information first you need to create a Security Log Profile and enable specific options in it:

 

Network firewall will provide specific SYN Cookie events, while DoS protection will provide DoS events for TCP Half open, as it does for any other DoS vector. But you will also get TCP half open stats automatically because AFM enables basic AVR under the hoods. So you will be able to see information in Dashboard.

Below tables shows the information you can check in GUI after enabling above options in security log profile:

 

Configuration

Let’s see how to configure SYN Cookie in different contexts for AFM as we did for LTM in previous article:

Device/Global context

Details about the context provided for LTM applies here as well. Also note that SYN cookie MUST be enabled in the protocol profile applied to virtual server in order to AFM Global SYN cookie take the virtual server into account when counting embryonic connections. Configuration options for typical LTM protocol profiles:

 

Remember that DSR whitelist is not the same than SYN Cookie whitelist. DSR whitelist is a special whitelist that automatically add legitimate clients to a temporal whitelist in order to allow SYN Cookie in DSR environments (see article 2 of this series). On the other hand, SYN Cookie whitelist is in fact a DoS whitelist where client’s IPs are added until you decide to remove them. During the time an IP is in this address list the client will not be matched against DoS vectors. Above table refers specifically to DSR whitelist.

Configuration options for TCP half open vector through TMSH are common to other vectors, but if you try to configure a non supported option then you will get an error. For example:

01071b13:3: DOS attack data (tcp-half-open): bad actor and auto blacklisting features do not apply to tcp-half-open vector.

Since we are working with DoS there are other options you can configure for this SYN Cookie vector, like auto-threshold, floors, multiplier, etc. but in this article I just want to describe the related SYN Cookie usage, so you can compare better with LTM version.

VLAN context

Details about this context described for LTM applies here.

(*) Be aware of ID993269.

 

At this point it is important to give more details about the difference between mitigating a TCP SYN flood attack by using TCP SYN flood DoS vector or by using SYN Cookie. TCP SYN flood vector will just count the number of TCP SYN packets that reach the specific context where it is configured, if this counter value exceeds the threshold that you configured for the SYN Flood vector, then SYN packets will be dropped until counter value is under the threshold again. As you can guess this could disrupt legitimate traffic during the attack. Sometimes this is better than lose totally an application but you need to configure this with care and always as a last resort.

On the other hand, SYN Cookie will not drop any connection unless connection comes from an attacker.

Virtual server context

Details about the context described for LTM applies here. Example for a virtual server using a TCP profile:

 

Conclusion

Now you know the difference between SYN Cookie LTM and AFM. Clearly AFM has more versatility, so it could be interesting thinking in moving SYN Cookie configuration from LTM to AFM if we have this module licensed. Configuration will be centralized and might be clearer if you are get used to work with security DoS vectors.

In next article I will write about the differences between hardware and software when working with SYN Cookie.