Introduction
Since you already know how SYN Cookie works now it is time to start configuring BIG-IP devices. In this article I explain how to configure BIG-IP LTM devices for protecting against TCP SYN flood attack at different contexts.
Configuration
BIG-IP is an application focused device, so from security perspective is in charge of protecting these applications, but it is also important to protect BIG-IP itself since compromising it means that all applications could be affected. This is why SYN Cookie can be configured not only for protecting applications but also for protecting whole BIG-IP, and even for protecting specific VLANs connected to BIG-IP.
In this section I will explain how to configure SYN Cookie for each context.
Device/Global
At this context we protect BIG-IP itself, so the idea is defining how many embryonic connections are allowed to be handled by BIG-IP TCP stack, regardless virtual server destination. This means that SYN Cache counter will increase for each embryonic connection that device is handling globally.
Since TMM is the core of the BIG-IP, the element that manipulate traffic, it makes sense to protect each TMM specifically. This is why SYN Cache at global context is defined per TMM. So for example, configuring a value of 1000 in a 4 TMM device means that the Big-IP will potentially (if connections are evenly balanced among TMMs) handle 4000 embryonic connections before activating SYN Cookie.
Fig9. Device context
SYN cookie will take into account all TCP SYN packets sent to any listener exposed, this includes also selfIPs and virtual servers, but note that it MUST be enabled in the protocol profile applied to virtual server (which is in fact the default value) in order to Global SYN cookie take the specific virtual server into account when counting embryonic connections. Configuration example for a device with one virtual server using a tcp profile:
VLAN context
The threshold is defined per TMM as in device context . This is only available for SYN Cookie hardware offloading platforms. See related AskF5 article for more details.
With this feature you can protect a group of virtual servers listening in the same VLAN. Reasons why you would want to do this can vary, from architecture perspective you could have a dedicated VLAN serving applications on old servers and therefore expecting lower number of connections for example. Or you could want to configure SYN Cookie in a more granular way instead configuring a global value for whole device.
In older versions also there could be a risk of collisions when multiple virtual servers were under attack at the same time, so using this method instead SYN Cookie per virtual could help in these cases.
If SYN Cookie is enabled at Global context the SYN Cookie Per-VLAN is disabled because Device protection is ON at all-VLAN basis and it would interfere with Per VLAN SYN cookie.
Fig10. VLAN context
At VLAN context you can configure not only SYN Cookie but also TCP SYN flood DDoS vector, even with only LTM license. It is important to note that setting a threshold for this vector could have consequences, unlike SYN Cookie, this vector will start to drop TCP SYN packets once the configured number of TCP SYN packets per second is reached. This is because TCP SYN flood vector just counts TCP SYN packets reaching the VLAN, instead embryonic connections, and if a TCP SYN packet exceeds the threshold then it is just dropped. TCP SYN flood and TCP SYN Cookie are totally different and independent countermeasures.
Virtual server context
In this case the threshold is defined globally. This means that the value is defined for all TMMs, unlike SYN Cookie at Device/VLAN context. If you want to know how many embryonic connections will be handled by each TMM prior the TMM activates SYN Cookie then you must divide configured threshold among the number of existing TMMs.
When configuring SYN Cookie in a LTM device you only can define a general threshold that it will be common for all virtual servers (in next article I will show differences with AFM SYN Cookie). So all virtual servers will have the same threshold.
Fig11. Virtual Server context
Configuring SYN Cookie at this context requires setting a common threshold for all virtual servers but also you MUST enable SYN Cookie in specific protocol profile that is applied to the virtual server in order to be able to enable the countermeasure for that virtual server. This will allow you to enable SYN Cookie in some virtual servers and disable it in others. Although you cannot have specific SYN Cache threshold for a virtual server, you can have different SYN Cookie behaviours depending on virtual server, like for example using whitelist or not (see second table below).
Example for fastL4 configuration:
Note that in protocol profile you could still have see twp options in TMSH that are deprecated from version 13 and have no effect anymore. They will be removed in a future release:
tmsh modify ltm profile fastl4 fastL4 hardware-syn-cookie <value> tmsh modify ltm profile fastl4 fastL4 software-syn-cookie <value>
As you can see in table above, as part of DSR configuration you can decide the device that will send the RST to the TCP connection:
tmsh modify ltm profile fastl4 <name> syn-cookie-dsr-flow-reset-by <bigip | client | none>
Sometimes it could be better choosing ‘client’ since some applications do not like Big-IP sending the reset. In order to get this, Big-IP sends the SYN Cookie in the ACK instead than in the sequence number, in this way client will RST the connection for this specific ACK, so when Big-IP gets the RST knows about the referred connection and it adds it into DSR whitelist.
SYN Cookie can work in two different modes at this context. Example for tcp protocol profile:
In case you have wildcard virtual servers and you want to protect them with SYN Cookie at virtual server context, then you will have to configure Software SYN Cookie unless you have a Neuron capable platform. I will give more details about this in next articles.
Default values
In TMOS versions higher than v12 we have the below default values:
Three comments related to above values.
- DB Key pvasyncookies.virtual.maxsyncache is deprecated in version >v12. This means that you should ignore the value of this DB Key whatever it is, since it is not used anymore by the system.
- Reason why we disable SYN Cookie at virtual server context when device is installed from scratch, is that we do not know the capacity of the pool members attached to virtual servers, so we let that value be disabled for customers to decide this threshold. However after upgrade from v12 we do not want to modify whatever behaviour security administrator considered correct in v12, so we just keep the value.
- At virtual server context SYN Cookie threshold in TMOS ≤v12 was set per TMM. In TMOS >v12 we define this value globally, as explained above in this same article. This is why threshold after upgrade is calculated as the existing value configured in v12 multiplied by the number of TMMs. In this way we keep the same value, so customer will not notice any change in the behaviour of their device.
But note that there are also a couple of things to take into account when upgrading from v12.x currently:
- If virtual server threshold in v12 (DB key pvasyncookies.virtual.maxsyncache) was < 4095 then value will be the same in >v12 after upgrade.
- If virtual server threshold in v12 (DB key pvasyncookies.virtual.maxsyncache) was ≥ 4095 then value after upgrade to ≥v12 will be 8192.
This behaviour it is being improved for new versions, so threshold will be kept regardless its original value, as I have commented.
Conclusion
You know how to configure SYN Cookie in LTM module based system, in next article I will explain differences between LTM and AFM SYN Cookie, so you will be aware of the limitations of each one and have a global perspective of the feature.
