Introduction
In previous articles I have explained why it is so important to implement TCP SYN Cookie in order to protect exposed applications. In this article I will explain when SYN Cookie is activated and different aspects you should take into account when you configure it in LTM.
SYN cache
You know how SYN Cookie works in broad strokes, so now the pending question about implementation is to know when BIG-IP should activate SYN Cookie countermeasure. This is where security administrators come into play.
Commonly SYN Cookie implementation works together with another countermeasure called SYN cache. SYN cache is based in the use of a cache for incomplete TCBs, this allows devices to save some resources comparing with standard TCP connection because full state allocation for TCB is delayed until the TCP 3WHS has been fully finished. I will not describe detailed functioning of SYN cache here but just note that this method could increase time to establish legitimate TCP connections in 15%.
BIG-IP does not use a cache as is, instead it uses a TCP embryonic connection counter, if BIG-IP detects that the number of embryonic connections have been exceeded attending to a configured threshold then SYN Cookie is activated. This is more efficient than typical SYN cache implementation since it does not add any delay by creating incomplete TCBs prior to complete TCP 3WHS. Also, it does not need to allocate memory for these incomplete TCBs.
The process of SYN Cookie activation can be described as below:
Fig7. TCP SYN Flood attack + SYN Cache
Our only task as Security Administrators is defining the best threshold for this counter. It is very important that threshold fits perfectly in your environment and there are two main reasons for it:
- Depending on our BIG-IP device platform SYN Cookie can be implemented in hardware or in software, if our device has not hardware offloading capability for SYN Cookie then the SYN Cookie process described in second article of this series must be run in TMM, that is, in software. Although the process is optimised there will be a slight penalty in CPU usage during an attack since TMM will have to create SYN Cookie challenges and validate client responses. This should not affect normal functioning of the device but it is relevant to take this into account since not always customer has a perfect BIG-IP sizing. So it is important to distinguish between a real attack or a wrong configured threshold, and avoid extra load to your devices by setting a correct SYN Cache value.
- As you will see with more detail in later articles in this series, activating SYN Cookie can have some consequences due to how SYN Cookie is implemented, not specifically in BIG-IP devices, but SYN Cookie standard in general. One important drawback is the limited space used for the SYN Cookie challenge which, as explained in previous article, it will limit the possible MSS sizes and also will remove some TCP options information (unless TCP Timestamp is used). This could cause some impact by slowing down the traffic between client and backend server when SYN Cookie is active. However, note something very important, SYN Cookie is only activated when under attack if it is correctly configured, so the possible choices during an attack are disruption if no countermeasure is configured or, in the worst cases, having a minimum impact in performance until attack is finished. Also, if SYN Cookie is correctly configured it should be only activated specifically on virtual servers under attack, so usually you will not notice any issue.
Although F5 Networks creates a default configuration for SYN cache, that you will read about in the next article, the value that better fits with your environment is the value you define attending to expected traffic patterns, and you have the best knowledge of your network.
Operation
As a short summary you can check below flow diagram where the most important steps are shown, so you can have at a glance a global idea about what it happens when SYN cache is exceeded in a TMM and hence SYN Cookie is activated in hardware or software for this TMM.
There are some important points to note:
- To prevent oscillation (activating/deactivating SYN Cookie loop), the entry/exit strategy from SYN cookie mode have some hysteresis. This is determined by several factors like the round-trip time, rate of SYN arrival, the 'exit' threshold, the value of the SYN cache,… This will avoid entering and exiting SYN Cookie continuously during an attack if the number of TCP SYN packets per second for this attack is near to the configured SYN Cache threshold.
- From TMOS v13 you can stop to challenge a source IP during some seconds if the client response with a successful challenge response, that is, if client is trustworthy This is detailed in next article where configuration is treated.
- By checking diagram above you will notice that regardless if Hardware or Software SYN Cookie is enabled we see TMM always rejecting connections. This is because hardware only generates and validates SYN Cookies but it never drops connections. This is important when we check SYN Cookie stats as you will see in future article.
Conclusion
At this point you have a clear knowledge of SYN Cookie and SYN Cache countermeasures and how they are implemented in BIG-IP. In next articles we will start to talk about configurations and troubleshooting.