6. SYN Cookie: Hardware vs Software
Introduction Currently, you know the differences between LTM and AFM when talking about SYN Cookie capabilities and configuration. In this article I describe how SYN Cookie can perform its tasks using two different ways, in software or offloaded in hardware. The most important difference between these functioning modes is clearly the resource consuming. In hardware based platforms SYN Cookie is a countermeasure that will not consume extra memory nor CPU, while in software this task must be handled by TMM, so some load could be added comparing to normal operation. Hardware SYN Cookie If you have a hardware offloading capable platform and you configure SYN Cookie to work in hardware, the creation and validation of SYN Cookie challenges will be managed by dedicated FPGA (Programmable Field Array) or NSP (Neuron Search Processor) In a few words this means that SYN Cookie running in hardware basically allows you to forget about TCP SYN flood attacks. You do not have to care about it, if it is correctly configured, since BIG-IP will not only mitigate attack without impacting legitimate users, who will still access to application during the attack, but also no extra resources will be needed. The only handicap you have to take into account currently when hardware SYN Cookie is activated is that you cannot keep TCP options information. In order to keep this information you need to enable SYN Cookie in software and client connection need to activate TCP TS option (this is enabled by default in BIG-IP). See second article in this series for more details (SYN Cookie Operation). Neuron Platforms shipped with Neuron chip and running a TMOS version greater than 14, improve performance because this chip, which is directly connected to HSBe2, provide with extra functionalities to SYN Cookie. Neuron improves performance and solves limitations that you could find in HSBe2 only platforms when SYN Cookie is activated for wildcard virtual servers. A brief description of this limitation can be found in K50955355. Note that Neuron does not only offloads SYN Cookie tasks from software, if you have an AFM provisioned device you can take advantage of other features like extended whitelists and blacklists in hardware. However these article series are only focused on SYN Cookie. With this in mind the functioning of Neuron is simple, HSBe2 makes requests to Neuron when a TCP SYN reaches BIG-IP, and depending of the type of request Neuron then will create a SYN Cookie for the connection or it will validate SYN Cookie response presented by client. For example, as I showed in previous articles, when an ACK comes from a client then HSBe2 will ask Neuron if SYN Cookie is correct, then Neuron will response with the requested information, so TMM will know if it must drop or allow the connection through the datapath. SYN Cookie Neuron does not offload AFM Global SYN Cookie, it works for: LTM Global SYN Cookie Per VLAN SYN Cookie LTM Per Virtual SYN Cookie AFM Per Virtual SYN Cookie In order to enable SYN Cookie Neuron in your platform you need to activate the Turboflex profile for Security/Securityv1 (AFM) or ADC (LTM). There is many literature in AskF5 about Turboflex, but in a few words it allows you to group several related features to be accelerated in hardware. I will not give technical details about Neuron since it is not the intention of these article series. For troubleshooting issues with Neuron please raise a case to F5 Networks, so expert engineer can investigate it. Making internal changes to Neuron could lead to a worst result. Disabling SYN Cookie SYN Cookie is enabled by default in software and hardware, if we disable hardware SYN Cookie then software SYN Cookie comes into play. There is a DB key for disabling Hardware SYN Cookie in all contexts: tmsh list sys db pvasyncookies.enabled sys db pvasyncookies.enabled { value "false" } Of course, if the specific platform cannot offload SYN Cookie into hardware then above DB key has no effect. In this case software SYN Cookie is enabled by default. There is not such DB key for enabling/disabling software SYN Cookie as we have for hardware, instead, if you want to disable software SYN Cookie then you have different options depending on context that you can consult in table below. Remember that AFM SYN Cookie has precedence over LTM SYN Cookie, this means that if AFM SYN Cookie is configured and you want to disable completely SYN Cookie you need to disable both, AFM and LTM SYN Cookie. The simplest path to disable completely SYN Cookie assuming default config, that is, hardware SYN Cookie is enabled, it would be: Fig14. Disabling SYN Cookie In table below I summarize how to disable hardware and software SYN Cookie in each context for the different scopes. For AFM disabling SYN Cookie is quite easier, you just need to change DoS Device and DoS profiles TCP Half Open vector to 0/Infinite. Warnings It can be possible that SYN Cookie works in software in your device whilst you expected SYN Cookie working in hardware. Sometimes you end up in this situation due to a wrong configuration. Below I make a list of possible reasons that you can check: You have disabled autolasthop. This option must be enabled if you want to offload SYN Cookie into hardware (K16887). You have changed DB key connection.syncookies.algorithm manually. This key defines which algorithm is used for generating hash that is part of the SYN Cookie challenge (as I described in the first article of this series). When set a value of Hardware to this DB key the error detecting code used for validating the hash will be understood by both, software and hardware. If set to Software then it will only be understood by software. If your version also has the option ‘both’, this means that BIG-IP dynamically discovers which algorithm should be used rather than forcing to Software or Hardware. In summary, if virtual is configured for hardware SYN Cookie but algorithm is configured in software then hardware will inspect SYN Cookies, it will confirm it cannot validate them and then it will send it to TMM for validation. Until v14.1 SYN cookie hardware it is not recommended for protecting networks (wildcard virtual servers), this is because SYN Cookie will only protect a single flood network destination when flooding towards multiple network destination at a time. The other networks will be protected by software SYN cookie. This could cause unexpected extra CPU utilization. This is greatly improved in Neuron capable platforms. If there are collisions when SYN Cookie is configured in hardware you will still see non zero stats for software SYN Cookie. Also, these stats can increase due to validation of first challenges, when SYN Cookie is activated, and TMMs handles TCP SYN until it enables hardware to do it. This is expected and it does not mean that hardware SYN Cookie is not working. I will show examples in article dedicated to stats. In order to end up this section with clear ideas, remember that hardware SYN Cookie and hardware flow acceleration are two different concepts. Conclusion In this article you learnt how behaves SYN Cookie when working in software and hardware and the advantages or disadvantages. In next two articles I will show you how to troubleshoot SYN Cookie issues.5. SYN Cookie: LTM Vs AFM
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 learnedmain 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.3. SYN Cookie: SYN Cache
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 attackis 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 successfulchallenge 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.
