ddos

145 Topics

BIG-IP Next SPK: a Kubernetes native ingress and egress gateway for Telco workloads
BIG-IP Next SPK: a Kubernetes native ingress and egress gateway for Telco workloads that is CNF agnostic.
Ulises_Alonso
Oct 27, 2024 Place Technical Articles
2.8KViews
5likes
1Comment
DevCentral Top 5: Sep 8, 2014
But soft! What light through yonder window breaks? It is the east, and this week's edition of the DevCentral Top 5 is the sun. Yep, you guessed it. The top 5 is back...but unlike Shakespeare's Romeo and Juliet, this is no tragedy. Rather, it's a celebration of the most awesome articles you'll read anywhere on the Internet. Our DevCentral authors have been writing with freakish speed and determination, and they have turned out quality articles that are simply second to none. Choosing only five articles was a tough task given all the great content out there, but here's my take on the top articles since our last posting. F5 SOC Malware Summary Report: Neverquest I literally could have chosen five Lori MacVittie articles for this "top 5" but I resisted the urge and only chose one. In this article, Lori explains the details of a Trojan known as "Neverquest" that has been active since July 2013. Most of us get that warm, fuzzy, secure feeling when using 2-factor authentication because, you know, it's got 2 factors! Maybe automated malware has a shot at cracking one factor, but two? No way. Well, apparently Neverquest has found a way to automate the demise of our beloved 2FA. Lori does a magnificent job of explaining how Neverquest works, and then she discusses the amazing work that was completed by our F5 Security Operations Center in their analysis of this malware (in case you didn't know, F5 has a Security Operations Center that analyzes malware like this and provides amazing reports that are free for anyone to read). Lori provides links to the downloads of the executive summary as well as the full technical analysis of Neverquest. This one is not optional...if you care about anything at all, you gotta read this one. Leveraging BIG-IP APM for seamless client NTLM Authentication Michael Koyfman reminds us why we love the BIG-IP APM...transparent seamless authentication for users. In this article, Michael specifically discusses how to configure the APM to perform client NTLM authentication and use it in the context of sending a SAML assertion to the Office 365 service. This is a step-by-step masterpiece that shows you exactly what to do at every turn. In the end, you point your browser to the FQDN of the APM virtual server and you will be silently authenticated (let's be honest...silent authentication is a bucket-list item for each and every one of us). Michael also reminds us of the SSO options at the end of his article. Webshells Nir Zigler introduces us to Webshells (web scripts that act as a control panel for the server running them), and talks about some of the common uses for these scripts. But you know the story...scripts that were created for good can also be used for evil. After Nir explains all the valid uses for legitimate webshells, he takes us to a place where mere mortals dare not tread...through a webshell attack. He gives us an overview of how a webshell attack works, and then he explains some of the specific tools that are used for these nefarious actions. After walking through the power and functionality of an open source webshell called b374k, Nir shows how this tool can be used to attack an unsuspecting user. But have no fear! Nir finishes up the article by discussing the power of the BIG-IP ASM and how it will detect and prevent webshell attacks. Continuing the DDoS Arms Race How long have DDoS attacks been around, and why are they still news today? Because they are consistently one of the top attack vectors that companies face today. Shauntine'z discusses the DDoS arms race and provides some poignant statistics that remind us of the very real and credible DDoS threat. But the article doesn't stop there...it goes on to provide some excellent tips on what to do to strengthen your DDoS defense posture (it even has a well-placed picture of Professor John Frink...you gotta check this one out). Last, Shauntine'z reveals new features that are loaded in the latest release of the BIG-IP...version 11.6. The AFM and ASM have some new and exciting capabilities that are "must haves" for any company that is serious about securing their applications and critical business functions. (Editors note: the LineRate product has been discontinued for several years. 09/2023) Why ECC and PFS Matter: SSL offloading with LineRate We all know that sensitive data traverses our networks every day. We also know it's critically important to secure this information. We also know that SSL/TLS is the primary method used to secure said information. Andrew Ragone discusses SSL offloading and tells us why Elliptical Curve Cryptography (ECC) and Perfect Forward Secrecy (PFS) are great candidates for securing your information. He highlights the advantages of the software based LineRate solution, and gives great examples of why LineRate is the clear-cut winner over any existing software-based or hardware-based SSL/TLS offload solutions. Andrew also published another series of articles related to this very topic, and in these articles he walks you through the exact steps needed to configure SSL certificates and offload SSL on LineRate. On that subject...if you haven't had a chance to check out LineRate and learn all about the awesomeness that it is, do yourself a favor and visit
ltwagnon
Sep 26, 2023 Place Technical Articles
215Views
0likes
0Comments
F5 Distributed Cloud L3-L7 DDoS Mitigation
In this article you will learn how simple it is to use F5 Distributed Cloud to protect your application from DDoS attacks.
KevinGallaugher
Apr 10, 2023 Place Technical Articles
9.7KViews
4likes
0Comments
Protect your applications using F5’s Distributed Cloud and Fast ACL’s
Introduction In this article I will show you how to easily create Fast ACL’s to protect your applications from DDoS attacks. Layer 3-4 DDoS Mitigation is included with the F5 Distributed Cloud service. When planning your DDoS strategy, you must plan at many layers. This means organizations need multiple tools and capabilities to protect themselves and keep their infrastructure and applications running. This layered approach uses network firewalls for Layer 3-4 DDoS protection, Web Application Firewalls (WAF) for Layer 7 protections, and as I’ll cover here Access Control Lists (ACLs) or as we call them Fast ACLs that can include rate-limiting. These ACL rules are applied at very early stages in datapath ingress processing and form a first line of defense against attack. Typical Use case(s) are: Rate-limiting traffic to destination Accepting traffic from certain source IPs to destination Rate-limiting or dropping traffic from source IPs to destination These rules are evaluated for each packet coming into the system (ingress), unlike session-based ACL’s where action is calculated only on first packet in the session. It is specified in terms of five tuple of the packet {destination ip, destination port, source ip, source port, protocol}. This gives you the ability to fine tune your DDoS strategy based on your network infrastructure and application performance. Getting Started Log in to your F5 Distributed Cloud Service. Select the Cloud and Edge Sites Tile. Navigate to Manage >> Firewall >> Fast ACL’s. We will also be discussing and using Policers and Protocol Policers. They can be added from this screen or as we build out our DDoS protection. We will show how during the build out. Click Add Fast ACL Give your Fast ACL a Name, add a Label and Description to help identify later. Next is what sets F5 XC Services apart. Under Fast ACL Type you have 2 options. This can be at the F5 XC Services regional edge (RE) or your own customer edge (CE) for apps deployed locally with F5 Distributed Cloud Service nodes. For this article I will cover the Customer Edge (CE). Select Configure. Here you have the option to select which network to apply this to at the CE, Inside or Outside, I will use the Outside Network. Next select the Destination IP, where you have three options to protect. I will use All Interface IP(s) as VIP. Finally, under Source, we will configure the Rules we wish to apply. Click Configure Under the Rules Section. Click Add Item Give your Rule a Name and a Description. Under Action you have 3 options, Simple Action, Policer Action and Protocol Policer Action. First, we will cover the Simple Action. You have two options, allow or deny. Under Source Port, click Add Item. You have the option to select All Ports, A User Defined Port or DNS. I will select User defined and add the value of 443. Under Source I'll allow all from 0.0.0.0./0 and click Add Item. Now you can go back in Rules and any additional rules that reflect your architecture. Click Add Item. This time I'll select Deny as the Action and ALL as Source Ports and Source Prefix as 0.0.0.0/0 When complete click Apply, this takes you back a Screen, Click Apply again. Protocol Policer Finally, we will configure a FAST ACL Protocol Policer. Give your Protocol Policer a Name, Labels and Description. Select a pre-configured Protocol Policer if one is already configured or you have system wide one you wish to apply. For this demonstration we will click Create new Protocol Policer. Click Add Item This will give you the option of Packet Type. The options are TCP, ICMP, UDP and DNS. For this we will select TCP. Then you select the appropriate TCP Flags, we will select SYN. Policer Dropping to the Policer section, we either need to select a preconfigured policer that might be used system wide or Create a new one. We will select Create New Policer. Creating a Policer is straightforward. Give it a Name, Labels and Description. Select If the Policer is to be Shared or Not Shared System wide. Here is where creating Fast ACLs helps you fine tune your DDoS protection for your application. You will enter both a Committed Information Rate in pps and a Burst Size in pps. Click Continue Add item and then Continue. Finally Save and Exit. These are all the steps necessary to get started using Fast ACL's. Two additional steps are needed and beyond the scope of this article. Most builds will already have the necessary configurations required. You need to have a Network Firewall designated and what F5 Distributed Cloud calls a Fleet. The Firewall will reference the ACL and the Firewall and Fleet Tag will be asisgned to your Customer Edge (CE). Conclusion In this article you learned how to configure Fast ACLs DDoS protection quickly and easily with the F5's Distributed Cloud. We included Rate Limiting as a viable option to tune your DDoS settings. In a few short minutes you would be able to react to an attack on your network by going into the F5 Distributed Cloud Console and adjusting or adding DDoS protections. "Nature is a mutable cloud, which is always and never the same." - Ralph Waldo Emerson We might not wax that philosophically around here, but our heads are in the cloud nonetheless! Join the F5 Distributed Cloud user group today and learn more with your peers and other F5 experts. For further information or to get started: F5 Distributed Cloud WAAP YouTube series (Link) F5 Distributed Cloud WAAP Services (Link) F5 Distributed Cloud WAAP Get Started (Link)
Ted_Byerly
Feb 06, 2023 Place Technical Articles
4KViews
3likes
0Comments
Explanation of F5 DDoS threshold modes
Der Reader, In my article “Concept of Device DOS and DOS profile”, I recommended to use the “Fully Automatic” or “Multiplier” based configuration option for some DOS vectors. In this article I would like to explain how these threshold modes work and what is happening behind the scene. When you configure a DOS vector you have the option to choose between different threshold modes: “Fully Automatic”, “Auto Detection / Multiplier Based”, “Manual Detection / Auto Mitigation” and “Fully Manual”. Figure 1: Threshold Modes The two options I normally use on many vectors are “Fully Automatic” and “Auto Detection / Multiplier Based”. But what are these two options do for me? To manually set thresholds is for some vectors not an easy task. I mean who really knows how many PUSH/ACK packets/sec for example are usually hitting the device or a specific service? And when I have an idea about a value, should this be a static value? Or should I better take the maximum value I have seen so far? And how many packets per second should I put on top to make sure the system is not kicking in too early? When should I adjust it? Do I have increasing traffic? Fully Automatic In reality, the rate changes constantly and most likely during the day I will have more PUSH/ACK packets/sec then during the night. What happens when there is a campaign or an event like “Black Friday” and way more users are visiting the webpage then usually? During these high traffic events, my suggested thresholds might be no longer correct which could lead to “good” traffic getting dropped. All this should be taken into consideration when setting a threshold and it ends up being very difficult to do manually. It´s better to make the machine doing it for you and this is what “Fully Automatic” is about. Figure 2: Expected EPS As soon as you use this option, it leverages from the learning it has done since traffic is passing through the BIG-IP, or since you have enforced the relearning, which resets everything learned so far and starts from new. The system continuously calculates the expected rates for all the vectors based on the historic rates of traffic. It takes the information up to one year and calculates them with different weights in order to know which packets rate should be expected at that time and day for that specific vector in the specific context (Device, Virtual Server/Protected Object). The system then calculates a padding on top of this expected rate. This rate is called Detection Rate and is dependent on the “threshold sensitivity” you have configured: Low Sensitivity means 66% padding Medium Sensitivity means 40% padding High Sensitivity means 0% padding Figure 3: Detection EPS As soon as the current rate is above the detection value, the BIG-IP will show the message “Attack detected”, which actually means anomaly detected, because it sees more packets of that specific vector then expected + the padding (detection_rate). But DoS mitigation will not start at that point! Figure 4: Current EPS Keep in mind, when you run the BIG-IP in stateful mode it will drop 'out of state' packets anyway. This has nothing to do with DoS functionalities. But what happens when there is a serious flood and the BIG-IP CPU gets high because of the massive number of packets it has to deal with? This is when the second part of the “Fully Automatic” approach comes into the game. Again, depending on your threshold sensitivity the DOS mitigation starts as soon as a certain level of stress is detected on the CPU of the BIG-IP. Figure 5: Mitigation Threshold Low Sensitivity means 78,3% TMM load Medium Sensitivity means 68,3% TMM load High Sensitivity means 51,6% TMM load Note, that the mitigation is per TMM and therefore the stress and rate per TMM is relevant. When the traffic rate for that vector is above the detection rate and the CPU of the BIG-IP (Device DOS) is “too” busy, the mitigation kicks in and will rate limit on that specific vector. When a DOS vector is hardware supported, FPGAs drop the packets at the switch level of the BIG-IP. If that DOS vector is not hardware supported, then the packet is dropped at a very early stage of the life cycle of a packet inside a BIG-IP. The rate at which are packets dropped is dynamic (mitigation rate), depending on the incoming number of packets for that vector and the CPU (TMM) stress of the BIG-IP. This allows the stress of the CPU to go down as it has to deal with less packets. Once the incoming rate is again below the detection rate, the system declares the attack as ended. Note: When an attack is detected, the packet rate during that time will not go into the calculation of expected rates for the future. This ensures that the BIG-IP will not learn from attack traffic skewing the automatic thresholds. All traffic rates below the detection (or below the floor value, when configured) rate modify the expected rate for the future and the BIG-IP will adjust the detection rate automatically. For most of the vectors you can configure a floor and ceiling value. Floor means that as long as the traffic value is below that threshold, the mitigation for that vector will never kick in. Even when the CPU is at 100%. Ceiling means that mitigation always kicks in at that rate, even when the CPU is idle. With these two values the dynamic and automatic process is done between floor and ceiling. Mitigation only gets executed when the rate is above the rate of the Floor EPS and Detection EPS AND stress on the particular context is measured. Figure 6: Floor and Ceiling EPS What is the difference when you use “Fully Automatic” on Device level compared to VS/PO (DOS profile) level? Everything is the same, except that on VS or Protected Object (PO) level the relevant stress is NOT the BIG-IP device stress, it is the stress of the service you are protecting (web-, DNS, IMAP-server, network, ...). BIG-IP can measure the stress of the service by measuring TCP attributes like retransmission, window size, congestion, etc. This gives a good indication on how busy a service is. This works very well for request/response protocols like TCP, HTTP, DNS. I recommend using this, when the Protected Object is a single service and not a “wildcard” Protected Object covering for example a network or service range. When the Protected Object is a “wildcard” service and/or a UDP service (except DNS), I recommend using “Auto Detection / Multiplier Option”. It works in the same way as the “Fully Automatic” from the learning perspective, but the mitigation condition is not stress, it is the multiplication of the detection rate. For example, the detection rate for a specific vector is calculated to be 100k packets/sec. By default, the multiplication rate is “500”, which means 5x. Therefore, the mitigation rate is calculated to 500k packets/sec. If that particular vector has more than 500k packets/sec those packets would be dropped. The multiplication rate can also be individually configured. Like in the screenshot, where it is set to 8x (800). Figure 7: Auto Detection / Multiplier Based Mitigation The benefit of this mode is that the BIG-IP will automatically learn the baseline for that vector and will only start to mitigate based on a large spike. The mitigation rate is always a multiplication of the detection rate, which is 5x by default but is configurable. When should I use “Fully Manual”? When you want to rate-limit a specific vector to a certain number of packets/sec, then “Fully Manual” is the right choice. Very good examples for that type of vector are the “Bad Header” vector types. These type of packets will never get forwarded by the BIG-IP so dropping them by a DoS vector saves the CPU, which is beneficial under DoS conditions. In the screenshot below is a vector configured as “Fully Manual”. Next I’ll describe what each of the options means. Figure 8: Fully Manual Detection Threshold EPS configures the packet rate/sec (pps) when you will get a log messages (NO mitigation!). Detection Threshold % compares the current pps rate for that vector with the multiplication of the configured percentage (in this example 5 for 500%) with the 1-minute average rate. If the current rate is higher, then you will get a log message. Mitigation Threshold EPS rate limits to that configured value (mitigation). I recommend setting the threshold (Mitigation Threshold EPS) to something relatively low like ‘10’ or ‘100’ on ‘Bad Header’ type of vectors. You can also set it also to ‘0’, which means all packets hitting this vector will get dropped by the DoS function which usually is done in hardware (FPGA). With the ‘Detection Threshold EPS’ you set the rate at which you want to get a log messages for that vector. If you do it this way, then you get a warning message like this one to inform you about the logging behavior: Warning generated: DOS attack data (bad-tcp-flags-all-set): Since drop limit is less than detection limit, packets dropped below the detection limit rate will not be logged. Another use-case for “Fully Manual” is when you know the maximum number of these packets the service can handle. But here my recommendation is to still use “Fully Automatic” and set the maximum rate with the Ceiling threshold, because then the protected service will benefit from both threshold options. Important: Please keep in mind, when you set manual thresholds for Device DoS the thresholds are to protect each TMM. Therefore the value you set is per TMM! An exception to this is the Sweep and Flood vector where the threshold is per BIG-IP/service and not per TMM like on DoS profiles. When using manual thresholds for a DOS profile of a Protected Object the threshold configuration is per service (all packets targeted to the protected service) NOT per TMM like on the Device level. Here the goal is to set how many packets are allowed to pass the BIG-IP and reach the service. The distribution of these thresholds to the TMMs is done in a dynamic way: Every TMM gets a percentage of the configured threshold, based on the EPS (Events Per Second, which is in this context Packets Per Second) for the specific vector the system has seen in the second before on this TMM. This mechanism protects against hash type of attacks. Ok, I hope this article gives you a better understanding on how ‘Fully Manual’, ‘Fully Automatic’ and ‘Auto Detection / Multiplier Based Mitigation’ works. They are important concepts to understand, especially when they work in conjunction with stress measurement. This means the BIG-IP will only kick in with the DoS mitigation when the protected object (BIG-IP or the service behind the BIG-IP) is under stress. -Why risk false positives, when not necessary? With my next article I will demonstrate you how Device DoS and the DoS profiles work together and how the stateful concept cooperates with the DoS mitigation. I will show you some DoS commands to test it and also commands to get details from the BIG-IP via CLI. Thank you, sVen Mueller
Sven_Mueller
Jan 26, 2023 Place Technical Articles
11KViews
21likes
10Comments
Demonstration of Device DoS and Per-Service DoS protection
Dear Reader, This article is intended to show what effect the different threshold modes have on the Device and Per-Service (VS/PO) context. I will be using practical examples to demonstrate those effects. You will get to review a couple of scripts which will help you to do DoS flood tests and “visualizing” results on the CLI. In my first article (https://devcentral.f5.com/s/articles/Concept-of-F5-Device-DoS-and-DoS-profiles), I talked about the concept of F5 Device DoS and Per-Service DoS protection (DoS profiles). I also covered the physical and logical data path, which explains the order of Device DoS and Per-Service DoS using the DoS profiles. In the second article (https://devcentral.f5.com/s/articles/Explanation-of-F5-DDoS-threshold-modes), I explained how the different threshold modes are working. In this third article, I would like to show you what it means when the different modes work together. But, before I start doing some tests to show the behavior, I would like to give you a quick introduction into the toolset I´m using for these tests. Toolset First of all, how to do some floods? Different tools that can be found on the Internet are available for use. Whatever tools you might prefer, just download the tool and run it against your Device Under Test (DUT). If you would like to use my script you can get it from GitHub: https://github.com/sv3n-mu3ll3r/DDoS-Scripts With this script - it uses hping - you can run different type of attacks. Simply start it with: $ ./attack_menu.sh <IP> <PORT> A menu of different attacks will be presented which you can launch against the used IP and port as a parameter. Figure 1: Attack Menu To see what L3/4 DoS events are currently ongoing on your BIG-IP, simply go to the DoS Overview page. Figure 2: DoS Overview page I personally prefer to use the CLI to get the details I´m interested in. This way I don´t need to switch between CLI to launch my attacks and GUI to see the results. For that reason, I created a script which shows me what I am most interested in. Figure 3: DoS stats via CLI You can download that script here: https://github.com/sv3n-mu3ll3r/F5_show_DoS_stats_scripts Simply run it with the “watch” command and the parameter “-c” to get a colored output (-c is only available starting with TMOS version 14.0): What is this script showing you? context_name: This is the context, either PO/VS or the Device in which the vector is running vector_name: This is the name of the DoS vector attack_detected: When it shows “1”, then an attack has been detected, which means the ‘stats_rate’ is above the ‘detection-rate'. stats_rate: Shows you the current incoming pps rate for that vector in this context drops_rate: Shows you the number dropped pps rate in software (not FPGA) for that vector in this context int_drops_rate: Shows you the number dropped pps rate in hardware (FPGA) for that vector in this context ba_stats_rate: Shows you the pps rate for bad actors ba_drops_rate: Shows you the pps rate of dropped ‘bad actors’ in HW and SW bd_stats_rate: Shows you the pps rate for attacked destination bd_drop_rate: Shows you the pps rate for dropped ‘attacked destination’ mitigation_curr: Shows the current mitigation rate (per tmm) for that vector in that context detection: Shows you the current detection rate (per tmm) for that vector in that context wl_count: Shows you the number of whitelist hits for that vector in that context hw_offload: When it shows ‘1’ it means that FPGAs are involved in the mitigation int_dropped_bytes_rate: Gives you the rate of in HW dropped bytes for that vector in that context dropped_bytes_rate: Gives you the rate of in SW dropped bytes for that vector in that context When a line is displayed in green, it means packets hitting that vector. However, no anomaly is detected or anything is mitigated (dropped) via DoS. If a line turns yellow, then an attack - anomaly – has been detected but no packets are dropped via DoS functionalities. When the color turns red, then the system is actually mitigating and dropping packets via DoS functionalities on that vector in that context. Start Testing Before we start doing some tests, let me provide you with a quick overview of my own lab setup. I´m using a DHD (DDoS Hybrid Defender) running on a i5800 box with TMOS version 15.1 My traffic generator sends around 5-6 Gbps legitimate (HTTP and DNS) traffic through the box which is connected in L2 mode (v-wire) to my network. On the “client” side, where my clean traffic generator is located, my attacking clients are located as well by use of my DoS script. On the “server” side, I run a web service and DNS service, which I´m going to attack. Ok, now let’s do some test so see the behavior of the box and double check that we really understand the DDoS mitigation concept of BIG-IP. Y-MAS flood against a protected server Let’s start with a simple Y-MAS (all TCP flags cleared) flood. You can only configure this vector on the device context and only in manual mode. Which is ok, because this TCP packet is not valid and would get drop by the operating system (TMOS) anyway. But, because I want this type of packet get dropped in hardware (FPGA) very early, when they hit the box, mostly without touching the CPU, I set the thresholds to ‘10’ on the Mitigation Threshold EPS and to ‘10’ on Detection Threshold EPS. That means as soon as a TMM sees more then 10 pps for that vector it will give me a log message and also rate-limit this type of packets per TMM to 10 packets per second. That means that everything below that threshold will get to the operating system (TMOS) and get dropped there. Figure 4: Bad TCP Flags vector As soon as I start the attack, which targets the web service (10.103.1.50, port 80) behind the DHD with randomized source IPs. $ /usr/sbin/hping3 --ymas -p 80 10.103.1.50 --flood --rand-source I do get a log messages in /var/log/ltm: Feb 5 10:57:52 lon-i5800-1 err tmm3[15367]: 01010252:3: A Enforced Device DOS attack start was detected for vector Bad TCP flags (all cleared), Attack ID 546994598. And, my script shows me the details on that attack in real time (the line is in ‘red’, indicating we are mitigating): Currently 437569 pps are hitting the device. 382 pps are blocked by DDoS in SW (CPU) and 437187 are blocked in HW (FPGA). Figure 5: Mitigating Y-Flood Great, that was easy. :-) Now, let’s do another TCP flood against my web server. RST-flood against a protected server with Fully manual Threshold mode: For this test I´m using the “Fully Manual” mode, which configures the thresholds for the whole service we are protecting with the DoS profile, which is attached to my VS/PO. Figure 6: RST flood with manual configuration My Detection Threshold and my Mitigation Threshold EPS is set to ‘100’. That means as soon as we see more then 100 RST packets hitting the configured VS/PO on my BIG-IP for this web server, the system will start to rate-limit and send a log message. Figure 7: Mitigating RST flood on PO level Perfect. We see the vector in the context of my web server (/Common/PO_10.103.1.50_HTTP) is blocking (rate-limiting) as expected from the configuration. Please ignore the 'IP bad src' which is in detected mode. This is because 'hping' creates randomized IPs and not all of them are valid. RST-flood against a protected server with Fully Automatic Threshold mode: In this test I set the Threshold Mode for the RST vector on the DoS profile which is attached to my web server to ‘Fully Automatic’ and this is what you would most likely do in the real world as well. Figure 8: RST vector configuration with Fully Automatic But, what does this mean for the test now? I run the same flood against the same destination and my script shows me the anomaly on the VS/PO (and on the device context), but it does not mitigate! Why would this happen? Figure 9: RST flood with Fully Automatic configuration When we take a closer look at the screenshot we see that the ‘stats_rate’ shows 730969 pps. The detection rate shows 25. From where is this 25 coming? As we know, when ‘Fully Automatic’ is enabled then the system learns from history. In this case, the history was even lower than 25, but because I set the floor value to 100, the detection rate per TMM is 25 (floor_value / number of TMMs), which in my case is 100/4 = 25 So, we need to recognize, that the ‘stats_rate’ value represents all packets for that vector in that context and the detection value is showing the per TMM value. This value explains us why the system has detected an attack, but why is it not dropping via DoS functionalities? To understand this, we need to remember that the mitigation in ‘Fully Automatic’ mode will ONLY kick in if the incoming rate for that vector is above the detection rate (condition is here now true) AND the stress on the service is too high. But, because BIG-IP is configures as a stateful device, this randomized RST packets will never reach the web service, because they get all dropped latest by the state engine of the BIG-IP. Therefor the service will never have stress caused by this flood.This is one of the nice benefits of having a stateful DoS device. So, the vector on the web server context will not mitigate here, because the web server will not be stressed by this type of TCP attack. This does also explains the Server Stress visualization in the GUI, which didn´t change before and during the attack. Figure 10: DoS Overview in the GUI But, what happens if the attack gets stronger and stronger or the BIG-IP is too busy dealing with all this RST packets? This is when the Device DOS kicks in but only if you have configured it in ‘Fully Automatic’ mode as well. As soon as the BIG-IP receives more RST packets then usually (detection rate) AND the stress (CPU load) on the BIG-IP gets too high, it starts to mitigate on the device context. This is what you can see here: Figure 11: 'massive' RST flood with Fully Automatic configuration The flood still goes against the same web server, but the mitigation is done on the device context, because the CPU utilization on the BIG-IP is too high. In the screenshot below you can see that the value for the mitigation (mitigation_curr) is set to 5000 on the device context, which is the same as the detection value. This value results from the 'floor' value as well. It is the smallest possible value, because the detection and mitigation rate will never be below the 'floor' value. The mitigation rate is calculated dynamically based on the stress of the BIG-IP. In this test I artificially increased the stress on the BIG-IP and therefor the mitigation rate was calculated to the lowest possible number, which is the same as the detection rate. I will provide an explanation of how I did that later. Figure 13: Device context configuration for RST Flood Because this is the device config, the value you enter in the GUI is per TMM and this is reflected on the script output as well. What does this mean for the false-positive rate? First of all, all RST packets not belonging to an existing flow will kicked out by the state engine. At this point we don´t have any false positives. If the attack increases and the CPU can´t handle the number of packets anymore, then the DOS protection on the device context kicks in. With the configuration we have done so far, it will do the rate-limiting on all RST packets hitting the BIG-IP. There is no differentiation anymore between good and bad RST, or if the RST has the destination of server 1 or server 2, and so on. This means that at this point we can face false positives with this configuration. Is this bad? Well, false-positives are always bad, but at this point you can say it´s better to have few false-positives then a service going down or, even more critical, when your DoS device goes down. What can you do to only have false positives on the destination which is under attack? You probably have recognized that you can also enable “Attacked Destination Detection” on the DoS vector, which makes sense on the device context and on a DoS profile which is used on protected object (VS), that covers a whole network. Figure 14: Device context configuration for RST Flood with 'Attacked Destination Detection' enabled If the attack now hits one or multiple IPs in that network, BIG-IP will identify them and will do the rate-limiting only on the destination(s) under attack. Which still means that you could face false positives, but they will be at least only on the IPs under attack. This is what we see here: Figure 15: Device context mitigation on attacked destination(s) The majority of the RST packet drops are done on the “bad destination” (bd_drops_rate), which is the IP under attack. The other option you can also set is “Bad Actor Detection”. When this is enabled the system identifies the source(s) which causes the load and will do the rate limiting for that IP address(es). This usually works very well for amplification attacks, where the attack packets coming from ‘specific’ hosts and are not randomized sources. Figure 16: Device context mitigation on attacked destination(s) and bad actor(s) Here you can see the majority of the mitigation is done on ‘bad actors’. This reduces the chance of false positives massively. Figure 17: Device context configuration for RST Flood with 'Attacked Destination Detection' and 'Bad Actor Detection' enabled You also have multiple additional options to deal with ‘attacked destination’ and ‘bad actors’, but this is something I will cover in another article. Artificial increase BIG-IPs CPU load Before I finish this article, I would like to give you an idea on how you could increase the CPU load of the BIG-IP for your own testing. Because, as we know, with “Fully Automatic” on the device context, the mitigation kicks only in if the packet rate is above the detection rate AND the CPU utilization on the BIG-IP is “too” high. This is sometimes difficult to archive in a lab because you may not be able to send enough packets to stress the CPUs of a HW BIG-IP. In this use-case I use a simple iRule, which I attach to the VS/PO that is under attack. Figure 18: Stress iRule When I start my attack, I send the traffic with a specific TTL for identification. This TTL is configured in my iRule in order to get a CPU intensive string compare function to work on every attack packet. Here is an example for 'hping': $ /usr/sbin/hping3 --rst -p 80 10.103.1.50 --ttl 5 --flood --rand-source This can easily drive the CPU very high and the DDoS rate-limiting kicks in very aggressive. Summary I hope that this article provides you with an even better understanding on what effect the different threshold modes have on the attack mitigation. Of course, keep in mind this are just the ‘static DoS’ vectors. In later articles I will explain also the 'Behavioral DoS' and the Cookie based mitigation, which helps to massively reduce the chance of a false positives. But, also keep in mind, the DoS vectors start to act in microseconds and are very effective for protecting. Thank you, sVen Mueller
Sven_Mueller
Jan 26, 2023 Place Technical Articles
3.9KViews
12likes
3Comments
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.
Javier_Velasco
Dec 09, 2022 Place Technical Articles
1.7KViews
1like
0Comments
4. SYN Cookie: LTM Configuration
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.
Javier_Velasco
Dec 09, 2022 Place Technical Articles
2.8KViews
1like
2Comments
1. SYN Cookie: Intro
Introduction As for today one of the most common and easiest DDoS attacks to carry out is TCP SYN flood attack. Due to this, many efforts have been dedicated to implement the best solution to mitigate it. This is why you can find different countermeasures with the same goal, like reducing SYN-RECEIVED timer TCP state, increasing backlog, recycling old TCBs, using TCPCT (RFC6013), implementing SYN cache, etc. but the widest spread choice is TCP SYN Cookie. In this article series I explain several aspects of SYN Cookie like how this countermeasure works and how is implemented in BIG-IP, how must be configured, differences between hardware and software SYN Cookie, things to take into account when dealing with SYN Cookie and troubleshooting. All examples shown in these articles are based on TMOS v16, although there could be some slight difference with your specific version it will help you to understand what it is happening in your own system. Note that, SYN Cookie term refers to the countermeasure itself, but sometimes you will read SYN Cookie meaning in fact SYN Cookie challenge. I will talk about the difference throughout the articles. As a final comment, please be aware that I have tried as much as possible to avoid talking about DB keys or internal commands throughout these article series. In any case, as a rule of thumb, please do not change any DB key unless this change is recommended by an F5 engineer. Why SYN Cookie? If you review the well-known TCP state diagram you can probably notice a weak point. Below I have extracted the section of TCP diagram that describes a TCP passive open and I have filled in red the specific TCP state that support the TCP SYN flood attack. Reason is that in SYN_RCVD state the system already reserves memory for the incoming connection information, which is saved in the so called TCB (Transmission Control Block). This means that the system starts to consume memory even before the connection is already ESTABLISHED. Fig1. TCP state diagram section This can be dangerous due to a simple reason, if a device running a server and waiting for connections receives a huge enough amount of TCP SYN packets then the service could be unavailable for legitimate users. This is because, according to TCP standard, the server must answer with a SYN/ACK packet to all these TCP SYN packets, create a TCB entry for each connection and also wait for last ACK from client. Therefore, the server will need to allocate memory, even without knowing if these connections will be finished successfully or not. This is the base of a TCP SYN flood attack. An attacker just needs to generate enough amount of TCP SYN packets to overwhelm a server. Any ISP will allow TCP SYN packets inside their network infrastructure since they cannot know if these packets are legitimate or not, and hence, all these packets will reach the victim. TCP SYN flood attack can cause two different symptoms depending on reachability of attacker’s source IPs. Attending to which one you face maybe you could have clues about the origin of the attack: 1. Source IPs from where the TCP SYN flood attack is being run are reachable from the attacked device. In this case when the target victim replies with expected responses (SYN/ACK) to source IPs the source IPs will response with a RST packet to the server since they are not aware of any TCP connection started from them. Fig2. DDoS TCP SYN Flood attack (bots) This behaviour will cause that the server most probably detects a TCP RST flood attack together with TCP SYN flood attack: Feb 22 10:12:54 slot1/AFM1 err tmm2[14782]: 01010252:3: A Enforced Device DOS attack start was detected for vector TCP RST flood, Attack ID 31508769 The good news in this case is that server will be able to free up space for more TCBs since upon receiving the RST packet TCP state changes to CLOSED and then to LISTEN and therefore reserved space used for TCP connection will be freed up. This is not the common behaviour since what an attacker wants is waste all server resources. Typically, source IPs are random and not reachable from server. Attending to this explanation, if you face a RST flood together with a SYN flood attack maybe attacker is just sending an hping3 from internal subnets, or near to your Big-IP device. 2. Source IPs are not reachable from the attacked device. This is the typical behaviour since, as commented, the idea for TCP SYN flood DDoS attack is consuming all server resources dedicated to TCP connections in order to avoid providing the service to legitimate users. Note that when I say ‘reachable’ I mean that TCP SYN/ACK packets sent by server never has a response. Source IP could be reachable by ICMP or by starting a new TCP connection from server, but unrelated SYN/ACK packets from server are dropped at any point in the path, or even in the client itself. So the result is the same as if they were not reachable at all. In this case TCP SYN/ACK packets sent by the server will be lost and hence space for TCB will be reserved until timeout. Fig3. TCP SYN Flood attack (generic) Note that the word ‘attack’ in this article series does not mandatorily refers to intentional attacker, but also can refer to legitimate devices doing something wrong by error or ignorance. Also a wrong SYN Cookie configuration can warn us about a non real TCP SYN flood attack. Conclusion At this point you know basic theory under TCP SYN flood attack, so the question now is, how can you avoid that a simple TCP SYN packet reserves space for TCB entry? You cannot. Since you have to keep with TCP standard only choice left is rejecting the TCP SYN packet and close the connection. Then the question is how to guarantee that legitimate clients will be able to connect to the server if you close their connections, and solution is, using TCP specification to your benefit. This is what TCP SYN Cookie does and what I will review in the next article, showing how it is implemented in BIG-IP.
Javier_Velasco
Dec 09, 2022 Place Technical Articles
3.1KViews
3likes
0Comments
Orchestrated Infrastructure Security - Guided Configuration
The F5 Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latest here. Introduction This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability, Central Management with BIG-IQ, Application Visibility with Beacon and the protection of critical assets using F5 Advanced WAF and Protocol Inspection (IPS) with AFM. It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working. If you need help setting up SSL Orchestrator for the first time, refer to the Dev/Central article series Implementing SSL Orchestrator here. This article focuses on configuring SSL Orchestrator to decrypt inbound SSL and pass the decrypted content to F5 Advanced WAF and Protocol Inspection (IPS) with AFM for enhanced protection from threats. It covers the configuration of the SSL Orchestrator Topology, Services and more on an F5 BIG-IP running version 15.1.0.4 and SSL Orchestrator version 7.4.9. Configuration of BIG-IP deployed as SSL Orchestrator can be downloaded from here from GitLab. Please forgive me for using SSL and TLS interchangeably in this article. In this article we will walk you through the SSL Orchestrator Guided Configuration which covers the following: Inbound L2 Topology creation Certificate and Key used for SSL Decryption Adding the Advanced WAF and AFM devices Creating a Security Policy Creating an Interception Policy SSL Orchestrator Guided Configuration From the BIG-IP Configuration Utility select SSL Orchestrator > Configuration from the menu on the left. Note: There are Required Configuration options on the right you may need to configure. A Route is not needed when SSL Orchestrator is deployed in Layer 2 mode. The Configuration screen presents all of the configuration options that are available. Scroll to the bottom of the page and click Next. Give the Topology a name, InboundAppProtection in this example. You can optionally configure the Protocol and IP Family you want the Topology to support. We’re using the default of TCP and IPv4. Select L2 Inbound and click Save & Next. Configure the Certificate Key Chain by clicking the Pencil icon on the right. Choose the correct Certificate and Key from the drop menu. In this example we use subrsa.f5labs.com for the Certificate and Key. Click Done. There are Server-side SSL settings that you can optionally configure. Click Save & Next. On the next screen click Add Service. Scroll to the bottom, select Generic Inline Layer 2 and then Add. Give it a name, Advanced_WAF in this example. Under Network Configuration click Add. Here we create the VLANs & select the Interfaces the Advanced WAF devices are connected to. For the From and To VLAN options select Create New. Give them a unique name, egress_WAF1 and ingress_WAF1 in this example. Select the interfaces connected to the first WAF device, 4.1 and 4.2 in this example. Then click Done. Repeat this process for the 2 nd Advanced WAF device using interfaces 4.3 and 4.4. It should look like this when done. Note: In this case the SSL Orchestrator interfaces 4.1 and 4.2 are connected to Advanced WAF1 interfaces 2.1 and 2.2. SSL Orchestrator interfaces 4.3 and 4.4 are connected to Advanced WAF2 interfaces 2.3 and 2.4. You can optionally configure the Device Monitor and Service Down Action. Enable the Port Remap option and click Save. Click Add Service to add the AFM devices. Scroll to the bottom, select Generic Inline Layer 2 and then Add. Give it a name, AFM in this example. Under Network Configuration click Add. Here we create the VLANs & select the Interfaces the AFM devices are connected to. For the From and To VLAN options select Create New. Give them a unique name, egress_AFM1 and ingress_AFM1 in this example. Select the interfaces connected to the first AFM device, 5.1 and 5.2 in this example. Then click Done. Repeat this process for the 2 nd AFM device using interfaces 5.3 and 5.4. It should look like this when done. Note: In this case the SSL Orchestrator interfaces 5.1 and 5.2 are connected to AFM1 interfaces 5.0 and 6.0. SSL Orchestrator interfaces 5.3 and 5.4 are connected to AFM2 interfaces 5.0 and 6.0. You can optionally configure the Device Monitor and Service Down Action. Enable the Port Remap option and click Save. Click Save & Next at the bottom. Click Add to create the Service Chain. Give it a name, Inbound_Protect1 in this example. Select ssloS_AFM and ssloS_Advanced_WAF Services then click the arrow to move them to the right. Click Save. Note: It is recommended that AFM be placed first in the Service Chain Order. That way intrusion attempts are detected and blocked before they ever get to the Advanced WAF. This saves resources on the Advanced WAFs because they don’t have to process any of the attempted intrusion connections. Click Save & Next. For the Security Policy click the Pencil icon on the lower right to edit the rule. Set the Service Chain to the one created previously. Click OK. Click Save & Next at the bottom. For the Interception Rule, define the Destination Address or subnet of the application servers you wish to protect. In this example the application servers are all in the 10.4.1.0/24 subnet. Specify the correct port, typically 443. For the Ingress Network select the VLAN(s) that will be receiving traffic from external users, Direct_all in this example. Set the L7 Profile to http. Click Save & Next. Make any changes to the Log Settings if needed. Click Save & Next. On the Summary screen you can review and change any of the settings. Click Deploy when ready. You should get a Success message. If you receive an error you will need to go back into the configuration to resolve it. If successful, you should see a screen like this: Notice the Service Health status is indicated by the small green circle. Summary In this article you learned how to use the SSL Orchestrator Guided Configuration to create a Topology, select the certificate and key used for SSL Decryption, add the Advanced WAF and AFM devices, create a Security Policy and an Interception Policy. Next Steps Click Next to proceed to the next article in the series.
KevinGallaugher
Aug 12, 2022 Place Technical Articles
522Views
0likes
0Comments

"}},"componentScriptGroups({\"componentId\":\"custom.widget.Beta_MetaNav\"})":{"__typename":"ComponentScriptGroups","scriptGroups":{"__typename":"ComponentScriptGroupsDefinition","afterInteractive":{"__typename":"PageScriptGroupDefinition","group":"AFTER_INTERACTIVE","scriptIds":[]},"lazyOnLoad":{"__typename":"PageScriptGroupDefinition","group":"LAZY_ON_LOAD","scriptIds":[]}},"componentScripts":[]},"component({\"componentId\":\"custom.widget.Beta_Footer\"})":{"__typename":"Component","render({\"context\":{\"component\":{\"entities\":[],\"props\":{}},\"page\":{\"entities\":[],\"name\":\"TagPage\",\"props\":{},\"url\":\"https://community.f5.com/tag/ddos\"}}})":{"__typename":"ComponentRenderResult","html":"

Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information

"}},"componentScriptGroups({\"componentId\":\"custom.widget.Beta_Footer\"})":{"__typename":"ComponentScriptGroups","scriptGroups":{"__typename":"ComponentScriptGroupsDefinition","afterInteractive":{"__typename":"PageScriptGroupDefinition","group":"AFTER_INTERACTIVE","scriptIds":[]},"lazyOnLoad":{"__typename":"PageScriptGroupDefinition","group":"LAZY_ON_LOAD","scriptIds":[]}},"componentScripts":[]},"component({\"componentId\":\"custom.widget.Tag_Manager_Helper\"})":{"__typename":"Component","render({\"context\":{\"component\":{\"entities\":[],\"props\":{}},\"page\":{\"entities\":[],\"name\":\"TagPage\",\"props\":{},\"url\":\"https://community.f5.com/tag/ddos\"}}})":{"__typename":"ComponentRenderResult","html":" "}},"componentScriptGroups({\"componentId\":\"custom.widget.Tag_Manager_Helper\"})":{"__typename":"ComponentScriptGroups","scriptGroups":{"__typename":"ComponentScriptGroupsDefinition","afterInteractive":{"__typename":"PageScriptGroupDefinition","group":"AFTER_INTERACTIVE","scriptIds":[]},"lazyOnLoad":{"__typename":"PageScriptGroupDefinition","group":"LAZY_ON_LOAD","scriptIds":[]}},"componentScripts":[]},"component({\"componentId\":\"custom.widget.Consent_Blackbar\"})":{"__typename":"Component","render({\"context\":{\"component\":{\"entities\":[],\"props\":{}},\"page\":{\"entities\":[],\"name\":\"TagPage\",\"props\":{},\"url\":\"https://community.f5.com/tag/ddos\"}}})":{"__typename":"ComponentRenderResult","html":"

"}},"componentScriptGroups({\"componentId\":\"custom.widget.Consent_Blackbar\"})":{"__typename":"ComponentScriptGroups","scriptGroups":{"__typename":"ComponentScriptGroupsDefinition","afterInteractive":{"__typename":"PageScriptGroupDefinition","group":"AFTER_INTERACTIVE","scriptIds":[]},"lazyOnLoad":{"__typename":"PageScriptGroupDefinition","group":"LAZY_ON_LOAD","scriptIds":[]}},"componentScripts":[]},"cachedText({\"lastModified\":\"1743097583657\",\"locale\":\"en-US\",\"namespaces\":[\"components/community/NavbarDropdownToggle\"]})":[{"__ref":"CachedAsset:text:en_US-components/community/NavbarDropdownToggle-1743097583657"}],"cachedText({\"lastModified\":\"1743097583657\",\"locale\":\"en-US\",\"namespaces\":[\"shared/client/components/common/OverflowNav\"]})":[{"__ref":"CachedAsset:text:en_US-shared/client/components/common/OverflowNav-1743097583657"}],"cachedText({\"lastModified\":\"1743097583657\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageView/MessageViewInline\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageView/MessageViewInline-1743097583657"}],"cachedText({\"lastModified\":\"1743097583657\",\"locale\":\"en-US\",\"namespaces\":[\"shared/client/components/common/Pager/PagerLoadMore\"]})":[{"__ref":"CachedAsset:text:en_US-shared/client/components/common/Pager/PagerLoadMore-1743097583657"}],"cachedText({\"lastModified\":\"1743097583657\",\"locale\":\"en-US\",\"namespaces\":[\"components/customComponent/CustomComponent\"]})":[{"__ref":"CachedAsset:text:en_US-components/customComponent/CustomComponent-1743097583657"}],"cachedText({\"lastModified\":\"1743097583657\",\"locale\":\"en-US\",\"namespaces\":[\"components/users/UserLink\"]})":[{"__ref":"CachedAsset:text:en_US-components/users/UserLink-1743097583657"}],"cachedText({\"lastModified\":\"1743097583657\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageSubject\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageSubject-1743097583657"}],"cachedText({\"lastModified\":\"1743097583657\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageTime\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageTime-1743097583657"}],"cachedText({\"lastModified\":\"1743097583657\",\"locale\":\"en-US\",\"namespaces\":[\"shared/client/components/nodes/NodeIcon\"]})":[{"__ref":"CachedAsset:text:en_US-shared/client/components/nodes/NodeIcon-1743097583657"}],"cachedText({\"lastModified\":\"1743097583657\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageUnreadCount\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageUnreadCount-1743097583657"}],"cachedText({\"lastModified\":\"1743097583657\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageViewCount\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageViewCount-1743097583657"}],"cachedText({\"lastModified\":\"1743097583657\",\"locale\":\"en-US\",\"namespaces\":[\"components/kudos/KudosCount\"]})":[{"__ref":"CachedAsset:text:en_US-components/kudos/KudosCount-1743097583657"}],"cachedText({\"lastModified\":\"1743097583657\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageRepliesCount\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageRepliesCount-1743097583657"}],"cachedText({\"lastModified\":\"1743097583657\",\"locale\":\"en-US\",\"namespaces\":[\"components/messages/MessageBody\"]})":[{"__ref":"CachedAsset:text:en_US-components/messages/MessageBody-1743097583657"}],"cachedText({\"lastModified\":\"1743097583657\",\"locale\":\"en-US\",\"namespaces\":[\"shared/client/components/users/UserAvatar\"]})":[{"__ref":"CachedAsset:text:en_US-shared/client/components/users/UserAvatar-1743097583657"}]},"CachedAsset:pages-1742463313756":{"__typename":"CachedAsset","id":"pages-1742463313756","value":[{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"HowDoI.GetInvolved.MvpProgram","type":"COMMUNITY","urlPath":"/c/how-do-i/get-involved/mvp-program","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"BlogViewAllPostsPage","type":"BLOG","urlPath":"/category/:categoryId/blog/:boardId/all-posts/(/:after|/:before)?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"CasePortalPage","type":"CASE_PORTAL","urlPath":"/caseportal","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"CreateGroupHubPage","type":"GROUP_HUB","urlPath":"/groups/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"CaseViewPage","type":"CASE_DETAILS","urlPath":"/case/:caseId/:caseNumber","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"InboxPage","type":"COMMUNITY","urlPath":"/inbox","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"HowDoI.GetInvolved.AdvocacyProgram","type":"COMMUNITY","urlPath":"/c/how-do-i/get-involved/advocacy-program","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"HowDoI.GetHelp.NonCustomer","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help/non-customer","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"HelpFAQPage","type":"COMMUNITY","urlPath":"/help","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"HowDoI.GetHelp.F5Customer","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help/f5-customer","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"IdeaMessagePage","type":"IDEA_POST","urlPath":"/idea/:boardId/:messageSubject/:messageId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"IdeaViewAllIdeasPage","type":"IDEA","urlPath":"/category/:categoryId/ideas/:boardId/all-ideas/(/:after|/:before)?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"LoginPage","type":"USER","urlPath":"/signin","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"BlogPostPage","type":"BLOG","urlPath":"/category/:categoryId/blogs/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"HowDoI.GetInvolved","type":"COMMUNITY","urlPath":"/c/how-do-i/get-involved","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"HowDoI.Learn","type":"COMMUNITY","urlPath":"/c/how-do-i/learn","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1739501996000,"localOverride":null,"page":{"id":"Test","type":"CUSTOM","urlPath":"/custom-test-2","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"ThemeEditorPage","type":"COMMUNITY","urlPath":"/designer/themes","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"TkbViewAllArticlesPage","type":"TKB","urlPath":"/category/:categoryId/kb/:boardId/all-articles/(/:after|/:before)?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"OccasionEditPage","type":"EVENT","urlPath":"/event/:boardId/:messageSubject/:messageId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"OAuthAuthorizationAllowPage","type":"USER","urlPath":"/auth/authorize/allow","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"PageEditorPage","type":"COMMUNITY","urlPath":"/designer/pages","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"PostPage","type":"COMMUNITY","urlPath":"/category/:categoryId/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"ForumBoardPage","type":"FORUM","urlPath":"/category/:categoryId/discussions/:boardId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"TkbBoardPage","type":"TKB","urlPath":"/category/:categoryId/kb/:boardId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"EventPostPage","type":"EVENT","urlPath":"/category/:categoryId/events/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"UserBadgesPage","type":"COMMUNITY","urlPath":"/users/:login/:userId/badges","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"GroupHubMembershipAction","type":"GROUP_HUB","urlPath":"/membership/join/:nodeId/:membershipType","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"MaintenancePage","type":"COMMUNITY","urlPath":"/maintenance","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"IdeaReplyPage","type":"IDEA_REPLY","urlPath":"/idea/:boardId/:messageSubject/:messageId/comments/:replyId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"UserSettingsPage","type":"USER","urlPath":"/mysettings/:userSettingsTab","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"GroupHubsPage","type":"GROUP_HUB","urlPath":"/groups","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"ForumPostPage","type":"FORUM","urlPath":"/category/:categoryId/discussions/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"OccasionRsvpActionPage","type":"OCCASION","urlPath":"/event/:boardId/:messageSubject/:messageId/rsvp/:responseType","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"VerifyUserEmailPage","type":"USER","urlPath":"/verifyemail/:userId/:verifyEmailToken","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"AllOccasionsPage","type":"OCCASION","urlPath":"/category/:categoryId/events/:boardId/all-events/(/:after|/:before)?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"EventBoardPage","type":"EVENT","urlPath":"/category/:categoryId/events/:boardId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"TkbReplyPage","type":"TKB_REPLY","urlPath":"/kb/:boardId/:messageSubject/:messageId/comments/:replyId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"IdeaBoardPage","type":"IDEA","urlPath":"/category/:categoryId/ideas/:boardId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"CommunityGuideLinesPage","type":"COMMUNITY","urlPath":"/communityguidelines","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"CaseCreatePage","type":"SALESFORCE_CASE_CREATION","urlPath":"/caseportal/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"TkbEditPage","type":"TKB","urlPath":"/kb/:boardId/:messageSubject/:messageId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"ForgotPasswordPage","type":"USER","urlPath":"/forgotpassword","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"IdeaEditPage","type":"IDEA","urlPath":"/idea/:boardId/:messageSubject/:messageId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"TagPage","type":"COMMUNITY","urlPath":"/tag/:tagName","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"BlogBoardPage","type":"BLOG","urlPath":"/category/:categoryId/blog/:boardId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"OccasionMessagePage","type":"OCCASION_TOPIC","urlPath":"/event/:boardId/:messageSubject/:messageId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"ManageContentPage","type":"COMMUNITY","urlPath":"/managecontent","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"ClosedMembershipNodeNonMembersPage","type":"GROUP_HUB","urlPath":"/closedgroup/:groupHubId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"HowDoI.GetHelp.Community","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help/community","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"CommunityPage","type":"COMMUNITY","urlPath":"/","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"HowDoI.GetInvolved.ContributeCode","type":"COMMUNITY","urlPath":"/c/how-do-i/get-involved/contribute-code","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"ForumMessagePage","type":"FORUM_TOPIC","urlPath":"/discussions/:boardId/:messageSubject/:messageId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"IdeaPostPage","type":"IDEA","urlPath":"/category/:categoryId/ideas/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"BlogMessagePage","type":"BLOG_ARTICLE","urlPath":"/blog/:boardId/:messageSubject/:messageId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"RegistrationPage","type":"USER","urlPath":"/register","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"EditGroupHubPage","type":"GROUP_HUB","urlPath":"/group/:groupHubId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"ForumEditPage","type":"FORUM","urlPath":"/discussions/:boardId/:messageSubject/:messageId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"ResetPasswordPage","type":"USER","urlPath":"/resetpassword/:userId/:resetPasswordToken","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"TkbMessagePage","type":"TKB_ARTICLE","urlPath":"/kb/:boardId/:messageSubject/:messageId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"HowDoI.Learn.AboutIrules","type":"COMMUNITY","urlPath":"/c/how-do-i/learn/about-irules","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"BlogEditPage","type":"BLOG","urlPath":"/blog/:boardId/:messageSubject/:messageId/edit","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"HowDoI.GetHelp.F5Support","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help/f5-support","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"ManageUsersPage","type":"USER","urlPath":"/users/manage/:tab?/:manageUsersTab?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"ForumReplyPage","type":"FORUM_REPLY","urlPath":"/discussions/:boardId/:messageSubject/:messageId/replies/:replyId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"PrivacyPolicyPage","type":"COMMUNITY","urlPath":"/privacypolicy","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"NotificationPage","type":"COMMUNITY","urlPath":"/notifications","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"UserPage","type":"USER","urlPath":"/users/:login/:userId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"HealthCheckPage","type":"COMMUNITY","urlPath":"/health","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"OccasionReplyPage","type":"OCCASION_REPLY","urlPath":"/event/:boardId/:messageSubject/:messageId/comments/:replyId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"ManageMembersPage","type":"GROUP_HUB","urlPath":"/group/:groupHubId/manage/:tab?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"SearchResultsPage","type":"COMMUNITY","urlPath":"/search","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"BlogReplyPage","type":"BLOG_REPLY","urlPath":"/blog/:boardId/:messageSubject/:messageId/replies/:replyId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"GroupHubPage","type":"GROUP_HUB","urlPath":"/group/:groupHubId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"TermsOfServicePage","type":"COMMUNITY","urlPath":"/termsofservice","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"HowDoI.GetHelp","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"HowDoI.GetHelp.SecurityIncident","type":"COMMUNITY","urlPath":"/c/how-do-i/get-help/security-incident","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"CategoryPage","type":"CATEGORY","urlPath":"/category/:categoryId","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"ForumViewAllTopicsPage","type":"FORUM","urlPath":"/category/:categoryId/discussions/:boardId/all-topics/(/:after|/:before)?","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"TkbPostPage","type":"TKB","urlPath":"/category/:categoryId/kbs/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"GroupHubPostPage","type":"GROUP_HUB","urlPath":"/group/:groupHubId/:boardId/create","__typename":"PageDescriptor"},"__typename":"PageResource"},{"lastUpdatedTime":1742463313756,"localOverride":null,"page":{"id":"HowDoI","type":"COMMUNITY","urlPath":"/c/how-do-i","__typename":"PageDescriptor"},"__typename":"PageResource"}],"localOverride":false},"CachedAsset:text:en_US-components/context/AppContext/AppContextProvider-0":{"__typename":"CachedAsset","id":"text:en_US-components/context/AppContext/AppContextProvider-0","value":{"noCommunity":"Cannot find community","noUser":"Cannot find current user","noNode":"Cannot find node with id {nodeId}","noMessage":"Cannot find message with id {messageId}"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/common/Loading/LoadingDot-0":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/common/Loading/LoadingDot-0","value":{"title":"Loading..."},"localOverride":false},"User:user:-1":{"__typename":"User","id":"user:-1","uid":-1,"login":"Former Member","email":"","avatar":null,"rank":null,"kudosWeight":1,"registrationData":{"__typename":"RegistrationData","status":"ANONYMOUS","registrationTime":null,"confirmEmailStatus":false,"registrationAccessLevel":"VIEW","ssoRegistrationFields":[]},"ssoId":null,"profileSettings":{"__typename":"ProfileSettings","dateDisplayStyle":{"__typename":"InheritableStringSettingWithPossibleValues","key":"layout.friendly_dates_enabled","value":"false","localValue":"true","possibleValues":["true","false"]},"dateDisplayFormat":{"__typename":"InheritableStringSetting","key":"layout.format_pattern_date","value":"dd-MMM-yyyy","localValue":"MM-dd-yyyy"},"language":{"__typename":"InheritableStringSettingWithPossibleValues","key":"profile.language","value":"en-US","localValue":null,"possibleValues":["en-US"]}},"deleted":false},"Theme:customTheme1":{"__typename":"Theme","id":"customTheme1"},"CachedAsset:theme:customTheme1-1742463312973":{"__typename":"CachedAsset","id":"theme:customTheme1-1742463312973","value":{"id":"customTheme1","animation":{"fast":"150ms","normal":"250ms","slow":"500ms","slowest":"750ms","function":"cubic-bezier(0.07, 0.91, 0.51, 1)","__typename":"AnimationThemeSettings"},"avatar":{"borderRadius":"50%","collections":["custom"],"__typename":"AvatarThemeSettings"},"basics":{"browserIcon":{"imageAssetName":"JimmyPackets-512-1702592938213.png","imageLastModified":"1702592945815","__typename":"ThemeAsset"},"customerLogo":{"imageAssetName":"f5_logo_fix-1704824537976.svg","imageLastModified":"1704824540697","__typename":"ThemeAsset"},"maximumWidthOfPageContent":"1600px","oneColumnNarrowWidth":"800px","gridGutterWidthMd":"30px","gridGutterWidthXs":"10px","pageWidthStyle":"WIDTH_OF_PAGE_CONTENT","__typename":"BasicsThemeSettings"},"buttons":{"borderRadiusSm":"5px","borderRadius":"5px","borderRadiusLg":"5px","paddingY":"5px","paddingYLg":"7px","paddingYHero":"var(--lia-bs-btn-padding-y-lg)","paddingX":"12px","paddingXLg":"14px","paddingXHero":"42px","fontStyle":"NORMAL","fontWeight":"400","textTransform":"NONE","disabledOpacity":0.5,"primaryTextColor":"var(--lia-bs-white)","primaryTextHoverColor":"var(--lia-bs-white)","primaryTextActiveColor":"var(--lia-bs-white)","primaryBgColor":"var(--lia-bs-primary)","primaryBgHoverColor":"hsl(var(--lia-bs-primary-h), var(--lia-bs-primary-s), calc(var(--lia-bs-primary-l) * 0.85))","primaryBgActiveColor":"hsl(var(--lia-bs-primary-h), var(--lia-bs-primary-s), calc(var(--lia-bs-primary-l) * 0.7))","primaryBorder":"1px solid transparent","primaryBorderHover":"1px solid transparent","primaryBorderActive":"1px solid transparent","primaryBorderFocus":"1px solid var(--lia-bs-white)","primaryBoxShadowFocus":"0 0 0 1px var(--lia-bs-primary), 0 0 0 4px hsla(var(--lia-bs-primary-h), var(--lia-bs-primary-s), var(--lia-bs-primary-l), 0.2)","secondaryTextColor":"var(--lia-bs-gray-900)","secondaryTextHoverColor":"hsl(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), calc(var(--lia-bs-gray-900-l) * 0.95))","secondaryTextActiveColor":"hsl(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), calc(var(--lia-bs-gray-900-l) * 0.9))","secondaryBgColor":"var(--lia-bs-gray-400)","secondaryBgHoverColor":"hsl(var(--lia-bs-gray-400-h), var(--lia-bs-gray-400-s), calc(var(--lia-bs-gray-400-l) * 0.96))","secondaryBgActiveColor":"hsl(var(--lia-bs-gray-400-h), var(--lia-bs-gray-400-s), calc(var(--lia-bs-gray-400-l) * 0.92))","secondaryBorder":"1px solid transparent","secondaryBorderHover":"1px solid transparent","secondaryBorderActive":"1px solid transparent","secondaryBorderFocus":"1px solid transparent","secondaryBoxShadowFocus":"0 0 0 1px var(--lia-bs-primary), 0 0 0 4px hsla(var(--lia-bs-primary-h), var(--lia-bs-primary-s), var(--lia-bs-primary-l), 0.2)","tertiaryTextColor":"var(--lia-bs-gray-900)","tertiaryTextHoverColor":"hsl(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), calc(var(--lia-bs-gray-900-l) * 0.95))","tertiaryTextActiveColor":"hsl(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), calc(var(--lia-bs-gray-900-l) * 0.9))","tertiaryBgColor":"transparent","tertiaryBgHoverColor":"transparent","tertiaryBgActiveColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.04)","tertiaryBorder":"1px solid transparent","tertiaryBorderHover":"1px solid hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.08)","tertiaryBorderActive":"1px solid transparent","tertiaryBorderFocus":"1px solid transparent","tertiaryBoxShadowFocus":"0 0 0 1px var(--lia-bs-primary), 0 0 0 4px hsla(var(--lia-bs-primary-h), var(--lia-bs-primary-s), var(--lia-bs-primary-l), 0.2)","destructiveTextColor":"var(--lia-bs-danger)","destructiveTextHoverColor":"hsl(var(--lia-bs-danger-h), var(--lia-bs-danger-s), calc(var(--lia-bs-danger-l) * 0.95))","destructiveTextActiveColor":"hsl(var(--lia-bs-danger-h), var(--lia-bs-danger-s), calc(var(--lia-bs-danger-l) * 0.9))","destructiveBgColor":"var(--lia-bs-gray-300)","destructiveBgHoverColor":"hsl(var(--lia-bs-gray-300-h), var(--lia-bs-gray-300-s), calc(var(--lia-bs-gray-300-l) * 0.96))","destructiveBgActiveColor":"hsl(var(--lia-bs-gray-300-h), var(--lia-bs-gray-300-s), calc(var(--lia-bs-gray-300-l) * 0.92))","destructiveBorder":"1px solid transparent","destructiveBorderHover":"1px solid transparent","destructiveBorderActive":"1px solid transparent","destructiveBorderFocus":"1px solid transparent","destructiveBoxShadowFocus":"0 0 0 1px var(--lia-bs-primary), 0 0 0 4px hsla(var(--lia-bs-primary-h), var(--lia-bs-primary-s), var(--lia-bs-primary-l), 0.2)","__typename":"ButtonsThemeSettings"},"border":{"color":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.08)","mainContent":"NONE","sideContent":"NONE","radiusSm":"3px","radius":"5px","radiusLg":"9px","radius50":"100vw","__typename":"BorderThemeSettings"},"boxShadow":{"xs":"0 0 0 1px hsla(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), var(--lia-bs-gray-900-l), 0.08), 0 3px 0 -1px hsla(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), var(--lia-bs-gray-900-l), 0.08)","sm":"0 2px 4px hsla(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), var(--lia-bs-gray-900-l), 0.06)","md":"0 5px 15px hsla(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), var(--lia-bs-gray-900-l), 0.15)","lg":"0 10px 30px hsla(var(--lia-bs-gray-900-h), var(--lia-bs-gray-900-s), var(--lia-bs-gray-900-l), 0.15)","__typename":"BoxShadowThemeSettings"},"cards":{"bgColor":"var(--lia-panel-bg-color)","borderRadius":"var(--lia-panel-border-radius)","boxShadow":"var(--lia-box-shadow-xs)","__typename":"CardsThemeSettings"},"chip":{"maxWidth":"300px","height":"30px","__typename":"ChipThemeSettings"},"coreTypes":{"defaultMessageLinkColor":"var(--lia-bs-primary)","defaultMessageLinkDecoration":"none","defaultMessageLinkFontStyle":"NORMAL","defaultMessageLinkFontWeight":"400","defaultMessageFontStyle":"NORMAL","defaultMessageFontWeight":"400","forumColor":"#0C5C8D","forumFontFamily":"var(--lia-bs-font-family-base)","forumFontWeight":"var(--lia-default-message-font-weight)","forumLineHeight":"var(--lia-bs-line-height-base)","forumFontStyle":"var(--lia-default-message-font-style)","forumMessageLinkColor":"var(--lia-default-message-link-color)","forumMessageLinkDecoration":"var(--lia-default-message-link-decoration)","forumMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","forumMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","forumSolvedColor":"#62C026","blogColor":"#730015","blogFontFamily":"var(--lia-bs-font-family-base)","blogFontWeight":"var(--lia-default-message-font-weight)","blogLineHeight":"1.75","blogFontStyle":"var(--lia-default-message-font-style)","blogMessageLinkColor":"var(--lia-default-message-link-color)","blogMessageLinkDecoration":"var(--lia-default-message-link-decoration)","blogMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","blogMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","tkbColor":"#C20025","tkbFontFamily":"var(--lia-bs-font-family-base)","tkbFontWeight":"var(--lia-default-message-font-weight)","tkbLineHeight":"1.75","tkbFontStyle":"var(--lia-default-message-font-style)","tkbMessageLinkColor":"var(--lia-default-message-link-color)","tkbMessageLinkDecoration":"var(--lia-default-message-link-decoration)","tkbMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","tkbMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","qandaColor":"#4099E2","qandaFontFamily":"var(--lia-bs-font-family-base)","qandaFontWeight":"var(--lia-default-message-font-weight)","qandaLineHeight":"var(--lia-bs-line-height-base)","qandaFontStyle":"var(--lia-default-message-link-font-style)","qandaMessageLinkColor":"var(--lia-default-message-link-color)","qandaMessageLinkDecoration":"var(--lia-default-message-link-decoration)","qandaMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","qandaMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","qandaSolvedColor":"#3FA023","ideaColor":"#F3704B","ideaFontFamily":"var(--lia-bs-font-family-base)","ideaFontWeight":"var(--lia-default-message-font-weight)","ideaLineHeight":"var(--lia-bs-line-height-base)","ideaFontStyle":"var(--lia-default-message-font-style)","ideaMessageLinkColor":"var(--lia-default-message-link-color)","ideaMessageLinkDecoration":"var(--lia-default-message-link-decoration)","ideaMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","ideaMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","contestColor":"#FCC845","contestFontFamily":"var(--lia-bs-font-family-base)","contestFontWeight":"var(--lia-default-message-font-weight)","contestLineHeight":"var(--lia-bs-line-height-base)","contestFontStyle":"var(--lia-default-message-link-font-style)","contestMessageLinkColor":"var(--lia-default-message-link-color)","contestMessageLinkDecoration":"var(--lia-default-message-link-decoration)","contestMessageLinkFontStyle":"ITALIC","contestMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","occasionColor":"#EE4B5B","occasionFontFamily":"var(--lia-bs-font-family-base)","occasionFontWeight":"var(--lia-default-message-font-weight)","occasionLineHeight":"var(--lia-bs-line-height-base)","occasionFontStyle":"var(--lia-default-message-font-style)","occasionMessageLinkColor":"var(--lia-default-message-link-color)","occasionMessageLinkDecoration":"var(--lia-default-message-link-decoration)","occasionMessageLinkFontStyle":"var(--lia-default-message-link-font-style)","occasionMessageLinkFontWeight":"var(--lia-default-message-link-font-weight)","grouphubColor":"#491B62","categoryColor":"#949494","communityColor":"#FFFFFF","productColor":"#949494","__typename":"CoreTypesThemeSettings"},"colors":{"black":"#000000","white":"#FFFFFF","gray100":"#F7F7F7","gray200":"#F7F7F7","gray300":"#E8E8E8","gray400":"#D9D9D9","gray500":"#CCCCCC","gray600":"#949494","gray700":"#707070","gray800":"#545454","gray900":"#333333","dark":"#545454","light":"#F7F7F7","primary":"#0C5C8D","secondary":"#333333","bodyText":"#222222","bodyBg":"#F5F5F5","info":"#1D9CD3","success":"#62C026","warning":"#FFD651","danger":"#C20025","alertSystem":"#FF6600","textMuted":"#707070","highlight":"#FFFCAD","outline":"var(--lia-bs-primary)","custom":["#C20025","#081B85","#009639","#B3C6D7","#7CC0EB","#F29A36"],"__typename":"ColorsThemeSettings"},"divider":{"size":"3px","marginLeft":"4px","marginRight":"4px","borderRadius":"50%","bgColor":"var(--lia-bs-gray-600)","bgColorActive":"var(--lia-bs-gray-600)","__typename":"DividerThemeSettings"},"dropdown":{"fontSize":"var(--lia-bs-font-size-sm)","borderColor":"var(--lia-bs-border-color)","borderRadius":"var(--lia-bs-border-radius-sm)","dividerBg":"var(--lia-bs-gray-300)","itemPaddingY":"5px","itemPaddingX":"20px","headerColor":"var(--lia-bs-gray-700)","__typename":"DropdownThemeSettings"},"email":{"link":{"color":"#0069D4","hoverColor":"#0061c2","decoration":"none","hoverDecoration":"underline","__typename":"EmailLinkSettings"},"border":{"color":"#e4e4e4","__typename":"EmailBorderSettings"},"buttons":{"borderRadiusLg":"5px","paddingXLg":"16px","paddingYLg":"7px","fontWeight":"700","primaryTextColor":"#ffffff","primaryTextHoverColor":"#ffffff","primaryBgColor":"#0069D4","primaryBgHoverColor":"#005cb8","primaryBorder":"1px solid transparent","primaryBorderHover":"1px solid transparent","__typename":"EmailButtonsSettings"},"panel":{"borderRadius":"5px","borderColor":"#e4e4e4","__typename":"EmailPanelSettings"},"__typename":"EmailThemeSettings"},"emoji":{"skinToneDefault":"#ffcd43","skinToneLight":"#fae3c5","skinToneMediumLight":"#e2cfa5","skinToneMedium":"#daa478","skinToneMediumDark":"#a78058","skinToneDark":"#5e4d43","__typename":"EmojiThemeSettings"},"heading":{"color":"var(--lia-bs-body-color)","fontFamily":"Inter","fontStyle":"NORMAL","fontWeight":"600","h1FontSize":"30px","h2FontSize":"25px","h3FontSize":"20px","h4FontSize":"18px","h5FontSize":"16px","h6FontSize":"16px","lineHeight":"1.2","subHeaderFontSize":"11px","subHeaderFontWeight":"500","h1LetterSpacing":"normal","h2LetterSpacing":"normal","h3LetterSpacing":"normal","h4LetterSpacing":"normal","h5LetterSpacing":"normal","h6LetterSpacing":"normal","subHeaderLetterSpacing":"2px","h1FontWeight":"var(--lia-bs-headings-font-weight)","h2FontWeight":"var(--lia-bs-headings-font-weight)","h3FontWeight":"var(--lia-bs-headings-font-weight)","h4FontWeight":"var(--lia-bs-headings-font-weight)","h5FontWeight":"var(--lia-bs-headings-font-weight)","h6FontWeight":"var(--lia-bs-headings-font-weight)","__typename":"HeadingThemeSettings"},"icons":{"size10":"10px","size12":"12px","size14":"14px","size16":"16px","size20":"20px","size24":"24px","size30":"30px","size40":"40px","size50":"50px","size60":"60px","size80":"80px","size120":"120px","size160":"160px","__typename":"IconsThemeSettings"},"imagePreview":{"bgColor":"var(--lia-bs-gray-900)","titleColor":"var(--lia-bs-white)","controlColor":"var(--lia-bs-white)","controlBgColor":"var(--lia-bs-gray-800)","__typename":"ImagePreviewThemeSettings"},"input":{"borderColor":"var(--lia-bs-gray-600)","disabledColor":"var(--lia-bs-gray-600)","focusBorderColor":"var(--lia-bs-primary)","labelMarginBottom":"10px","btnFontSize":"var(--lia-bs-font-size-sm)","focusBoxShadow":"0 0 0 3px hsla(var(--lia-bs-primary-h), var(--lia-bs-primary-s), var(--lia-bs-primary-l), 0.2)","checkLabelMarginBottom":"2px","checkboxBorderRadius":"3px","borderRadiusSm":"var(--lia-bs-border-radius-sm)","borderRadius":"var(--lia-bs-border-radius)","borderRadiusLg":"var(--lia-bs-border-radius-lg)","formTextMarginTop":"4px","textAreaBorderRadius":"var(--lia-bs-border-radius)","activeFillColor":"var(--lia-bs-primary)","__typename":"InputThemeSettings"},"loading":{"dotDarkColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.2)","dotLightColor":"hsla(var(--lia-bs-white-h), var(--lia-bs-white-s), var(--lia-bs-white-l), 0.5)","barDarkColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.06)","barLightColor":"hsla(var(--lia-bs-white-h), var(--lia-bs-white-s), var(--lia-bs-white-l), 0.4)","__typename":"LoadingThemeSettings"},"link":{"color":"var(--lia-bs-primary)","hoverColor":"hsl(var(--lia-bs-primary-h), var(--lia-bs-primary-s), calc(var(--lia-bs-primary-l) - 10%))","decoration":"none","hoverDecoration":"underline","__typename":"LinkThemeSettings"},"listGroup":{"itemPaddingY":"15px","itemPaddingX":"15px","borderColor":"var(--lia-bs-gray-300)","__typename":"ListGroupThemeSettings"},"modal":{"contentTextColor":"var(--lia-bs-body-color)","contentBg":"var(--lia-bs-white)","backgroundBg":"var(--lia-bs-black)","smSize":"440px","mdSize":"760px","lgSize":"1080px","backdropOpacity":0.3,"contentBoxShadowXs":"var(--lia-bs-box-shadow-sm)","contentBoxShadow":"var(--lia-bs-box-shadow)","headerFontWeight":"700","__typename":"ModalThemeSettings"},"navbar":{"position":"FIXED","background":{"attachment":null,"clip":null,"color":"var(--lia-bs-white)","imageAssetName":null,"imageLastModified":"0","origin":null,"position":"CENTER_CENTER","repeat":"NO_REPEAT","size":"COVER","__typename":"BackgroundProps"},"backgroundOpacity":0.8,"paddingTop":"15px","paddingBottom":"15px","borderBottom":"1px solid var(--lia-bs-border-color)","boxShadow":"var(--lia-bs-box-shadow-sm)","brandMarginRight":"30px","brandMarginRightSm":"10px","brandLogoHeight":"30px","linkGap":"10px","linkJustifyContent":"flex-start","linkPaddingY":"5px","linkPaddingX":"10px","linkDropdownPaddingY":"9px","linkDropdownPaddingX":"var(--lia-nav-link-px)","linkColor":"var(--lia-bs-body-color)","linkHoverColor":"var(--lia-bs-primary)","linkFontSize":"var(--lia-bs-font-size-sm)","linkFontStyle":"NORMAL","linkFontWeight":"400","linkTextTransform":"NONE","linkLetterSpacing":"normal","linkBorderRadius":"var(--lia-bs-border-radius-sm)","linkBgColor":"transparent","linkBgHoverColor":"transparent","linkBorder":"none","linkBorderHover":"none","linkBoxShadow":"none","linkBoxShadowHover":"none","linkTextBorderBottom":"none","linkTextBorderBottomHover":"none","dropdownPaddingTop":"10px","dropdownPaddingBottom":"15px","dropdownPaddingX":"10px","dropdownMenuOffset":"2px","dropdownDividerMarginTop":"10px","dropdownDividerMarginBottom":"10px","dropdownBorderColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.08)","controllerBgHoverColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.1)","controllerIconColor":"var(--lia-bs-body-color)","controllerIconHoverColor":"var(--lia-bs-body-color)","controllerTextColor":"var(--lia-nav-controller-icon-color)","controllerTextHoverColor":"var(--lia-nav-controller-icon-hover-color)","controllerHighlightColor":"hsla(30, 100%, 50%)","controllerHighlightTextColor":"var(--lia-yiq-light)","controllerBorderRadius":"var(--lia-border-radius-50)","hamburgerColor":"var(--lia-nav-controller-icon-color)","hamburgerHoverColor":"var(--lia-nav-controller-icon-color)","hamburgerBgColor":"transparent","hamburgerBgHoverColor":"transparent","hamburgerBorder":"none","hamburgerBorderHover":"none","collapseMenuMarginLeft":"20px","collapseMenuDividerBg":"var(--lia-nav-link-color)","collapseMenuDividerOpacity":0.16,"__typename":"NavbarThemeSettings"},"pager":{"textColor":"var(--lia-bs-link-color)","textFontWeight":"var(--lia-font-weight-md)","textFontSize":"var(--lia-bs-font-size-sm)","__typename":"PagerThemeSettings"},"panel":{"bgColor":"var(--lia-bs-white)","borderRadius":"var(--lia-bs-border-radius)","borderColor":"var(--lia-bs-border-color)","boxShadow":"none","__typename":"PanelThemeSettings"},"popover":{"arrowHeight":"8px","arrowWidth":"16px","maxWidth":"300px","minWidth":"100px","headerBg":"var(--lia-bs-white)","borderColor":"var(--lia-bs-border-color)","borderRadius":"var(--lia-bs-border-radius)","boxShadow":"0 0.5rem 1rem hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.15)","__typename":"PopoverThemeSettings"},"prism":{"color":"#000000","bgColor":"#f5f2f0","fontFamily":"var(--font-family-monospace)","fontSize":"var(--lia-bs-font-size-base)","fontWeightBold":"var(--lia-bs-font-weight-bold)","fontStyleItalic":"italic","tabSize":2,"highlightColor":"#b3d4fc","commentColor":"#62707e","punctuationColor":"#6f6f6f","namespaceOpacity":"0.7","propColor":"#990055","selectorColor":"#517a00","operatorColor":"#906736","operatorBgColor":"hsla(0, 0%, 100%, 0.5)","keywordColor":"#0076a9","functionColor":"#d3284b","variableColor":"#c14700","__typename":"PrismThemeSettings"},"rte":{"bgColor":"var(--lia-bs-white)","borderRadius":"var(--lia-panel-border-radius)","boxShadow":" var(--lia-panel-box-shadow)","customColor1":"#bfedd2","customColor2":"#fbeeb8","customColor3":"#f8cac6","customColor4":"#eccafa","customColor5":"#c2e0f4","customColor6":"#2dc26b","customColor7":"#f1c40f","customColor8":"#e03e2d","customColor9":"#b96ad9","customColor10":"#3598db","customColor11":"#169179","customColor12":"#e67e23","customColor13":"#ba372a","customColor14":"#843fa1","customColor15":"#236fa1","customColor16":"#ecf0f1","customColor17":"#ced4d9","customColor18":"#95a5a6","customColor19":"#7e8c8d","customColor20":"#34495e","customColor21":"#000000","customColor22":"#ffffff","defaultMessageHeaderMarginTop":"14px","defaultMessageHeaderMarginBottom":"10px","defaultMessageItemMarginTop":"0","defaultMessageItemMarginBottom":"10px","diffAddedColor":"hsla(170, 53%, 51%, 0.4)","diffChangedColor":"hsla(43, 97%, 63%, 0.4)","diffNoneColor":"hsla(0, 0%, 80%, 0.4)","diffRemovedColor":"hsla(9, 74%, 47%, 0.4)","specialMessageHeaderMarginTop":"14px","specialMessageHeaderMarginBottom":"10px","specialMessageItemMarginTop":"0","specialMessageItemMarginBottom":"10px","__typename":"RteThemeSettings"},"tags":{"bgColor":"var(--lia-bs-gray-200)","bgHoverColor":"var(--lia-bs-gray-400)","borderRadius":"var(--lia-bs-border-radius-sm)","color":"var(--lia-bs-body-color)","hoverColor":"var(--lia-bs-body-color)","fontWeight":"var(--lia-font-weight-md)","fontSize":"var(--lia-font-size-xxs)","textTransform":"UPPERCASE","letterSpacing":"0.5px","__typename":"TagsThemeSettings"},"toasts":{"borderRadius":"var(--lia-bs-border-radius)","paddingX":"12px","__typename":"ToastsThemeSettings"},"typography":{"fontFamilyBase":"Atkinson Hyperlegible","fontStyleBase":"NORMAL","fontWeightBase":"400","fontWeightLight":"300","fontWeightNormal":"400","fontWeightMd":"500","fontWeightBold":"700","letterSpacingSm":"normal","letterSpacingXs":"normal","lineHeightBase":"1.3","fontSizeBase":"15px","fontSizeXxs":"11px","fontSizeXs":"12px","fontSizeSm":"13px","fontSizeLg":"20px","fontSizeXl":"24px","smallFontSize":"14px","customFonts":[],"__typename":"TypographyThemeSettings"},"unstyledListItem":{"marginBottomSm":"5px","marginBottomMd":"10px","marginBottomLg":"15px","marginBottomXl":"20px","marginBottomXxl":"25px","__typename":"UnstyledListItemThemeSettings"},"yiq":{"light":"#ffffff","dark":"#000000","__typename":"YiqThemeSettings"},"colorLightness":{"primaryDark":0.36,"primaryLight":0.74,"primaryLighter":0.89,"primaryLightest":0.95,"infoDark":0.39,"infoLight":0.72,"infoLighter":0.85,"infoLightest":0.93,"successDark":0.24,"successLight":0.62,"successLighter":0.8,"successLightest":0.91,"warningDark":0.39,"warningLight":0.68,"warningLighter":0.84,"warningLightest":0.93,"dangerDark":0.41,"dangerLight":0.72,"dangerLighter":0.89,"dangerLightest":0.95,"__typename":"ColorLightnessThemeSettings"},"localOverride":false,"__typename":"Theme"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/common/Loading/LoadingDot-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/common/Loading/LoadingDot-1743097583657","value":{"title":"Loading..."},"localOverride":false},"CachedAsset:text:en_US-components/common/EmailVerification-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/common/EmailVerification-1743097583657","value":{"email.verification.title":"Email Verification Required","email.verification.message.update.email":"To participate in the community, you must first verify your email address. The verification email was sent to {email}. To change your email, visit My Settings.","email.verification.message.resend.email":"To participate in the community, you must first verify your email address. The verification email was sent to {email}. Resend email."},"localOverride":false},"CachedAsset:text:en_US-pages/tags/TagPage-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-pages/tags/TagPage-1743097583657","value":{"tagPageTitle":"Tag:\"{tagName}\" | {communityTitle}","tagPageForNodeTitle":"Tag:\"{tagName}\" in \"{title}\" | {communityTitle}","name":"Tags Page","tag":"Tag: {tagName}"},"localOverride":false},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bi0zNC0xM2k0MzE3N0Q2NjFBRDg5NDAy\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bi0zNC0xM2k0MzE3N0Q2NjFBRDg5NDAy","mimeType":"image/png"},"Category:category:Articles":{"__typename":"Category","id":"category:Articles","entityType":"CATEGORY","displayId":"Articles","nodeType":"category","depth":1,"title":"Articles","shortTitle":"Articles","parent":{"__ref":"Category:category:top"},"categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Category:category:top":{"__typename":"Category","id":"category:top","displayId":"top","nodeType":"category","depth":0,"title":"Top"},"Tkb:board:TechnicalArticles":{"__typename":"Tkb","id":"board:TechnicalArticles","entityType":"TKB","displayId":"TechnicalArticles","nodeType":"board","depth":2,"conversationStyle":"TKB","title":"Technical Articles","description":"F5 SMEs share good practice.","avatar":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bi0zNC0xM2k0MzE3N0Q2NjFBRDg5NDAy\"}"},"profileSettings":{"__typename":"ProfileSettings","language":null},"parent":{"__ref":"Category:category:Articles"},"ancestors":{"__typename":"CoreNodeConnection","edges":[{"__typename":"CoreNodeEdge","node":{"__ref":"Community:community:zihoc95639"}},{"__typename":"CoreNodeEdge","node":{"__ref":"Category:category:Articles"}}]},"userContext":{"__typename":"NodeUserContext","canAddAttachments":false,"canUpdateNode":false,"canPostMessages":false,"isSubscribed":false},"boardPolicies":{"__typename":"BoardPolicies","canPublishArticleOnCreate":{"__typename":"PolicyResult","failureReason":{"__typename":"FailureReason","message":"error.lithium.policies.forums.policy_can_publish_on_create_workflow_action.accessDenied","key":"error.lithium.policies.forums.policy_can_publish_on_create_workflow_action.accessDenied","args":[]}},"canReadNode":{"__typename":"PolicyResult","failureReason":null}},"tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"shortTitle":"Technical Articles","tagPolicies":{"__typename":"TagPolicies","canSubscribeTagOnNode":{"__typename":"PolicyResult","failureReason":{"__typename":"FailureReason","message":"error.lithium.policies.labels.action.corenode.subscribe_labels.allow.accessDenied","key":"error.lithium.policies.labels.action.corenode.subscribe_labels.allow.accessDenied","args":[]}},"canManageTagDashboard":{"__typename":"PolicyResult","failureReason":{"__typename":"FailureReason","message":"error.lithium.policies.labels.action.corenode.admin_labels.allow.accessDenied","key":"error.lithium.policies.labels.action.corenode.admin_labels.allow.accessDenied","args":[]}}}},"CachedAsset:quilt:f5.prod:pages/tags/TagPage:board:TechnicalArticles-1743097587532":{"__typename":"CachedAsset","id":"quilt:f5.prod:pages/tags/TagPage:board:TechnicalArticles-1743097587532","value":{"id":"TagPage","container":{"id":"Common","headerProps":{"removeComponents":["community.widget.bannerWidget"],"__typename":"QuiltContainerSectionProps"},"items":[{"id":"tag-header-widget","layout":"ONE_COLUMN","bgColor":"var(--lia-bs-white)","showBorder":"BOTTOM","sectionEditLevel":"LOCKED","columnMap":{"main":[{"id":"tags.widget.TagsHeaderWidget","__typename":"QuiltComponent"}],"__typename":"OneSectionColumns"},"__typename":"OneColumnQuiltSection"},{"id":"messages-list-for-tag-widget","layout":"ONE_COLUMN","columnMap":{"main":[{"id":"messages.widget.messageListForNodeByRecentActivityWidget","props":{"viewVariant":{"type":"inline","props":{"useUnreadCount":true,"useViewCount":true,"useAuthorLogin":true,"clampBodyLines":3,"useAvatar":true,"useBoardIcon":false,"useKudosCount":true,"usePreviewMedia":true,"useTags":false,"useNode":true,"useNodeLink":true,"useTextBody":true,"truncateBodyLength":-1,"useBody":true,"useRepliesCount":true,"useSolvedBadge":true,"timeStampType":"conversation.lastPostingActivityTime","useMessageTimeLink":true,"clampSubjectLines":2}},"panelType":"divider","useTitle":false,"hideIfEmpty":false,"pagerVariant":{"type":"loadMore"},"style":"list","showTabs":true,"tabItemMap":{"default":{"mostRecent":true,"mostRecentUserContent":false,"newest":false},"additional":{"mostKudoed":true,"mostViewed":true,"mostReplies":false,"noReplies":false,"noSolutions":false,"solutions":false}}},"__typename":"QuiltComponent"}],"__typename":"OneSectionColumns"},"__typename":"OneColumnQuiltSection"}],"__typename":"QuiltContainer"},"__typename":"Quilt"},"localOverride":false},"CachedAsset:quiltWrapper:f5.prod:Common:1742463219590":{"__typename":"CachedAsset","id":"quiltWrapper:f5.prod:Common:1742463219590","value":{"id":"Common","header":{"backgroundImageProps":{"assetName":"header.jpg","backgroundSize":"COVER","backgroundRepeat":"NO_REPEAT","backgroundPosition":"LEFT_CENTER","lastModified":"1702932449000","__typename":"BackgroundImageProps"},"backgroundColor":"transparent","items":[{"id":"custom.widget.Beta_MetaNav","props":{"widgetVisibility":"signedInOrAnonymous","useTitle":true,"useBackground":false,"title":"","lazyLoad":false},"__typename":"QuiltComponent"},{"id":"community.widget.navbarWidget","props":{"showUserName":false,"showRegisterLink":true,"style":{"boxShadow":"var(--lia-bs-box-shadow-sm)","linkFontWeight":"700","controllerHighlightColor":"hsla(30, 100%, 50%)","dropdownDividerMarginBottom":"10px","hamburgerBorderHover":"none","linkFontSize":"15px","linkBoxShadowHover":"none","backgroundOpacity":0.4,"controllerBorderRadius":"var(--lia-border-radius-50)","hamburgerBgColor":"transparent","linkTextBorderBottom":"none","hamburgerColor":"var(--lia-nav-controller-icon-color)","brandLogoHeight":"48px","linkLetterSpacing":"normal","linkBgHoverColor":"transparent","collapseMenuDividerOpacity":0.16,"paddingBottom":"10px","dropdownPaddingBottom":"15px","dropdownMenuOffset":"2px","hamburgerBgHoverColor":"transparent","borderBottom":"0","hamburgerBorder":"none","dropdownPaddingX":"10px","brandMarginRightSm":"10px","linkBoxShadow":"none","linkJustifyContent":"center","linkColor":"var(--lia-bs-primary)","collapseMenuDividerBg":"var(--lia-nav-link-color)","dropdownPaddingTop":"10px","controllerHighlightTextColor":"var(--lia-yiq-dark)","background":{"imageAssetName":"","color":"var(--lia-bs-white)","size":"COVER","repeat":"NO_REPEAT","position":"CENTER_CENTER","imageLastModified":""},"linkBorderRadius":"var(--lia-bs-border-radius-sm)","linkHoverColor":"var(--lia-bs-primary)","position":"FIXED","linkBorder":"none","linkTextBorderBottomHover":"2px solid #0C5C8D","brandMarginRight":"30px","hamburgerHoverColor":"var(--lia-nav-controller-icon-color)","linkBorderHover":"none","collapseMenuMarginLeft":"20px","linkFontStyle":"NORMAL","linkPaddingX":"10px","paddingTop":"10px","linkPaddingY":"5px","linkTextTransform":"NONE","dropdownBorderColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.08)","controllerBgHoverColor":"hsla(var(--lia-bs-black-h), var(--lia-bs-black-s), var(--lia-bs-black-l), 0.1)","linkDropdownPaddingX":"var(--lia-nav-link-px)","linkBgColor":"transparent","linkDropdownPaddingY":"9px","controllerIconColor":"#0C5C8D","dropdownDividerMarginTop":"10px","linkGap":"10px","controllerIconHoverColor":"#0C5C8D"},"links":{"sideLinks":[],"mainLinks":[{"children":[{"linkType":"INTERNAL","id":"migrated-link-1","params":{"boardId":"TechnicalForum","categoryId":"Forums"},"routeName":"ForumBoardPage"},{"linkType":"INTERNAL","id":"migrated-link-2","params":{"boardId":"WaterCooler","categoryId":"Forums"},"routeName":"ForumBoardPage"}],"linkType":"INTERNAL","id":"migrated-link-0","params":{"categoryId":"Forums"},"routeName":"CategoryPage"},{"children":[{"linkType":"INTERNAL","id":"migrated-link-4","params":{"boardId":"codeshare","categoryId":"CrowdSRC"},"routeName":"TkbBoardPage"},{"linkType":"INTERNAL","id":"migrated-link-5","params":{"boardId":"communityarticles","categoryId":"CrowdSRC"},"routeName":"TkbBoardPage"}],"linkType":"INTERNAL","id":"migrated-link-3","params":{"categoryId":"CrowdSRC"},"routeName":"CategoryPage"},{"children":[{"linkType":"INTERNAL","id":"migrated-link-7","params":{"boardId":"TechnicalArticles","categoryId":"Articles"},"routeName":"TkbBoardPage"},{"linkType":"INTERNAL","id":"article-series","params":{"boardId":"article-series","categoryId":"Articles"},"routeName":"TkbBoardPage"},{"linkType":"INTERNAL","id":"security-insights","params":{"boardId":"security-insights","categoryId":"Articles"},"routeName":"TkbBoardPage"},{"linkType":"INTERNAL","id":"migrated-link-8","params":{"boardId":"DevCentralNews","categoryId":"Articles"},"routeName":"TkbBoardPage"}],"linkType":"INTERNAL","id":"migrated-link-6","params":{"categoryId":"Articles"},"routeName":"CategoryPage"},{"children":[{"linkType":"INTERNAL","id":"migrated-link-10","params":{"categoryId":"CommunityGroups"},"routeName":"CategoryPage"},{"linkType":"INTERNAL","id":"migrated-link-11","params":{"categoryId":"F5-Groups"},"routeName":"CategoryPage"}],"linkType":"INTERNAL","id":"migrated-link-9","params":{"categoryId":"GroupsCategory"},"routeName":"CategoryPage"},{"children":[],"linkType":"INTERNAL","id":"migrated-link-12","params":{"boardId":"Events","categoryId":"top"},"routeName":"EventBoardPage"},{"children":[],"linkType":"INTERNAL","id":"migrated-link-13","params":{"boardId":"Suggestions","categoryId":"top"},"routeName":"IdeaBoardPage"},{"children":[],"linkType":"EXTERNAL","id":"Common-external-link","url":"https://community.f5.com/c/how-do-i","target":"SELF"}]},"className":"QuiltComponent_lia-component-edit-mode__lQ9Z6","showSearchIcon":false},"__typename":"QuiltComponent"},{"id":"community.widget.bannerWidget","props":{"backgroundColor":"transparent","visualEffects":{"showBottomBorder":false},"backgroundImageProps":{"backgroundSize":"COVER","backgroundPosition":"CENTER_CENTER","backgroundRepeat":"NO_REPEAT"},"fontColor":"#222222"},"__typename":"QuiltComponent"},{"id":"community.widget.breadcrumbWidget","props":{"backgroundColor":"var(--lia-bs-primary)","linkHighlightColor":"#FFFFFF","visualEffects":{"showBottomBorder":false},"backgroundOpacity":60,"linkTextColor":"#FFFFFF"},"__typename":"QuiltComponent"}],"__typename":"QuiltWrapperSection"},"footer":{"backgroundImageProps":{"assetName":null,"backgroundSize":"COVER","backgroundRepeat":"NO_REPEAT","backgroundPosition":"CENTER_CENTER","lastModified":null,"__typename":"BackgroundImageProps"},"backgroundColor":"var(--lia-bs-body-color)","items":[{"id":"custom.widget.Beta_Footer","props":{"widgetVisibility":"signedInOrAnonymous","useTitle":true,"useBackground":false,"title":"","lazyLoad":false},"__typename":"QuiltComponent"},{"id":"custom.widget.Tag_Manager_Helper","props":{"widgetVisibility":"signedInOrAnonymous","useTitle":true,"useBackground":false,"title":"","lazyLoad":false},"__typename":"QuiltComponent"},{"id":"custom.widget.Consent_Blackbar","props":{"widgetVisibility":"signedInOrAnonymous","useTitle":true,"useBackground":false,"title":"","lazyLoad":false},"__typename":"QuiltComponent"}],"__typename":"QuiltWrapperSection"},"__typename":"QuiltWrapper","localOverride":false},"localOverride":false},"CachedAsset:text:en_US-components/common/ActionFeedback-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/common/ActionFeedback-1743097583657","value":{"joinedGroupHub.title":"Welcome","joinedGroupHub.message":"You are now a member of this group and are subscribed to updates.","groupHubInviteNotFound.title":"Invitation Not Found","groupHubInviteNotFound.message":"Sorry, we could not find your invitation to the group. The owner may have canceled the invite.","groupHubNotFound.title":"Group Not Found","groupHubNotFound.message":"The grouphub you tried to join does not exist. It may have been deleted.","existingGroupHubMember.title":"Already Joined","existingGroupHubMember.message":"You are already a member of this group.","accountLocked.title":"Account Locked","accountLocked.message":"Your account has been locked due to multiple failed attempts. Try again in {lockoutTime} minutes.","editedGroupHub.title":"Changes Saved","editedGroupHub.message":"Your group has been updated.","leftGroupHub.title":"Goodbye","leftGroupHub.message":"You are no longer a member of this group and will not receive future updates.","deletedGroupHub.title":"Deleted","deletedGroupHub.message":"The group has been deleted.","groupHubCreated.title":"Group Created","groupHubCreated.message":"{groupHubName} is ready to use","accountClosed.title":"Account Closed","accountClosed.message":"The account has been closed and you will now be redirected to the homepage","resetTokenExpired.title":"Reset Password Link has Expired","resetTokenExpired.message":"Try resetting your password again","invalidUrl.title":"Invalid URL","invalidUrl.message":"The URL you're using is not recognized. Verify your URL and try again.","accountClosedForUser.title":"Account Closed","accountClosedForUser.message":"{userName}'s account is closed","inviteTokenInvalid.title":"Invitation Invalid","inviteTokenInvalid.message":"Your invitation to the community has been canceled or expired.","inviteTokenError.title":"Invitation Verification Failed","inviteTokenError.message":"The url you are utilizing is not recognized. Verify your URL and try again","pageNotFound.title":"Access Denied","pageNotFound.message":"You do not have access to this area of the community or it doesn't exist","eventAttending.title":"Responded as Attending","eventAttending.message":"You'll be notified when there's new activity and reminded as the event approaches","eventInterested.title":"Responded as Interested","eventInterested.message":"You'll be notified when there's new activity and reminded as the event approaches","eventNotFound.title":"Event Not Found","eventNotFound.message":"The event you tried to respond to does not exist.","redirectToRelatedPage.title":"Showing Related Content","redirectToRelatedPageForBaseUsers.title":"Showing Related Content","redirectToRelatedPageForBaseUsers.message":"The content you are trying to access is archived","redirectToRelatedPage.message":"The content you are trying to access is archived","relatedUrl.archivalLink.flyoutMessage":"The content you are trying to access is archived View Archived Content"},"localOverride":false},"CachedAsset:component:custom.widget.Beta_MetaNav-en-1742463330781":{"__typename":"CachedAsset","id":"component:custom.widget.Beta_MetaNav-en-1742463330781","value":{"component":{"id":"custom.widget.Beta_MetaNav","template":{"id":"Beta_MetaNav","markupLanguage":"HANDLEBARS","style":null,"texts":null,"defaults":{"config":{"applicablePages":[],"description":"MetaNav menu at the top of every page.","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"components":[{"id":"custom.widget.Beta_MetaNav","form":null,"config":null,"props":[],"__typename":"Component"}],"grouping":"CUSTOM","__typename":"ComponentTemplate"},"properties":{"config":{"applicablePages":[],"description":"MetaNav menu at the top of every page.","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"form":null,"__typename":"Component","localOverride":false},"globalCss":null,"form":null},"localOverride":false},"CachedAsset:component:custom.widget.Beta_Footer-en-1742463330781":{"__typename":"CachedAsset","id":"component:custom.widget.Beta_Footer-en-1742463330781","value":{"component":{"id":"custom.widget.Beta_Footer","template":{"id":"Beta_Footer","markupLanguage":"HANDLEBARS","style":null,"texts":null,"defaults":{"config":{"applicablePages":[],"description":"DevCentral´s custom footer.","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"components":[{"id":"custom.widget.Beta_Footer","form":null,"config":null,"props":[],"__typename":"Component"}],"grouping":"CUSTOM","__typename":"ComponentTemplate"},"properties":{"config":{"applicablePages":[],"description":"DevCentral´s custom footer.","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"form":null,"__typename":"Component","localOverride":false},"globalCss":null,"form":null},"localOverride":false},"CachedAsset:component:custom.widget.Tag_Manager_Helper-en-1742463330781":{"__typename":"CachedAsset","id":"component:custom.widget.Tag_Manager_Helper-en-1742463330781","value":{"component":{"id":"custom.widget.Tag_Manager_Helper","template":{"id":"Tag_Manager_Helper","markupLanguage":"HANDLEBARS","style":null,"texts":null,"defaults":{"config":{"applicablePages":[],"description":"Helper widget to inject Tag Manager scripts into head element","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"components":[{"id":"custom.widget.Tag_Manager_Helper","form":null,"config":null,"props":[],"__typename":"Component"}],"grouping":"CUSTOM","__typename":"ComponentTemplate"},"properties":{"config":{"applicablePages":[],"description":"Helper widget to inject Tag Manager scripts into head element","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"form":null,"__typename":"Component","localOverride":false},"globalCss":null,"form":null},"localOverride":false},"CachedAsset:component:custom.widget.Consent_Blackbar-en-1742463330781":{"__typename":"CachedAsset","id":"component:custom.widget.Consent_Blackbar-en-1742463330781","value":{"component":{"id":"custom.widget.Consent_Blackbar","template":{"id":"Consent_Blackbar","markupLanguage":"HTML","style":null,"texts":null,"defaults":{"config":{"applicablePages":[],"description":"","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"components":[{"id":"custom.widget.Consent_Blackbar","form":null,"config":null,"props":[],"__typename":"Component"}],"grouping":"TEXTHTML","__typename":"ComponentTemplate"},"properties":{"config":{"applicablePages":[],"description":"","fetchedContent":null,"__typename":"ComponentConfiguration"},"props":[],"__typename":"ComponentProperties"},"form":null,"__typename":"Component","localOverride":false},"globalCss":null,"form":null},"localOverride":false},"CachedAsset:text:en_US-components/community/Breadcrumb-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/community/Breadcrumb-1743097583657","value":{"navLabel":"Breadcrumbs","dropdown":"Additional parent page navigation"},"localOverride":false},"CachedAsset:text:en_US-components/tags/TagsHeaderWidget-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/tags/TagsHeaderWidget-1743097583657","value":{"tag":"{tagName}","topicsCount":"{count} {count, plural, one {Topic} other {Topics}}"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageListForNodeByRecentActivityWidget-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageListForNodeByRecentActivityWidget-1743097583657","value":{"title@userScope:other":"Recent Content","title@userScope:self":"Contributions","title@board:FORUM@userScope:other":"Recent Discussions","title@board:BLOG@userScope:other":"Recent Blogs","emptyDescription":"No content to show","MessageListForNodeByRecentActivityWidgetEditor.nodeScope.label":"Scope","title@instance:1706288370055":"Content Feed","title@instance:1743095186784":"Most Recent Updates","title@instance:1704317906837":"Content Feed","title@instance:1743095018194":"Most Recent Updates","title@instance:1702668293472":"Community Feed","title@instance:1743095117047":"Most Recent Updates","title@instance:1704319314827":"Blog Feed","title@instance:1743095235555":"Most Recent Updates","title@instance:1704320290851":"My Contributions","title@instance:1703720491809":"Forum Feed","title@instance:1743095311723":"Most Recent Updates","title@instance:1703028709746":"Group Content Feed","title@instance:VTsglH":"Content Feed"},"localOverride":false},"Category:category:Forums":{"__typename":"Category","id":"category:Forums","categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Forum:board:TechnicalForum":{"__typename":"Forum","id":"board:TechnicalForum","forumPolicies":{"__typename":"ForumPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Forum:board:WaterCooler":{"__typename":"Forum","id":"board:WaterCooler","forumPolicies":{"__typename":"ForumPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Tkb:board:DevCentralNews":{"__typename":"Tkb","id":"board:DevCentralNews","tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Category:category:GroupsCategory":{"__typename":"Category","id":"category:GroupsCategory","categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Category:category:F5-Groups":{"__typename":"Category","id":"category:F5-Groups","categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Category:category:CommunityGroups":{"__typename":"Category","id":"category:CommunityGroups","categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Occasion:board:Events":{"__typename":"Occasion","id":"board:Events","boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"occasionPolicies":{"__typename":"OccasionPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Idea:board:Suggestions":{"__typename":"Idea","id":"board:Suggestions","boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"ideaPolicies":{"__typename":"IdeaPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Category:category:CrowdSRC":{"__typename":"Category","id":"category:CrowdSRC","categoryPolicies":{"__typename":"CategoryPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Tkb:board:codeshare":{"__typename":"Tkb","id":"board:codeshare","tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Tkb:board:communityarticles":{"__typename":"Tkb","id":"board:communityarticles","tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Tkb:board:security-insights":{"__typename":"Tkb","id":"board:security-insights","tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Tkb:board:article-series":{"__typename":"Tkb","id":"board:article-series","tkbPolicies":{"__typename":"TkbPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}},"boardPolicies":{"__typename":"BoardPolicies","canReadNode":{"__typename":"PolicyResult","failureReason":null}}},"Conversation:conversation:300547":{"__typename":"Conversation","id":"conversation:300547","topic":{"__typename":"TkbTopicMessage","uid":300547},"lastPostingActivityTime":"2024-10-27T14:23:00.033-07:00","solved":false},"User:user:303102":{"__typename":"User","uid":303102,"login":"Ulises_Alonso","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/images/dS0zMDMxMDItNnNGUVZV?image-coordinates=90%2C0%2C517%2C427"},"id":"user:303102"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNzdpMDI3MDVFRkJEN0I1QTYxOA?revision=12\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNzdpMDI3MDVFRkJEN0I1QTYxOA?revision=12","title":"Break or Extend Kubernetes.png","associationType":"TEASER","width":2088,"height":690,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNjVpNEI4MzY2QTI1OEFGQTBDRg?revision=12\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNjVpNEI4MzY2QTI1OEFGQTBDRg?revision=12","title":"Break or Extend Kubernetes.png","associationType":"BODY","width":2088,"height":690,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNjhpODdDQTI2MTg2MkNDQTY4Qg?revision=12\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNjhpODdDQTI2MTg2MkNDQTY4Qg?revision=12","title":"SPK-software-components.png","associationType":"BODY","width":2048,"height":1152,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNjZpN0FFQThCMkE5Q0E3QTNCRg?revision=12\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNjZpN0FFQThCMkE5Q0E3QTNCRg?revision=12","title":"SPK-general-architecture.png","associationType":"BODY","width":2086,"height":1172,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNzVpQUYzNTM1RTlGQjgyQTA2NA?revision=12\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNzVpQUYzNTM1RTlGQjgyQTA2NA?revision=12","title":"SPK-traffic-flows.png","associationType":"BODY","width":2048,"height":1128,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNzZpRUUyODNDMTMzMDc1NDEwMQ?revision=12\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNzZpRUUyODNDMTMzMDc1NDEwMQ?revision=12","title":"SPK-physical.png","associationType":"BODY","width":2048,"height":1128,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyOTRpREUxNUNENUI4RjM3NjJDNw?revision=12\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyOTRpREUxNUNENUI4RjM3NjJDNw?revision=12","title":"Data plane architecture - security.png","associationType":"BODY","width":2048,"height":1128,"altText":null},"TkbTopicMessage:message:300547":{"__typename":"TkbTopicMessage","subject":"BIG-IP Next SPK: a Kubernetes native ingress and egress gateway for Telco workloads","conversation":{"__ref":"Conversation:conversation:300547"},"id":"message:300547","revisionNum":12,"uid":300547,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:303102"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":" BIG-IP Next SPK: a Kubernetes native ingress and egress gateway for Telco workloads that is CNF agnostic. \n ","introduction":"","metrics":{"__typename":"MessageMetrics","views":2825},"postTime":"2022-09-25T18:00:00.028-07:00","lastPublishTime":"2022-09-25T18:00:00.028-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" \n Kubernetes has a simplified networking model which was designed for general IT workloads which only use TCP/HTTP protocols, and a simplified networking model with a single IP address per POD (the smallest deployable unit of computing in Kubernetes) and a single external gateway. On the other hand, Telco deployments require: \n \n 3GPP protocols support. \n Transitional 4G to 5G facilities. \n Network capabilities to match Telco's networks by providing multiple external network connectivity, allowing different paths depending on the Network Function (NF), dynamic routing, etc... \n \n Hopefully, Kubernetes has been designed to be extensible yet it's up to the software and infrastructure architects to design solutions with good practices by following Kubernetes patterns. It´s usual that NF vendors use additional interfaces (multus CNI) for each NF PODs. By doing this, there is no dynamic advertising of addresses as the PODs in the deployment change or a good way to track these addresses outside the cluster by network elements such as firewalls. \n Alternatively, NF vendors try to hide this complexity by selling turn-key solutions with dedicated Kubernetes clusters for each NF or vendor. Therefore the customer ends up with multiple clusters typically disimilar, ultimately defeating the whole purpose of Kubernetes which aims to homogenize application's environment in a single platform. In a way, this this approach is equivalent to having a load balancer for each application. Also, the management of addresses by external network elements is still inaddecuate because identification of NFs is done in a coarse manner by identifying clusters' addresses. \n These two approaches break Kuberentes patterns by adding complexity in the form of non-homogenous networking to the different NFs. \n In this post we introduce F5 BIG-IP Next Service Proxy Kubernetes (SPK) -- BIG-IP Next SPK for short -- architecture which overcomes these limitations while being Network Functions-agnostic. We will use Red Hat's Openshift as reference platform. \n BIG-IP Next SPK software architecture \n BIG-IP Next SPK is a cloud-native solution which runs inside the Kubernetes cluster and is made out of independent components which can be scaled-out. It's headless software (no graphical UI) and it's managed using the Kubernetes API. The major software components are shown next. \n \n BIG-IP Next SPK's data plane makes use of the widely trusted BIG-IP’s Traffic Management Microkernel (TMM) data plane. This allows for a high performance, dependable product from the start. A dynamic routing component configures the BGP peering with the upstream routers for ECMP load distribution. The BFD feature for fast failure detection is available. The session persistence is a distributed database which allows to store connection related state such as pool member persistence, SNATs, NAT46 translations, etc... This database is backed in Kubernetes Persistent Volume which allows this information to be available even after POD restarts. The controller is the component which interacts with the Kubernetes API that customers use to configure BIG-IP Next SPK. Fluentd is a high-performance industry standard for exposing BIG-IP Next SPK metrics and logs to external tools. \n BIG-IP Next SPK network architecture \n The overall network architecture is shown next. Out of this picture we would like to emphasise the following items: \n \n Independent BIG-IP Next SPK instances, with completely different external network config, can handle ingress & egress traffic for each namespace individually. \n BIG-IP Next SPK is highly scalable at POD level (1-24 cores) and at cluster level, limited by the upstream ECMP capabilities. \n \n A more detailed view of the network path is shown next. From this diagram we want to emphasise: \n \n PODs make use of BIG-IP Next SPK transparently by continue using the CNI as usual. \n BIG-IP Next SPK is a single tier ingress/egress solution not requiring external LB. \n BIG-IP Next SPK has direct POD IP visibility, there is no kube-proxy or other IP-translating mechanism in between. \n \n \n As depicted above, BIG-IP Next SPK has two types of interfaces: external facing the upstream routers and internal facing the Kubernetes networking. Openshift's networking facilitates that using BIG-IP Next SPK in a cluster is optional in a per-namespace basis and this is done transparently to the applications. No change or configuration needs to be done in the applications. Openshift uses for its networking the OVNKubernetes CNI. It can be seen in the picture that the applications continue using the OVNKubernetes router as default and only gateway. \n Finally we will show a L2 view of the networks in a cluster with BIG-IP Next SPK. From this diagram we want to emphasise: \n \n How regular nodes hosting applications have no modifications either. \n How BIG-IP Next SPK is typically setup with link aggregations and SR-IOV wire-speed interfaces. \n How the L3 path between BIG-IP Next SPK and the application's nodes is validated by means of using BFD. \n \n \n Using BIG-IP Next SPK \n In order to use BIG-IP Next SPK no changes need to be done in the applications or in the namespace hosting the applications. At BIG-IP Next SPK configuration time we will instruct which namespace we want BIG-IP Next SPK to handle and voilà: BIG-IP Next SPK becomes the next-hop of OVNKubernetes router for that namespace. No labels or other artifacts need to be configured manually. \n Defining BIG-IP Next SPK services configurations is done thorugh the Kubernetes API using Custom Resource Definitions (CRDs). At time of this writting the following resources are avaiilable: \n \n \n \n \n F5SPKIngressTCP Manages ingress layer 4 TCP application traffic. \n F5SPKIngressUDP Manages ingress layer 4 UDP application traffic. \n F5SPKIngressDiameter Manages Diameter traffic unifying ingress and egress traffic using either TCP or SCTP and keeps sessions persistent using the SESSION-ID attribute value pair (AVP) by default. \n F5SPKIngressNGAP Balances ingress datagram loads for SCTP or NG application protocol (NGAP) signaling. \n F5SPKEgress Enables egress traffic for pods using SNAT or DNS/NAT46. DNS cache and rate limiting parameters can be configured. \n F5SPKSnatpool Allocates IP addresses for egress pod connections. \n F5SPKDNSCache Provides high-performance, transparent DNS resolution and caching for the F5SPKEgress resources. \n F5SPKPortListandF5SPKAddressList Creates sets of ports and addresses, respectively, to make creating and updating services easier. \n \n Besides the above resource list we would like to highlight 3 functionalities that should not be overlooked: \n \n IPv6 support\n \n \n \n BIG-IP Next SPK fully supports IPv4/IPv6 dual-stack networking as implemented in Kubernetes v1.21 or later. BIG-IP Next SPK’s DNS46/NAT46 feature, however, does not rely on Kubernetes IPv4/IPv6 dual-stack and therefore, it can be used with earlier versions of Kubernetes. \n \n \n \n \n DNS46/NAT46 translation \n \n \n The adoption of IPv6 in new 5G deployments has created a need to interact with older IPv4 single stack components and services. BIG-IP Next SPK’s DNS46/NAT46 provides this interoperability, easing the adoption and transition between IPv4 and IPv6 services. This solution allows IPv4 applications to access any IPv6 application on demand, without requiring reconfiguration. \n \n \n \n Application hairpinning The application hairpinning feature is used to differentiate between internal and external clients. A selected set of internal clients accesses an BIG-IP Next SPK Service with the same domain name or IP address as that of another BIG-IP Next SPK Service, which is used by external clients using different configurations. The key difference between the two types of connections is that internal clients are connected using SNAT and external clients are not. This is done by installing two BIG-IP Next SPK CRs of the same type, for example F5SPKIngressTCP, with each CR enabled on a selected VLAN or VLAN list. \n \n ´BIG-IP Next SPKs roadmap \n In the upcoming releases BIG-IP Next SPK will continue expanding its traffic management capabilities by exposing more TMM capabilities through the Kubernetes API, noticiably HTTP/2. \n Also, BIG-IP Next SPK will be gaining more security oriented features. At present it is being targeted the following features: \n \n Firewall \n DDoS protection \n WAF \n \n These security features are specially useful because BIG-IP Next SPK constitutes a security boundary with respect of all the workloads in the cluster and kubernetes itself (CNI, API, basic node management). Although BIG-IP Next SPK is running inside the Kubernetes cluster, it is the only software that manages the external network interfaces at L3. This is depicted in the next figure. \n \n \n These security features have been available for long time in BIG-IP products and at present we are capturing customers´ input to design the best APIs possible for exposing these functionalities following Kubernetes patterns. \n Conclusion \n \n \n \n This article introduces a scalable and dependable high performance gateway solution that delivers the granular ingress and egress controls in Kubernetes-based deployments that Telcos need. It builds on the unique potential of OpenShift external gateways by making full use of OpenShift capabilities—an industry first. Use cases that particularly benefit include 5GC and MEC. Plus, the BIG-IP Next SPK solution can dynamically translate IPv4 to IPv6 network addresses, which solves the problem of mixed IPv4 and IPv6 deployments. The result is a gateway solution flexible enough to adapt to new and evolving Telco needs while offering interoperability with pre-5G services. For additional information please check the RedHat & F5 co-written white paper F5 Telco Gateway for Red Hat OpenShift and the official BIG-IP Next SPK documentation. \n \n \n \n \n \n \n \n ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"10027","kudosSumWeight":5,"repliesCount":1,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNzdpMDI3MDVFRkJEN0I1QTYxOA?revision=12\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNjVpNEI4MzY2QTI1OEFGQTBDRg?revision=12\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNjhpODdDQTI2MTg2MkNDQTY4Qg?revision=12\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNjZpN0FFQThCMkE5Q0E3QTNCRg?revision=12\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDU","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNzVpQUYzNTM1RTlGQjgyQTA2NA?revision=12\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDY","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyNzZpRUUyODNDMTMzMDc1NDEwMQ?revision=12\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDc","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0zMDA1NDctMTkyOTRpREUxNUNENUI4RjM3NjJDNw?revision=12\"}"}}],"totalCount":7,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:280348":{"__typename":"Conversation","id":"conversation:280348","topic":{"__typename":"TkbTopicMessage","uid":280348},"lastPostingActivityTime":"2023-09-26T14:46:25.167-07:00","solved":false},"User:user:56738":{"__typename":"User","uid":56738,"login":"ltwagnon","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/images/dS01NjczOC0xNjM3OGk3QkQ0M0UxRDAzRDEzMDg3"},"id":"user:56738"},"TkbTopicMessage:message:280348":{"__typename":"TkbTopicMessage","subject":"DevCentral Top 5: Sep 8, 2014","conversation":{"__ref":"Conversation:conversation:280348"},"id":"message:280348","revisionNum":2,"uid":280348,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:56738"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":215},"postTime":"2014-09-08T19:22:00.000-07:00","lastPublishTime":"2023-09-26T14:46:25.167-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" But soft! What light through yonder window breaks? It is the east, and this week's edition of the DevCentral Top 5 is the sun. Yep, you guessed it. The top 5 is back...but unlike Shakespeare's Romeo and Juliet, this is no tragedy. Rather, it's a celebration of the most awesome articles you'll read anywhere on the Internet. Our DevCentral authors have been writing with freakish speed and determination, and they have turned out quality articles that are simply second to none. Choosing only five articles was a tough task given all the great content out there, but here's my take on the top articles since our last posting. \n \n F5 SOC Malware Summary Report: Neverquest \n I literally could have chosen five Lori MacVittie articles for this \"top 5\" but I resisted the urge and only chose one. In this article, Lori explains the details of a Trojan known as \"Neverquest\" that has been active since July 2013. Most of us get that warm, fuzzy, secure feeling when using 2-factor authentication because, you know, it's got 2 factors! Maybe automated malware has a shot at cracking one factor, but two? No way. Well, apparently Neverquest has found a way to automate the demise of our beloved 2FA. Lori does a magnificent job of explaining how Neverquest works, and then she discusses the amazing work that was completed by our F5 Security Operations Center in their analysis of this malware (in case you didn't know, F5 has a Security Operations Center that analyzes malware like this and provides amazing reports that are free for anyone to read). Lori provides links to the downloads of the executive summary as well as the full technical analysis of Neverquest. This one is not optional...if you care about anything at all, you gotta read this one. \n \n Leveraging BIG-IP APM for seamless client NTLM Authentication \n Michael Koyfman reminds us why we love the BIG-IP APM...transparent seamless authentication for users. In this article, Michael specifically discusses how to configure the APM to perform client NTLM authentication and use it in the context of sending a SAML assertion to the Office 365 service. This is a step-by-step masterpiece that shows you exactly what to do at every turn. In the end, you point your browser to the FQDN of the APM virtual server and you will be silently authenticated (let's be honest...silent authentication is a bucket-list item for each and every one of us). Michael also reminds us of the SSO options at the end of his article. \n \n Webshells \n Nir Zigler introduces us to Webshells (web scripts that act as a control panel for the server running them), and talks about some of the common uses for these scripts. But you know the story...scripts that were created for good can also be used for evil. After Nir explains all the valid uses for legitimate webshells, he takes us to a place where mere mortals dare not tread...through a webshell attack. He gives us an overview of how a webshell attack works, and then he explains some of the specific tools that are used for these nefarious actions. After walking through the power and functionality of an open source webshell called b374k, Nir shows how this tool can be used to attack an unsuspecting user. But have no fear! Nir finishes up the article by discussing the power of the BIG-IP ASM and how it will detect and prevent webshell attacks. \n \n Continuing the DDoS Arms Race \n How long have DDoS attacks been around, and why are they still news today? Because they are consistently one of the top attack vectors that companies face today. Shauntine'z discusses the DDoS arms race and provides some poignant statistics that remind us of the very real and credible DDoS threat. But the article doesn't stop there...it goes on to provide some excellent tips on what to do to strengthen your DDoS defense posture (it even has a well-placed picture of Professor John Frink...you gotta check this one out). Last, Shauntine'z reveals new features that are loaded in the latest release of the BIG-IP...version 11.6. The AFM and ASM have some new and exciting capabilities that are \"must haves\" for any company that is serious about securing their applications and critical business functions. \n \n (Editors note: the LineRate product has been discontinued for several years. 09/2023) \n Why ECC and PFS Matter: SSL offloading with LineRate We all know that sensitive data traverses our networks every day. We also know it's critically important to secure this information. We also know that SSL/TLS is the primary method used to secure said information. Andrew Ragone discusses SSL offloading and tells us why Elliptical Curve Cryptography (ECC) and Perfect Forward Secrecy (PFS) are great candidates for securing your information. He highlights the advantages of the software based LineRate solution, and gives great examples of why LineRate is the clear-cut winner over any existing software-based or hardware-based SSL/TLS offload solutions. Andrew also published another series of articles related to this very topic, and in these articles he walks you through the exact steps needed to configure SSL certificates and offload SSL on LineRate. On that subject...if you haven't had a chance to check out LineRate and learn all about the awesomeness that it is, do yourself a favor and visit \n ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"5556","kudosSumWeight":0,"repliesCount":0,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:292576":{"__typename":"Conversation","id":"conversation:292576","topic":{"__typename":"TkbTopicMessage","uid":292576},"lastPostingActivityTime":"2023-04-10T13:16:45.752-07:00","solved":false},"User:user:129415":{"__typename":"User","uid":129415,"login":"KevinGallaugher","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/images/dS0xMjk0MTUtNU4zOHUz?image-coordinates=0%2C0%2C360%2C360"},"id":"user:129415"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMjM0MTVpQUQwNUEwNDRFMzAxRjY0RQ?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMjM0MTVpQUQwNUEwNDRFMzAxRjY0RQ?revision=10","title":"DCCover-_0004_ali-zahdhan-WpU9j-_FeYk-unsplash.jpg","associationType":"COVER","width":500,"height":500,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMjA0MTJpQ0JCN0FGQjI5MzBFN0VDOQ?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMjA0MTJpQ0JCN0FGQjI5MzBFN0VDOQ?revision=10","title":"f5xclogo.png","associationType":"BODY","width":100,"height":103,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3MzlpOEY4OEYxNEZCOTVCNjE3MA?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3MzlpOEY4OEYxNEZCOTVCNjE3MA?revision=10","title":"Screen Shot 2022-02-14 at 1.26.03 PM.png","associationType":"BODY","width":792,"height":579,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3MzdpN0I2ODc5QUU1NThDRDJERQ?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3MzdpN0I2ODc5QUU1NThDRDJERQ?revision=10","title":"Screen Shot 2022-02-14 at 1.49.09 PM.png","associationType":"BODY","width":1145,"height":476,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDBpNUIyNkJFQ0U4N0FBNzBGMg?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDBpNUIyNkJFQ0U4N0FBNzBGMg?revision=10","title":"Screen Shot 2022-02-14 at 1.52.49 PM.png","associationType":"BODY","width":528,"height":739,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDFpQjU0MjI0RjRDNzkyNzM4Mw?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDFpQjU0MjI0RjRDNzkyNzM4Mw?revision=10","title":"Screen Shot 2022-02-14 at 2.07.21 PM.png","associationType":"BODY","width":1121,"height":82,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDJpNjgzQkJDN0IxMThCNkU5QQ?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDJpNjgzQkJDN0IxMThCNkU5QQ?revision=10","title":"Screen Shot 2022-02-14 at 2.09.39 PM.png","associationType":"BODY","width":579,"height":212,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDNpQUY3REM5QTNBRTUzQzczMQ?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDNpQUY3REM5QTNBRTUzQzczMQ?revision=10","title":"Screen Shot 2022-02-14 at 2.22.13 PM.png","associationType":"BODY","width":767,"height":519,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDRpNTFCNzQ3RkFBRTIwQzQ1RA?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDRpNTFCNzQ3RkFBRTIwQzQ1RA?revision=10","title":"Screen Shot 2022-02-14 at 2.24.38 PM.png","associationType":"BODY","width":1128,"height":366,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDVpNTg0RDNCQTdBNDA1QjM5MA?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDVpNTg0RDNCQTdBNDA1QjM5MA?revision=10","title":"Screen Shot 2022-02-14 at 2.58.19 PM.png","associationType":"BODY","width":566,"height":563,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDZpNTg0RjFGMkJDRjM5N0ZEQg?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDZpNTg0RjFGMkJDRjM5N0ZEQg?revision=10","title":"Screen Shot 2022-02-14 at 3.02.26 PM.png","associationType":"BODY","width":494,"height":462,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDhpQjEyOEQzNDM4QUU1MTJCRA?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDhpQjEyOEQzNDM4QUU1MTJCRA?revision=10","title":"Screen Shot 2022-02-14 at 3.19.36 PM.png","associationType":"BODY","width":408,"height":344,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDlpQkIxQUVFQjA4MjZBRjgxOQ?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDlpQkIxQUVFQjA4MjZBRjgxOQ?revision=10","title":"Screen Shot 2022-02-14 at 3.25.52 PM.png","associationType":"BODY","width":1404,"height":552,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTBpNzE4NDFEOTlCMzlCMjFFNA?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTBpNzE4NDFEOTlCMzlCMjFFNA?revision=10","title":"Screen Shot 2022-02-14 at 3.30.56 PM.png","associationType":"BODY","width":1133,"height":181,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTFpMzEyRDJEQzlBRThCQkNCNQ?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTFpMzEyRDJEQzlBRThCQkNCNQ?revision=10","title":"Screen Shot 2022-02-14 at 3.33.36 PM.png","associationType":"BODY","width":1090,"height":361,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTJpMDg4MjE0M0Q4NjY4NDBGQg?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTJpMDg4MjE0M0Q4NjY4NDBGQg?revision=10","title":"Screen Shot 2022-02-14 at 3.39.14 PM.png","associationType":"BODY","width":623,"height":275,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTNpOTgzODkyNkM4NUE2NzQ5Ng?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTNpOTgzODkyNkM4NUE2NzQ5Ng?revision=10","title":"Screen Shot 2022-02-14 at 3.40.42 PM.png","associationType":"BODY","width":677,"height":319,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTRpQkRFM0Y1MjczNzUxNzY0NQ?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTRpQkRFM0Y1MjczNzUxNzY0NQ?revision=10","title":"Screen Shot 2022-02-14 at 3.43.53 PM.png","associationType":"BODY","width":622,"height":292,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTVpOTEwMTVFMzA0NjUxNjYwRA?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTVpOTEwMTVFMzA0NjUxNjYwRA?revision=10","title":"Screen Shot 2022-02-14 at 3.47.15 PM.png","associationType":"BODY","width":1100,"height":231,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTZpNTc1MjdFNTY3MDREQjAxNA?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTZpNTc1MjdFNTY3MDREQjAxNA?revision=10","title":"Screen Shot 2022-02-14 at 3.48.34 PM.png","associationType":"BODY","width":1100,"height":358,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTdpREUwM0Y3NkE3RDlBN0YyQw?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTdpREUwM0Y3NkE3RDlBN0YyQw?revision=10","title":"Screen Shot 2022-02-14 at 3.50.00 PM.png","associationType":"BODY","width":1123,"height":373,"altText":null},"TkbTopicMessage:message:292576":{"__typename":"TkbTopicMessage","subject":"F5 Distributed Cloud L3-L7 DDoS Mitigation","conversation":{"__ref":"Conversation:conversation:292576"},"id":"message:292576","revisionNum":10,"uid":292576,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:129415"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":" In this article you will learn how simple it is to use F5 Distributed Cloud to protect your application from DDoS attacks. ","introduction":"","metrics":{"__typename":"MessageMetrics","views":9742},"postTime":"2022-03-01T09:00:00.021-08:00","lastPublishTime":"2023-04-10T13:16:45.752-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" \n Introduction \n In this article you will learn how simple it is to use F5 Distributed Cloud to protect your application from DDoS attacks. Some of the benefits of using F5 Distributed Cloud DDoS Mitigation are: \n \n Ensure application and network availability during DDoS attacks \n Block the malicious traffic while allowing the good, ensuring a good user experience for applications and services \n Identify and mitigate sophisticated Layer 7 DoS attacks that exploit application & infrastructure weaknesses \n Block the attack where it originates with a global backbone and distributed DoS mitigation technology \n Protect small facility and cloud-based applications and services with DNS-based redirection \n \n \n \"Nature is a mutable cloud, which is always and never the same.\" - Ralph Waldo Emerson \n We might not wax that philosophically around here, but our heads are in the cloud nonetheless! Join the F5 Distributed Cloud user group today and learn more with your peers and other F5 experts. \n \n Layer 3/4 DDoS Mitigation is enabled by default and requires no configuration. \n DDoS Mitigation is included with the F5 Distributed Cloud service. \n Configuring F5 Distributed Cloud DDoS Mitigation \n From the F5 Distributed Cloud Console select Load Balancers to begin. \n \n For this article let’s assume you have configured a very basic HTTP Load Balancer named “my-web-app”. On the right under Actions click the 3 dots and select Manage Configuration. \n \n \n \n \n \n The Basic Configuration shows the Domain name, “mydomain.com” in this example. The Load Balancer is configured as HTTPS with Automatic Certificate and an HTTP redirect to HTTPS. TLS security is set to High. \n \n \n Under Security Configuration you may need to scroll down and toggle the Show Advanced Fields button to On to view the DDoS configuration. \n \n \n Scroll down to ML Config and select Single Load Balancer Application. \n \n \n Disable API Discovery. \n \n \n Scroll to the bottom and click Save and Exit. \n \n \n The application is now protected from Layer 7 DDoS attacks. \n How to know when a DDoS attack occurs? \n Security Events will be generated when a DDoS attack occurs. This can be viewed from the Security Monitoring Dashboard. \n \n \n Select the DDoS Dashboard to view a geographical map that shows the location off the affected application. \n \n Expand the DDoS Events for more detail. Under Metric we can see that Error Rate and Request Rate were triggered. Make a note of the Suspicious Users IP address so it can be blocked. \n \n How to mitigate attacks? \n Go back to Manage > Load Balancers. Click the 3 dots under Actions and select Manage Configuration. \n \n \n Click Edit Configuration on the top right. \n \n \n Scroll down under Security Configuration. Find the DDoS Mitigation Rules and click Configure. \n \n Click Add item. \n \n Give it a name, “block-by-ip” in this example. \n \n Under Mitigation Choice > IP Source enter the IP prefixes you want to block. \n \n Note: IP address 1.2.3.4 is only being used as an example. 1.2.3.0/24 notations can be used to block entire subnets. \n Click Add item at the bottom. \n \n Then click Apply. \n \n Scroll to the bottom and click Save and Exit. \n \n The attacking client has been blocked and will no longer trigger DDoS Events. \n Conclusion \n In this article you learned how to enable and configure L7 DDoS Mitigation with the F5 Distributed Cloud. We also went over the monitoring of Security Events and what to do if a DDoS attack is detected. \n For further information or to get started: \n \n F5 Distributed Cloud WAAP YouTube series (Link) \n F5 Distributed Cloud WAAP Services (Link) \n F5 Distributed Cloud WAAP Get Started (Link) \n \n Tag: F5 XC DDoS Mitigation \n ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"3844","kudosSumWeight":4,"repliesCount":0,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMjM0MTVpQUQwNUEwNDRFMzAxRjY0RQ?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMjA0MTJpQ0JCN0FGQjI5MzBFN0VDOQ?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3MzlpOEY4OEYxNEZCOTVCNjE3MA?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3MzdpN0I2ODc5QUU1NThDRDJERQ?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDU","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDBpNUIyNkJFQ0U4N0FBNzBGMg?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDY","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDFpQjU0MjI0RjRDNzkyNzM4Mw?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDc","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDJpNjgzQkJDN0IxMThCNkU5QQ?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDg","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDNpQUY3REM5QTNBRTUzQzczMQ?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDk","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDRpNTFCNzQ3RkFBRTIwQzQ1RA?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEw","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDVpNTg0RDNCQTdBNDA1QjM5MA?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEx","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDZpNTg0RjFGMkJDRjM5N0ZEQg?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEy","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDhpQjEyOEQzNDM4QUU1MTJCRA?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEz","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NDlpQkIxQUVFQjA4MjZBRjgxOQ?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE0","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTBpNzE4NDFEOTlCMzlCMjFFNA?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE1","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTFpMzEyRDJEQzlBRThCQkNCNQ?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE2","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTJpMDg4MjE0M0Q4NjY4NDBGQg?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE3","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTNpOTgzODkyNkM4NUE2NzQ5Ng?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE4","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTRpQkRFM0Y1MjczNzUxNzY0NQ?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE5","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTVpOTEwMTVFMzA0NjUxNjYwRA?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDIw","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTZpNTc1MjdFNTY3MDREQjAxNA?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDIx","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTI1NzYtMTY3NTdpREUwM0Y3NkE3RDlBN0YyQw?revision=10\"}"}}],"totalCount":21,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:296626":{"__typename":"Conversation","id":"conversation:296626","topic":{"__typename":"TkbTopicMessage","uid":296626},"lastPostingActivityTime":"2023-02-06T12:09:22.283-08:00","solved":false},"User:user:275378":{"__typename":"User","uid":275378,"login":"Ted_Byerly","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/m_assets/avatars/default/avatar-10.svg?time=0"},"id":"user:275378"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTgyNTBpQjQ2MDMxRTI4NjgyNzQ3Qw?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTgyNTBpQjQ2MDMxRTI4NjgyNzQ3Qw?revision=10","title":"CoverPhoto_0021_shubham-dhage-T9rKvI3N0NM-unsplash.jpg","associationType":"COVER","width":1000,"height":1000,"altText":""},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MjRpMUQ4RkJEREUxMzNDQzRDNg?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MjRpMUQ4RkJEREUxMzNDQzRDNg?revision=10","title":"ddos_fast_login.png","associationType":"BODY","width":1380,"height":1017,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MjVpNkY0Q0VEMTJCOUMxQUYzRg?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MjVpNkY0Q0VEMTJCOUMxQUYzRg?revision=10","title":"ddos_fast_Cloud_edge.png","associationType":"BODY","width":1049,"height":902,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MjZpMkI1OTI2MkIzOEY5MzIwOA?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MjZpMkI1OTI2MkIzOEY5MzIwOA?revision=10","title":"ddos_fast_initial.png","associationType":"BODY","width":1376,"height":942,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MjhpNzc5Q0IzNENFRjU0QUQ1OQ?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MjhpNzc5Q0IzNENFRjU0QUQ1OQ?revision=10","title":"ddos_fast_add_fast.png","associationType":"BODY","width":1372,"height":888,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MjlpREFBQkQ4MzMxQzk0NjU3NA?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MjlpREFBQkQ4MzMxQzk0NjU3NA?revision=10","title":"ddos_fast_acl_configure.png","associationType":"BODY","width":1123,"height":797,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzBpMERDOUE4QUNCMjNBRjA1Nw?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzBpMERDOUE4QUNCMjNBRjA1Nw?revision=10","title":"ddos_fast_ce_destination.png","associationType":"BODY","width":1135,"height":618,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzJpNjkyRDAzM0M3RDJCMDMzMg?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzJpNjkyRDAzM0M3RDJCMDMzMg?revision=10","title":"ddos_fast_rules_add.png","associationType":"BODY","width":1129,"height":369,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzNpQTFBNzJBMzE0NjM1QTJDNA?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzNpQTFBNzJBMzE0NjM1QTJDNA?revision=10","title":"ddos_fast_rules.png","associationType":"BODY","width":1105,"height":950,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzRpQzZGQUMyNUEwRENBQzhBQQ?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzRpQzZGQUMyNUEwRENBQzhBQQ?revision=10","title":"ddos_fast_port.png","associationType":"BODY","width":1114,"height":343,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzVpQzkyREUwMzMyNDg2MEUzOA?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzVpQzkyREUwMzMyNDg2MEUzOA?revision=10","title":"Screen Shot 2022-06-08 at 12.26.27 PM.png","associationType":"BODY","width":1137,"height":425,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzdpRENGNDk0MDgxN0UxODgyRA?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzdpRENGNDk0MDgxN0UxODgyRA?revision=10","title":"Screen Shot 2022-06-08 at 1.03.00 PM.png","associationType":"BODY","width":1135,"height":962,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzhpOUE4MDZCRDZFMkIzOTk3Qw?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzhpOUE4MDZCRDZFMkIzOTk3Qw?revision=10","title":"ddos_fast_protocol_policer.png","associationType":"BODY","width":1132,"height":599,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzlpMzAxRUQyOTE5RURDNkNEMQ?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzlpMzAxRUQyOTE5RURDNkNEMQ?revision=10","title":"ddos_fast_protocol_type.png","associationType":"BODY","width":1132,"height":552,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5NDFpMDlFODBDRDhCRjE0NTU4Mg?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5NDFpMDlFODBDRDhCRjE0NTU4Mg?revision=10","title":"Screen Shot 2022-06-08 at 1.07.16 PM.png","associationType":"BODY","width":1138,"height":695,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5NDJpMUEwMUVDNzI1MDBERTUxOQ?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5NDJpMUEwMUVDNzI1MDBERTUxOQ?revision=10","title":"ddos_fast_policer.png","associationType":"BODY","width":1135,"height":987,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMjA0MTJpQ0JCN0FGQjI5MzBFN0VDOQ?revision=10\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMjA0MTJpQ0JCN0FGQjI5MzBFN0VDOQ?revision=10","title":"f5xclogo.png","associationType":"BODY","width":100,"height":103,"altText":null},"TkbTopicMessage:message:296626":{"__typename":"TkbTopicMessage","subject":"Protect your applications using F5’s Distributed Cloud and Fast ACL’s","conversation":{"__ref":"Conversation:conversation:296626"},"id":"message:296626","revisionNum":10,"uid":296626,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:275378"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":4040},"postTime":"2022-06-27T05:00:00.025-07:00","lastPublishTime":"2023-02-06T12:09:22.283-08:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Introduction \n In this article I will show you how to easily create Fast ACL’s to protect your applications from DDoS attacks. Layer 3-4 DDoS Mitigation is included with the F5 Distributed Cloud service. \n When planning your DDoS strategy, you must plan at many layers. This means organizations need multiple tools and capabilities to protect themselves and keep their infrastructure and applications running. This layered approach uses network firewalls for Layer 3-4 DDoS protection, Web Application Firewalls (WAF) for Layer 7 protections, and as I’ll cover here Access Control Lists (ACLs) or as we call them Fast ACLs that can include rate-limiting. \n These ACL rules are applied at very early stages in datapath ingress processing and form a first line of defense against attack. \n Typical Use case(s) are: \n \n Rate-limiting traffic to destination \n Accepting traffic from certain source IPs to destination \n Rate-limiting or dropping traffic from source IPs to destination \n \n These rules are evaluated for each packet coming into the system (ingress), unlike session-based ACL’s where action is calculated only on first packet in the session. \n It is specified in terms of five tuple of the packet {destination ip, destination port, source ip, source port, protocol}. \n This gives you the ability to fine tune your DDoS strategy based on your network infrastructure and application performance. \n Getting Started \n Log in to your F5 Distributed Cloud Service. \n \n \n Select the Cloud and Edge Sites Tile. \n \n Navigate to Manage >> Firewall >> Fast ACL’s. \n \n We will also be discussing and using Policers and Protocol Policers. They can be added from this screen or as we build out our DDoS protection. We will show how during the build out. \n Click Add Fast ACL \n \n Give your Fast ACL a Name, add a Label and Description to help identify later. \n \n Next is what sets F5 XC Services apart. \n Under Fast ACL Type you have 2 options. \n This can be at the F5 XC Services regional edge (RE) or your own customer edge (CE) for apps deployed locally with F5 Distributed Cloud Service nodes. For this article I will cover the Customer Edge (CE). \n Select Configure. \n \n Here you have the option to select which network to apply this to at the CE, Inside or Outside, I will use the Outside Network. Next select the Destination IP, where you have three options to protect. I will use All Interface IP(s) as VIP. \n Finally, under Source, we will configure the Rules we wish to apply. Click Configure \n \n Under the Rules Section. Click Add Item \n \n Give your Rule a Name and a Description. \n Under Action you have 3 options, Simple Action, Policer Action and Protocol Policer Action. \n First, we will cover the Simple Action. You have two options, allow or deny. \n Under Source Port, click Add Item. \n \n You have the option to select All Ports, A User Defined Port or DNS. \n I will select User defined and add the value of 443. \n \n Under Source I'll allow all from 0.0.0.0./0 and click Add Item. \n Now you can go back in Rules and any additional rules that reflect your architecture. Click Add Item. \n This time I'll select Deny as the Action and ALL as Source Ports and Source Prefix as 0.0.0.0/0 \n When complete click Apply, this takes you back a Screen, Click Apply again. \n Protocol Policer \n Finally, we will configure a FAST ACL Protocol Policer. \n \n Give your Protocol Policer a Name, Labels and Description. \n Select a pre-configured Protocol Policer if one is already configured or you have system wide one you wish to apply. For this demonstration we will click Create new Protocol Policer. \n \n Click Add Item \n This will give you the option of Packet Type. The options are TCP, ICMP, UDP and DNS. For this we will select TCP. \n \n Then you select the appropriate TCP Flags, we will select SYN. \n Policer \n Dropping to the Policer section, we either need to select a preconfigured policer that might be used system wide or Create a new one. We will select Create New Policer. \n \n Creating a Policer is straightforward. Give it a Name, Labels and Description. Select If the Policer is to be Shared or Not Shared System wide. \n \n Here is where creating Fast ACLs helps you fine tune your DDoS protection for your application. \n You will enter both a Committed Information Rate in pps and a Burst Size in pps. \n Click Continue \n Add item and then Continue. \n Finally Save and Exit. \n These are all the steps necessary to get started using Fast ACL's. \n Two additional steps are needed and beyond the scope of this article. Most builds will already have the necessary configurations required. \n You need to have a Network Firewall designated and what F5 Distributed Cloud calls a Fleet. The Firewall will reference the ACL and the Firewall and Fleet Tag will be asisgned to your Customer Edge (CE). \n Conclusion \n In this article you learned how to configure Fast ACLs DDoS protection quickly and easily with the F5's Distributed Cloud. We included Rate Limiting as a viable option to tune your DDoS settings. In a few short minutes you would be able to react to an attack on your network by going into the F5 Distributed Cloud Console and adjusting or adding DDoS protections. \n \n \"Nature is a mutable cloud, which is always and never the same.\" - Ralph Waldo Emerson \n We might not wax that philosophically around here, but our heads are in the cloud nonetheless! Join the F5 Distributed Cloud user group today and learn more with your peers and other F5 experts. \n \n For further information or to get started: \n F5 Distributed Cloud WAAP YouTube series (Link) \n F5 Distributed Cloud WAAP Services (Link) \n F5 Distributed Cloud WAAP Get Started (Link) \n \n ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"5874","kudosSumWeight":3,"repliesCount":0,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTgyNTBpQjQ2MDMxRTI4NjgyNzQ3Qw?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MjRpMUQ4RkJEREUxMzNDQzRDNg?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MjVpNkY0Q0VEMTJCOUMxQUYzRg?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MjZpMkI1OTI2MkIzOEY5MzIwOA?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDU","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MjhpNzc5Q0IzNENFRjU0QUQ1OQ?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDY","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MjlpREFBQkQ4MzMxQzk0NjU3NA?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDc","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzBpMERDOUE4QUNCMjNBRjA1Nw?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDg","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzJpNjkyRDAzM0M3RDJCMDMzMg?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDk","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzNpQTFBNzJBMzE0NjM1QTJDNA?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEw","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzRpQzZGQUMyNUEwRENBQzhBQQ?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEx","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzVpQzkyREUwMzMyNDg2MEUzOA?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEy","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzdpRENGNDk0MDgxN0UxODgyRA?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEz","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzhpOUE4MDZCRDZFMkIzOTk3Qw?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE0","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5MzlpMzAxRUQyOTE5RURDNkNEMQ?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE1","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5NDFpMDlFODBDRDhCRjE0NTU4Mg?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE2","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMTc5NDJpMUEwMUVDNzI1MDBERTUxOQ?revision=10\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE3","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yOTY2MjYtMjA0MTJpQ0JCN0FGQjI5MzBFN0VDOQ?revision=10\"}"}}],"totalCount":17,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:286884":{"__typename":"Conversation","id":"conversation:286884","topic":{"__typename":"TkbTopicMessage","uid":286884},"lastPostingActivityTime":"2023-01-26T06:45:46.056-08:00","solved":false},"User:user:406351":{"__typename":"User","uid":406351,"login":"Sven_Mueller","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/m_assets/avatars/default/avatar-9.svg?time=0"},"id":"user:406351"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTA3MjZpRkUwNDc0REMzOTE2QzBGOQ?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTA3MjZpRkUwNDc0REMzOTE2QzBGOQ?revision=1","title":"0151T000003lbrkQAA.png","associationType":"BODY","width":270,"height":131,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtNTc1MGkxMjNEQjMxQzY1MkIxMDRB?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtNTc1MGkxMjNEQjMxQzY1MkIxMDRB?revision=1","title":"0151T000003lbrpQAA.png","associationType":"BODY","width":545,"height":347,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTMxM2kzQUZCQTlFQjJEMjRCM0ZD?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTMxM2kzQUZCQTlFQjJEMjRCM0ZD?revision=1","title":"0151T000003lbruQAA.png","associationType":"BODY","width":602,"height":383,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTIyNzBpRjAyOUExQ0RDNDI2OTM1NQ?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTIyNzBpRjAyOUExQ0RDNDI2OTM1NQ?revision=1","title":"0151T000003lbrzQAA.png","associationType":"BODY","width":714,"height":458,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTI1NjZpRDE2QTNEMjZDREQ3QkU0Qw?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTI1NjZpRDE2QTNEMjZDREQ3QkU0Qw?revision=1","title":"0151T000003lbs4QAA.png","associationType":"BODY","width":747,"height":479,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTQwODdpOTY1MkNEMTY4NTJDQkJDQg?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTQwODdpOTY1MkNEMTY4NTJDQkJDQg?revision=1","title":"0151T000003lbsxQAA.png","associationType":"BODY","width":943,"height":568,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTE2NjZpODZDMDE2NEQ2Rjk2MDAwMw?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTE2NjZpODZDMDE2NEQ2Rjk2MDAwMw?revision=1","title":"0151T000003lbtRQAQ.png","associationType":"BODY","width":275,"height":277,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtNDY4OGlFNUU2RUZCMzRGRTUxNUFD?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtNDY4OGlFNUU2RUZCMzRGRTUxNUFD?revision=1","title":"0151T000003lbtWQAQ.png","associationType":"BODY","width":254,"height":256,"altText":null},"TkbTopicMessage:message:286884":{"__typename":"TkbTopicMessage","subject":"Explanation of F5 DDoS threshold modes","conversation":{"__ref":"Conversation:conversation:286884"},"id":"message:286884","revisionNum":1,"uid":286884,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:406351"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":10595},"postTime":"2020-02-12T14:26:51.000-08:00","lastPublishTime":"2020-02-12T14:26:51.000-08:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Der Reader, In my article “Concept of Device DOS and DOS profile”, I recommended to use the “Fully Automatic” or “Multiplier” based configuration option for some DOS vectors. In this article I would like to explain how these threshold modes work and what is happening behind the scene. When you configure a DOS vector you have the option to choose between different threshold modes: “Fully Automatic”, “Auto Detection / Multiplier Based”, “Manual Detection / Auto Mitigation” and “Fully Manual”. Figure 1: Threshold Modes The two options I normally use on many vectors are “Fully Automatic” and “Auto Detection / Multiplier Based”. But what are these two options do for me? To manually set thresholds is for some vectors not an easy task. I mean who really knows how many PUSH/ACK packets/sec for example are usually hitting the device or a specific service? And when I have an idea about a value, should this be a static value? Or should I better take the maximum value I have seen so far? And how many packets per second should I put on top to make sure the system is not kicking in too early? When should I adjust it? Do I have increasing traffic? Fully Automatic In reality, the rate changes constantly and most likely during the day I will have more PUSH/ACK packets/sec then during the night. What happens when there is a campaign or an event like “Black Friday” and way more users are visiting the webpage then usually? During these high traffic events, my suggested thresholds might be no longer correct which could lead to “good” traffic getting dropped. All this should be taken into consideration when setting a threshold and it ends up being very difficult to do manually. It´s better to make the machine doing it for you and this is what “Fully Automatic” is about. Figure 2: Expected EPS As soon as you use this option, it leverages from the learning it has done since traffic is passing through the BIG-IP, or since you have enforced the relearning, which resets everything learned so far and starts from new. The system continuously calculates the expected rates for all the vectors based on the historic rates of traffic. It takes the information up to one year and calculates them with different weights in order to know which packets rate should be expected at that time and day for that specific vector in the specific context (Device, Virtual Server/Protected Object). The system then calculates a padding on top of this expected rate. This rate is called Detection Rate and is dependent on the “threshold sensitivity” you have configured: Low Sensitivity means 66% padding Medium Sensitivity means 40% padding High Sensitivity means 0% padding Figure 3: Detection EPS As soon as the current rate is above the detection value, the BIG-IP will show the message “Attack detected”, which actually means anomaly detected, because it sees more packets of that specific vector then expected + the padding (detection_rate). But DoS mitigation will not start at that point! Figure 4: Current EPS Keep in mind, when you run the BIG-IP in stateful mode it will drop 'out of state' packets anyway. This has nothing to do with DoS functionalities. But what happens when there is a serious flood and the BIG-IP CPU gets high because of the massive number of packets it has to deal with? This is when the second part of the “Fully Automatic” approach comes into the game. Again, depending on your threshold sensitivity the DOS mitigation starts as soon as a certain level of stress is detected on the CPU of the BIG-IP. Figure 5: Mitigation Threshold Low Sensitivity means 78,3% TMM load Medium Sensitivity means 68,3% TMM load High Sensitivity means 51,6% TMM load Note, that the mitigation is per TMM and therefore the stress and rate per TMM is relevant. When the traffic rate for that vector is above the detection rate and the CPU of the BIG-IP (Device DOS) is “too” busy, the mitigation kicks in and will rate limit on that specific vector. When a DOS vector is hardware supported, FPGAs drop the packets at the switch level of the BIG-IP. If that DOS vector is not hardware supported, then the packet is dropped at a very early stage of the life cycle of a packet inside a BIG-IP. The rate at which are packets dropped is dynamic (mitigation rate), depending on the incoming number of packets for that vector and the CPU (TMM) stress of the BIG-IP. This allows the stress of the CPU to go down as it has to deal with less packets. Once the incoming rate is again below the detection rate, the system declares the attack as ended. Note: When an attack is detected, the packet rate during that time will not go into the calculation of expected rates for the future. This ensures that the BIG-IP will not learn from attack traffic skewing the automatic thresholds. All traffic rates below the detection (or below the floor value, when configured) rate modify the expected rate for the future and the BIG-IP will adjust the detection rate automatically. For most of the vectors you can configure a floor and ceiling value. Floor means that as long as the traffic value is below that threshold, the mitigation for that vector will never kick in. Even when the CPU is at 100%. Ceiling means that mitigation always kicks in at that rate, even when the CPU is idle. With these two values the dynamic and automatic process is done between floor and ceiling. Mitigation only gets executed when the rate is above the rate of the Floor EPS and Detection EPS AND stress on the particular context is measured. Figure 6: Floor and Ceiling EPS What is the difference when you use “Fully Automatic” on Device level compared to VS/PO (DOS profile) level? Everything is the same, except that on VS or Protected Object (PO) level the relevant stress is NOT the BIG-IP device stress, it is the stress of the service you are protecting (web-, DNS, IMAP-server, network, ...). BIG-IP can measure the stress of the service by measuring TCP attributes like retransmission, window size, congestion, etc. This gives a good indication on how busy a service is. This works very well for request/response protocols like TCP, HTTP, DNS. I recommend using this, when the Protected Object is a single service and not a “wildcard” Protected Object covering for example a network or service range. When the Protected Object is a “wildcard” service and/or a UDP service (except DNS), I recommend using “Auto Detection / Multiplier Option”. It works in the same way as the “Fully Automatic” from the learning perspective, but the mitigation condition is not stress, it is the multiplication of the detection rate. For example, the detection rate for a specific vector is calculated to be 100k packets/sec. By default, the multiplication rate is “500”, which means 5x. Therefore, the mitigation rate is calculated to 500k packets/sec. If that particular vector has more than 500k packets/sec those packets would be dropped. The multiplication rate can also be individually configured. Like in the screenshot, where it is set to 8x (800). Figure 7: Auto Detection / Multiplier Based Mitigation The benefit of this mode is that the BIG-IP will automatically learn the baseline for that vector and will only start to mitigate based on a large spike. The mitigation rate is always a multiplication of the detection rate, which is 5x by default but is configurable. When should I use “Fully Manual”? When you want to rate-limit a specific vector to a certain number of packets/sec, then “Fully Manual” is the right choice. Very good examples for that type of vector are the “Bad Header” vector types. These type of packets will never get forwarded by the BIG-IP so dropping them by a DoS vector saves the CPU, which is beneficial under DoS conditions. In the screenshot below is a vector configured as “Fully Manual”. Next I’ll describe what each of the options means. Figure 8: Fully Manual Detection Threshold EPS configures the packet rate/sec (pps) when you will get a log messages (NO mitigation!). Detection Threshold % compares the current pps rate for that vector with the multiplication of the configured percentage (in this example 5 for 500%) with the 1-minute average rate. If the current rate is higher, then you will get a log message. Mitigation Threshold EPS rate limits to that configured value (mitigation). I recommend setting the threshold (Mitigation Threshold EPS) to something relatively low like ‘10’ or ‘100’ on ‘Bad Header’ type of vectors. You can also set it also to ‘0’, which means all packets hitting this vector will get dropped by the DoS function which usually is done in hardware (FPGA). With the ‘Detection Threshold EPS’ you set the rate at which you want to get a log messages for that vector. If you do it this way, then you get a warning message like this one to inform you about the logging behavior: Warning generated: DOS attack data (bad-tcp-flags-all-set): Since drop limit is less than detection limit, packets dropped below the detection limit rate will not be logged. Another use-case for “Fully Manual” is when you know the maximum number of these packets the service can handle. But here my recommendation is to still use “Fully Automatic” and set the maximum rate with the Ceiling threshold, because then the protected service will benefit from both threshold options. Important: Please keep in mind, when you set manual thresholds for Device DoS the thresholds are to protect each TMM. Therefore the value you set is per TMM! An exception to this is the Sweep and Flood vector where the threshold is per BIG-IP/service and not per TMM like on DoS profiles. When using manual thresholds for a DOS profile of a Protected Object the threshold configuration is per service (all packets targeted to the protected service) NOT per TMM like on the Device level. Here the goal is to set how many packets are allowed to pass the BIG-IP and reach the service. The distribution of these thresholds to the TMMs is done in a dynamic way: Every TMM gets a percentage of the configured threshold, based on the EPS (Events Per Second, which is in this context Packets Per Second) for the specific vector the system has seen in the second before on this TMM. This mechanism protects against hash type of attacks. Ok, I hope this article gives you a better understanding on how ‘Fully Manual’, ‘Fully Automatic’ and ‘Auto Detection / Multiplier Based Mitigation’ works. They are important concepts to understand, especially when they work in conjunction with stress measurement. This means the BIG-IP will only kick in with the DoS mitigation when the protected object (BIG-IP or the service behind the BIG-IP) is under stress. -Why risk false positives, when not necessary? With my next article I will demonstrate you how Device DoS and the DoS profiles work together and how the stateful concept cooperates with the DoS mitigation. I will show you some DoS commands to test it and also commands to get details from the BIG-IP via CLI. Thank you, sVen Mueller ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"11181","kudosSumWeight":21,"repliesCount":10,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTA3MjZpRkUwNDc0REMzOTE2QzBGOQ?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtNTc1MGkxMjNEQjMxQzY1MkIxMDRB?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTMxM2kzQUZCQTlFQjJEMjRCM0ZD?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTIyNzBpRjAyOUExQ0RDNDI2OTM1NQ?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDU","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTI1NjZpRDE2QTNEMjZDREQ3QkU0Qw?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDY","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTQwODdpOTY1MkNEMTY4NTJDQkJDQg?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDc","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtMTE2NjZpODZDMDE2NEQ2Rjk2MDAwMw?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDg","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4ODQtNDY4OGlFNUU2RUZCMzRGRTUxNUFD?revision=1\"}"}}],"totalCount":8,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:286851":{"__typename":"Conversation","id":"conversation:286851","topic":{"__typename":"TkbTopicMessage","uid":286851},"lastPostingActivityTime":"2023-01-26T04:42:17.478-08:00","solved":false},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTUwMDVpMTU3QTZGNTE0MDU4QkFBNA?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTUwMDVpMTU3QTZGNTE0MDU4QkFBNA?revision=1","title":"0151T000003ljjAQAQ.png","associationType":"BODY","width":606,"height":368,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtOTA2M2lDODUzMEQzMzJERTc0QzlD?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtOTA2M2lDODUzMEQzMzJERTc0QzlD?revision=1","title":"0151T000003ljjKQAQ.png","associationType":"BODY","width":939,"height":224,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtODAxMGk2OTNCMzcyQkJDMzEwRDc3?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtODAxMGk2OTNCMzcyQkJDMzEwRDc3?revision=1","title":"0151T000003ljjPQAQ.png","associationType":"BODY","width":939,"height":210,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtOTE0NWk4OUQ3NTEzREExMUI5Mjk2?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtOTE0NWk4OUQ3NTEzREExMUI5Mjk2?revision=1","title":"0151T000003ljjZQAQ.png","associationType":"BODY","width":195,"height":204,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTUyNzBpRTRGQzE2NUJFRENDMTU3QQ?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTUyNzBpRTRGQzE2NUJFRENDMTU3QQ?revision=1","title":"0151T000003ljjeQAA.png","associationType":"BODY","width":939,"height":272,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTIxMzBpNkUwMUU4RTIwQjZCNjc5MA?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTIxMzBpNkUwMUU4RTIwQjZCNjc5MA?revision=1","title":"0151T000003ljjjQAA.png","associationType":"BODY","width":210,"height":343,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTE2OGkyMzI1OUJFMzVCMTZGQUE2?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTE2OGkyMzI1OUJFMzVCMTZGQUE2?revision=1","title":"0151T000003ljjoQAA.png","associationType":"BODY","width":939,"height":172,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMzg3Nmk0REYwNUUyQzBERkNEOTAy?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMzg3Nmk0REYwNUUyQzBERkNEOTAy?revision=1","title":"0151T000003lkFqQAI.png","associationType":"BODY","width":249,"height":356,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtNTc4MGlBQ0QwMTRDNjZBRkM5MDBC?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtNTc4MGlBQ0QwMTRDNjZBRkM5MDBC?revision=1","title":"0151T000003ljjtQAA.png","associationType":"BODY","width":939,"height":172,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTI5MzFpNTYwREREOUVDMTBBODY4QQ?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTI5MzFpNTYwREREOUVDMTBBODY4QQ?revision=1","title":"0151T000003ljjkQAA.png","associationType":"BODY","width":939,"height":395,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTMxMzhpNzNFRDNBNUQ4RTNEMDRGMw?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTMxMzhpNzNFRDNBNUQ4RTNEMDRGMw?revision=1","title":"0151T000003ljk3QAA.png","associationType":"BODY","width":939,"height":160,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTA4MjRpNzI1NUQyNTc1MTBFNEU3Rg?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTA4MjRpNzI1NUQyNTc1MTBFNEU3Rg?revision=1","title":"0151T000003llNLQAY.png","associationType":"BODY","width":270,"height":366,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtNjc1M2lGOEFEMDlFNUM0MDE1OTcw?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtNjc1M2lGOEFEMDlFNUM0MDE1OTcw?revision=1","title":"0151T000003ljkDQAQ.png","associationType":"BODY","width":270,"height":418,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTczMGk3RjYyRTkxQ0YwRDQ5OEE3?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTczMGk3RjYyRTkxQ0YwRDQ5OEE3?revision=1","title":"0151T000003ljkIQAQ.png","associationType":"BODY","width":939,"height":160,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMzIxNmk1MUU3QThGRUUxRjUxNjEz?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMzIxNmk1MUU3QThGRUUxRjUxNjEz?revision=1","title":"0151T000003ljkNQAQ.png","associationType":"BODY","width":939,"height":164,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTYwMjRpNDE1NUFFOUMzNUMxNjRBOA?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTYwMjRpNDE1NUFFOUMzNUMxNjRBOA?revision=1","title":"0151T000003llNQQAY.png","associationType":"BODY","width":245,"height":382,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtOTkyaTQyOEIzM0Y2OEY3RkI4REM?revision=1\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtOTkyaTQyOEIzM0Y2OEY3RkI4REM?revision=1","title":"0151T000003llNVQAY.png","associationType":"BODY","width":2126,"height":536,"altText":null},"TkbTopicMessage:message:286851":{"__typename":"TkbTopicMessage","subject":"Demonstration of Device DoS and Per-Service DoS protection","conversation":{"__ref":"Conversation:conversation:286851"},"id":"message:286851","revisionNum":1,"uid":286851,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:406351"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":3902},"postTime":"2020-04-08T12:31:46.000-07:00","lastPublishTime":"2020-04-08T12:31:46.000-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Dear Reader, This article is intended to show what effect the different threshold modes have on the Device and Per-Service (VS/PO) context. I will be using practical examples to demonstrate those effects. You will get to review a couple of scripts which will help you to do DoS flood tests and “visualizing” results on the CLI. In my first article (https://devcentral.f5.com/s/articles/Concept-of-F5-Device-DoS-and-DoS-profiles), I talked about the concept of F5 Device DoS and Per-Service DoS protection (DoS profiles). I also covered the physical and logical data path, which explains the order of Device DoS and Per-Service DoS using the DoS profiles. In the second article (https://devcentral.f5.com/s/articles/Explanation-of-F5-DDoS-threshold-modes), I explained how the different threshold modes are working. In this third article, I would like to show you what it means when the different modes work together. But, before I start doing some tests to show the behavior, I would like to give you a quick introduction into the toolset I´m using for these tests. Toolset First of all, how to do some floods? Different tools that can be found on the Internet are available for use. Whatever tools you might prefer, just download the tool and run it against your Device Under Test (DUT). If you would like to use my script you can get it from GitHub: https://github.com/sv3n-mu3ll3r/DDoS-Scripts With this script - it uses hping - you can run different type of attacks. Simply start it with: $ ./attack_menu.sh <IP> <PORT> A menu of different attacks will be presented which you can launch against the used IP and port as a parameter. Figure 1: Attack Menu To see what L3/4 DoS events are currently ongoing on your BIG-IP, simply go to the DoS Overview page. Figure 2: DoS Overview page I personally prefer to use the CLI to get the details I´m interested in. This way I don´t need to switch between CLI to launch my attacks and GUI to see the results. For that reason, I created a script which shows me what I am most interested in. Figure 3: DoS stats via CLI You can download that script here: https://github.com/sv3n-mu3ll3r/F5_show_DoS_stats_scripts Simply run it with the “watch” command and the parameter “-c” to get a colored output (-c is only available starting with TMOS version 14.0): What is this script showing you? context_name:\tThis is the context, either PO/VS or the Device in which the vector is running vector_name:\t\tThis is the name of the DoS vector attack_detected: When it shows “1”, then an attack has been detected, which means the ‘stats_rate’ is above the ‘detection-rate'. stats_rate:\t\t\tShows you the current incoming pps rate for that vector in this context drops_rate:\t\tShows you the number dropped pps rate in software (not FPGA) for that vector in this context int_drops_rate:\tShows you the number dropped pps rate in hardware (FPGA) for that vector in this context ba_stats_rate:\tShows you the pps rate for bad actors ba_drops_rate:\tShows you the pps rate of dropped ‘bad actors’ in HW and SW bd_stats_rate: Shows you the pps rate for attacked destination bd_drop_rate:\tShows you the pps rate for dropped ‘attacked destination’ mitigation_curr:\tShows the current mitigation rate (per tmm) for that vector in that context detection:\t\t\tShows you the current detection rate (per tmm) for that vector in that context wl_count:\t\t\tShows you the number of whitelist hits for that vector in that context hw_offload:\t\tWhen it shows ‘1’ it means that FPGAs are involved in the mitigation int_dropped_bytes_rate:\tGives you the rate of in HW dropped bytes for that vector in that context dropped_bytes_rate: \t\tGives you the rate of in SW dropped bytes for that vector in that context When a line is displayed in green, it means packets hitting that vector. However, no anomaly is detected or anything is mitigated (dropped) via DoS. If a line turns yellow, then an attack - anomaly – has been detected but no packets are dropped via DoS functionalities. When the color turns red, then the system is actually mitigating and dropping packets via DoS functionalities on that vector in that context. Start Testing Before we start doing some tests, let me provide you with a quick overview of my own lab setup. I´m using a DHD (DDoS Hybrid Defender) running on a i5800 box with TMOS version 15.1 My traffic generator sends around 5-6 Gbps legitimate (HTTP and DNS) traffic through the box which is connected in L2 mode (v-wire) to my network. On the “client” side, where my clean traffic generator is located, my attacking clients are located as well by use of my DoS script. On the “server” side, I run a web service and DNS service, which I´m going to attack. Ok, now let’s do some test so see the behavior of the box and double check that we really understand the DDoS mitigation concept of BIG-IP. Y-MAS flood against a protected server Let’s start with a simple Y-MAS (all TCP flags cleared) flood. You can only configure this vector on the device context and only in manual mode. Which is ok, because this TCP packet is not valid and would get drop by the operating system (TMOS) anyway. But, because I want this type of packet get dropped in hardware (FPGA) very early, when they hit the box, mostly without touching the CPU, I set the thresholds to ‘10’ on the Mitigation Threshold EPS and to ‘10’ on Detection Threshold EPS. That means as soon as a TMM sees more then 10 pps for that vector it will give me a log message and also rate-limit this type of packets per TMM to 10 packets per second. That means that everything below that threshold will get to the operating system (TMOS) and get dropped there. Figure 4: Bad TCP Flags vector As soon as I start the attack, which targets the web service (10.103.1.50, port 80) behind the DHD with randomized source IPs. $ /usr/sbin/hping3 --ymas -p 80 10.103.1.50 --flood --rand-source I do get a log messages in /var/log/ltm: Feb 5 10:57:52 lon-i5800-1 err tmm3[15367]: 01010252:3: A Enforced Device DOS attack start was detected for vector Bad TCP flags (all cleared), Attack ID 546994598. And, my script shows me the details on that attack in real time (the line is in ‘red’, indicating we are mitigating): Currently 437569 pps are hitting the device. 382 pps are blocked by DDoS in SW (CPU) and 437187 are blocked in HW (FPGA). Figure 5: Mitigating Y-Flood Great, that was easy. :-) Now, let’s do another TCP flood against my web server. RST-flood against a protected server with Fully manual Threshold mode: For this test I´m using the “Fully Manual” mode, which configures the thresholds for the whole service we are protecting with the DoS profile, which is attached to my VS/PO. Figure 6: RST flood with manual configuration My Detection Threshold and my Mitigation Threshold EPS is set to ‘100’. That means as soon as we see more then 100 RST packets hitting the configured VS/PO on my BIG-IP for this web server, the system will start to rate-limit and send a log message. Figure 7: Mitigating RST flood on PO level Perfect. We see the vector in the context of my web server (/Common/PO_10.103.1.50_HTTP) is blocking (rate-limiting) as expected from the configuration. Please ignore the 'IP bad src' which is in detected mode. This is because 'hping' creates randomized IPs and not all of them are valid. RST-flood against a protected server with Fully Automatic Threshold mode: In this test I set the Threshold Mode for the RST vector on the DoS profile which is attached to my web server to ‘Fully Automatic’ and this is what you would most likely do in the real world as well. Figure 8: RST vector configuration with Fully Automatic But, what does this mean for the test now? I run the same flood against the same destination and my script shows me the anomaly on the VS/PO (and on the device context), but it does not mitigate! Why would this happen? Figure 9: RST flood with Fully Automatic configuration When we take a closer look at the screenshot we see that the ‘stats_rate’ shows 730969 pps. The detection rate shows 25. From where is this 25 coming? As we know, when ‘Fully Automatic’ is enabled then the system learns from history. In this case, the history was even lower than 25, but because I set the floor value to 100, the detection rate per TMM is 25 (floor_value / number of TMMs), which in my case is 100/4 = 25 So, we need to recognize, that the ‘stats_rate’ value represents all packets for that vector in that context and the detection value is showing the per TMM value. This value explains us why the system has detected an attack, but why is it not dropping via DoS functionalities? To understand this, we need to remember that the mitigation in ‘Fully Automatic’ mode will ONLY kick in if the incoming rate for that vector is above the detection rate (condition is here now true) AND the stress on the service is too high. But, because BIG-IP is configures as a stateful device, this randomized RST packets will never reach the web service, because they get all dropped latest by the state engine of the BIG-IP. Therefor the service will never have stress caused by this flood.This is one of the nice benefits of having a stateful DoS device. So, the vector on the web server context will not mitigate here, because the web server will not be stressed by this type of TCP attack. This does also explains the Server Stress visualization in the GUI, which didn´t change before and during the attack. Figure 10: DoS Overview in the GUI But, what happens if the attack gets stronger and stronger or the BIG-IP is too busy dealing with all this RST packets? This is when the Device DOS kicks in but only if you have configured it in ‘Fully Automatic’ mode as well. As soon as the BIG-IP receives more RST packets then usually (detection rate) AND the stress (CPU load) on the BIG-IP gets too high, it starts to mitigate on the device context. This is what you can see here: Figure 11: 'massive' RST flood with Fully Automatic configuration The flood still goes against the same web server, but the mitigation is done on the device context, because the CPU utilization on the BIG-IP is too high. In the screenshot below you can see that the value for the mitigation (mitigation_curr) is set to 5000 on the device context, which is the same as the detection value. This value results from the 'floor' value as well. It is the smallest possible value, because the detection and mitigation rate will never be below the 'floor' value. The mitigation rate is calculated dynamically based on the stress of the BIG-IP. In this test I artificially increased the stress on the BIG-IP and therefor the mitigation rate was calculated to the lowest possible number, which is the same as the detection rate. I will provide an explanation of how I did that later. Figure 13: Device context configuration for RST Flood Because this is the device config, the value you enter in the GUI is per TMM and this is reflected on the script output as well. What does this mean for the false-positive rate? First of all, all RST packets not belonging to an existing flow will kicked out by the state engine. At this point we don´t have any false positives. If the attack increases and the CPU can´t handle the number of packets anymore, then the DOS protection on the device context kicks in. With the configuration we have done so far, it will do the rate-limiting on all RST packets hitting the BIG-IP. There is no differentiation anymore between good and bad RST, or if the RST has the destination of server 1 or server 2, and so on. This means that at this point we can face false positives with this configuration. Is this bad? Well, false-positives are always bad, but at this point you can say it´s better to have few false-positives then a service going down or, even more critical, when your DoS device goes down. What can you do to only have false positives on the destination which is under attack? You probably have recognized that you can also enable “Attacked Destination Detection” on the DoS vector, which makes sense on the device context and on a DoS profile which is used on protected object (VS), that covers a whole network. Figure 14: Device context configuration for RST Flood with 'Attacked Destination Detection' enabled If the attack now hits one or multiple IPs in that network, BIG-IP will identify them and will do the rate-limiting only on the destination(s) under attack. Which still means that you could face false positives, but they will be at least only on the IPs under attack. This is what we see here: Figure 15: Device context mitigation on attacked destination(s) The majority of the RST packet drops are done on the “bad destination” (bd_drops_rate), which is the IP under attack. The other option you can also set is “Bad Actor Detection”. When this is enabled the system identifies the source(s) which causes the load and will do the rate limiting for that IP address(es). This usually works very well for amplification attacks, where the attack packets coming from ‘specific’ hosts and are not randomized sources. Figure 16: Device context mitigation on attacked destination(s) and bad actor(s) Here you can see the majority of the mitigation is done on ‘bad actors’. This reduces the chance of false positives massively. Figure 17: Device context configuration for RST Flood with 'Attacked Destination Detection' and 'Bad Actor Detection' enabled You also have multiple additional options to deal with ‘attacked destination’ and ‘bad actors’, but this is something I will cover in another article. Artificial increase BIG-IPs CPU load Before I finish this article, I would like to give you an idea on how you could increase the CPU load of the BIG-IP for your own testing. Because, as we know, with “Fully Automatic” on the device context, the mitigation kicks only in if the packet rate is above the detection rate AND the CPU utilization on the BIG-IP is “too” high. This is sometimes difficult to archive in a lab because you may not be able to send enough packets to stress the CPUs of a HW BIG-IP. In this use-case I use a simple iRule, which I attach to the VS/PO that is under attack. Figure 18: Stress iRule When I start my attack, I send the traffic with a specific TTL for identification. This TTL is configured in my iRule in order to get a CPU intensive string compare function to work on every attack packet. Here is an example for 'hping': $ /usr/sbin/hping3 --rst -p 80 10.103.1.50 --ttl 5 --flood --rand-source This can easily drive the CPU very high and the DDoS rate-limiting kicks in very aggressive. Summary I hope that this article provides you with an even better understanding on what effect the different threshold modes have on the attack mitigation. Of course, keep in mind this are just the ‘static DoS’ vectors. In later articles I will explain also the 'Behavioral DoS' and the Cookie based mitigation, which helps to massively reduce the chance of a false positives. But, also keep in mind, the DoS vectors start to act in microseconds and are very effective for protecting. Thank you, sVen Mueller ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"15825","kudosSumWeight":12,"repliesCount":3,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTUwMDVpMTU3QTZGNTE0MDU4QkFBNA?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtOTA2M2lDODUzMEQzMzJERTc0QzlD?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtODAxMGk2OTNCMzcyQkJDMzEwRDc3?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtOTE0NWk4OUQ3NTEzREExMUI5Mjk2?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDU","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTUyNzBpRTRGQzE2NUJFRENDMTU3QQ?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDY","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTIxMzBpNkUwMUU4RTIwQjZCNjc5MA?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDc","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTE2OGkyMzI1OUJFMzVCMTZGQUE2?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDg","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMzg3Nmk0REYwNUUyQzBERkNEOTAy?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDk","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtNTc4MGlBQ0QwMTRDNjZBRkM5MDBC?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEw","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTI5MzFpNTYwREREOUVDMTBBODY4QQ?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEx","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTMxMzhpNzNFRDNBNUQ4RTNEMDRGMw?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEy","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTA4MjRpNzI1NUQyNTc1MTBFNEU3Rg?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEz","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtNjc1M2lGOEFEMDlFNUM0MDE1OTcw?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE0","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTczMGk3RjYyRTkxQ0YwRDQ5OEE3?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE1","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMzIxNmk1MUU3QThGRUUxRjUxNjEz?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE2","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtMTYwMjRpNDE1NUFFOUMzNUMxNjRBOA?revision=1\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE3","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODY4NTEtOTkyaTQyOEIzM0Y2OEY3RkI4REM?revision=1\"}"}}],"totalCount":17,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:279434":{"__typename":"Conversation","id":"conversation:279434","topic":{"__typename":"TkbTopicMessage","uid":279434},"lastPostingActivityTime":"2022-12-09T12:19:49.327-08:00","solved":false},"User:user:56733":{"__typename":"User","uid":56733,"login":"Javier_Velasco","registrationData":{"__typename":"RegistrationData","status":null},"deleted":false,"avatar":{"__typename":"UserAvatar","url":"https://community.f5.com/t5/s/zihoc95639/m_assets/avatars/default/avatar-3.svg?time=0"},"id":"user:56733"},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0MzQtNDYyN2lBQTc0OUJGOTVGOEYyRDY5?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0MzQtNDYyN2lBQTc0OUJGOTVGOEYyRDY5?revision=2","title":"0EM1T000002bekt.png","associationType":"BODY","width":1629,"height":425,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0MzQtOTQ5MGkxREE1Q0Q0Q0VENkY4QUYy?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0MzQtOTQ5MGkxREE1Q0Q0Q0VENkY4QUYy?revision=2","title":"0EM1T000002beku.png","associationType":"BODY","width":1640,"height":474,"altText":null},"TkbTopicMessage:message:279434":{"__typename":"TkbTopicMessage","subject":"6. SYN Cookie: Hardware vs Software","conversation":{"__ref":"Conversation:conversation:279434"},"id":"message:279434","revisionNum":2,"uid":279434,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:56733"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":1692},"postTime":"2021-03-24T08:23:19.000-07:00","lastPublishTime":"2022-12-09T12:19:49.327-08:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Introduction \n 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. \n 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. \n Hardware SYN Cookie \n 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. \n 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). \n Neuron \n 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. \n 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. \n SYN Cookie Neuron does not offload AFM Global SYN Cookie, it works for: \n \n LTM Global SYN Cookie \n Per VLAN SYN Cookie \n LTM Per Virtual SYN Cookie \n AFM Per Virtual SYN Cookie \n \n 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. \n 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. \n Disabling SYN Cookie \n 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: \n \n tmsh list sys db pvasyncookies.enabled\nsys db pvasyncookies.enabled {\n value \"false\"\n}\n \n \n 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. \n 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: \n \n \n Fig14. Disabling SYN Cookie \n \n In table below I summarize how to disable hardware and software SYN Cookie in each context for the different scopes. \n \n \n 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. \n Warnings \n 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: \n \n You have disabled autolasthop. This option must be enabled if you want to offload SYN Cookie into hardware (K16887). \n 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. \n 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. \n 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. \n \n In order to end up this section with clear ideas, remember that hardware SYN Cookie and hardware flow acceleration are two different concepts. \n \n Conclusion \n 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. ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"7448","kudosSumWeight":1,"repliesCount":0,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0MzQtNDYyN2lBQTc0OUJGOTVGOEYyRDY5?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0MzQtOTQ5MGkxREE1Q0Q0Q0VENkY4QUYy?revision=2\"}"}}],"totalCount":2,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:279489":{"__typename":"Conversation","id":"conversation:279489","topic":{"__typename":"TkbTopicMessage","uid":279489},"lastPostingActivityTime":"2022-12-09T12:19:32.528-08:00","solved":false},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktMjE3OGk4RTc5NjVCMzJBQjY2QzZD?revision=3\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktMjE3OGk4RTc5NjVCMzJBQjY2QzZD?revision=3","title":"0EM1T000002bY5X.png","associationType":"BODY","width":475,"height":463,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktMTExOWlBOUE3RDQyNDFCQjJFQzJG?revision=3\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktMTExOWlBOUE3RDQyNDFCQjJFQzJG?revision=3","title":"0EM1T000002bY5Y.png","associationType":"BODY","width":1428,"height":190,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktMTIxMTdpMUFBNDQxNDg0OUQzQjkwOQ?revision=3\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktMTIxMTdpMUFBNDQxNDg0OUQzQjkwOQ?revision=3","title":"0EM1T000002bY5Z.png","associationType":"BODY","width":463,"height":381,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktODU2N2k4QjZEN0JCQTE3MjQ4NjFG?revision=3\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktODU2N2k4QjZEN0JCQTE3MjQ4NjFG?revision=3","title":"0EM1T000002bY5a.png","associationType":"BODY","width":1489,"height":184,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktMTQ5NzRpQzI1QkM5QTY3QzhCRDI3NQ?revision=3\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktMTQ5NzRpQzI1QkM5QTY3QzhCRDI3NQ?revision=3","title":"0EM1T000002bY7R.png","associationType":"BODY","width":519,"height":404,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktNTUzNWlCMTlEMDNCMzY3M0NCNTND?revision=3\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktNTUzNWlCMTlEMDNCMzY3M0NCNTND?revision=3","title":"0EM1T000002bZ92.png","associationType":"BODY","width":1490,"height":755,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktNjQ4MWlFRjJEQUYyMTdGRDAzMzFB?revision=3\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktNjQ4MWlFRjJEQUYyMTdGRDAzMzFB?revision=3","title":"0EM1T000002bZ93.png","associationType":"BODY","width":1511,"height":423,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktMzM2NWlBNTc3MkE4NjlCNTFDQThF?revision=3\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktMzM2NWlBNTc3MkE4NjlCNTFDQThF?revision=3","title":"0EM1T000002bZ94.png","associationType":"BODY","width":1555,"height":262,"altText":null},"TkbTopicMessage:message:279489":{"__typename":"TkbTopicMessage","subject":"4. SYN Cookie: LTM Configuration","conversation":{"__ref":"Conversation:conversation:279489"},"id":"message:279489","revisionNum":3,"uid":279489,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:56733"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":2801},"postTime":"2021-03-18T08:59:10.000-07:00","lastPublishTime":"2022-12-09T12:19:32.528-08:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Introduction \n \n 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. \n \n Configuration \n \n 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. \n \n In this section I will explain how to configure SYN Cookie for each context. \n \n Device/Global \n \n 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. \n \n 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. \n \n \n \n \n \n Fig9. Device context \n \n \n \n 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: \n \n \n \n \n \n VLAN context \n \n 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. \n \n 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. \n \n 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. \n \n 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. \n \n \n \n \n \n Fig10. VLAN context \n \n \n \n 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. \n \n \n \n \n \n Virtual server context \n \n 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. \n \n 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. \n \n \n \n \n \n Fig11. Virtual Server context \n \n \n \n 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). \n \n Example for fastL4 configuration: \n \n \n \n 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: \n \n \n \n tmsh modify ltm profile fastl4 fastL4 hardware-syn-cookie <value>\ntmsh modify ltm profile fastl4 fastL4 software-syn-cookie <value>\n \n \n \n \n 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: \n \n \n \n tmsh modify ltm profile fastl4 <name> syn-cookie-dsr-flow-reset-by <bigip | client | none>\n \n \n \n \n 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. \n \n SYN Cookie can work in two different modes at this context. Example for tcp protocol profile: \n \n \n \n \n \n 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. \n \n Default values \n \n In TMOS versions higher than v12 we have the below default values: \n \n \n \n \n \n Three comments related to above values. \n \n \n 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. \n 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. \n 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. \n \n \n \n \n But note that there are also a couple of things to take into account when upgrading from v12.x currently: \n \n \n If virtual server threshold in v12 (DB key pvasyncookies.virtual.maxsyncache) was < 4095 then value will be the same in >v12 after upgrade. \n If virtual server threshold in v12 (DB key pvasyncookies.virtual.maxsyncache) was ≥ 4095 then value after upgrade to ≥v12 will be 8192. \n \n \n This behaviour it is being improved for new versions, so threshold will be kept regardless its original value, as I have commented. \n \n Conclusion \n \n 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. \n \n \n \n ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"8840","kudosSumWeight":1,"repliesCount":2,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktMjE3OGk4RTc5NjVCMzJBQjY2QzZD?revision=3\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktMTExOWlBOUE3RDQyNDFCQjJFQzJG?revision=3\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktMTIxMTdpMUFBNDQxNDg0OUQzQjkwOQ?revision=3\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktODU2N2k4QjZEN0JCQTE3MjQ4NjFG?revision=3\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDU","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktMTQ5NzRpQzI1QkM5QTY3QzhCRDI3NQ?revision=3\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDY","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktNTUzNWlCMTlEMDNCMzY3M0NCNTND?revision=3\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDc","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktNjQ4MWlFRjJEQUYyMTdGRDAzMzFB?revision=3\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDg","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0ODktMzM2NWlBNTc3MkE4NjlCNTFDQThF?revision=3\"}"}}],"totalCount":8,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:279496":{"__typename":"Conversation","id":"conversation:279496","topic":{"__typename":"TkbTopicMessage","uid":279496},"lastPostingActivityTime":"2022-12-09T12:19:07.030-08:00","solved":false},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0OTYtNzU4NmkyNEJDMkM4MTJCOEUzRDMz?revision=3\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0OTYtNzU4NmkyNEJDMkM4MTJCOEUzRDMz?revision=3","title":"0EM1T000002bKgb.png","associationType":"BODY","width":975,"height":750,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0OTYtNjM3OGlEOUEzQjUxODdBNjQ2MTZC?revision=3\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0OTYtNjM3OGlEOUEzQjUxODdBNjQ2MTZC?revision=3","title":"0EM1T000002bKgg.png","associationType":"BODY","width":1610,"height":500,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0OTYtNTQwMWlCNEMxM0VBREJBNDQzMUZC?revision=3\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0OTYtNTQwMWlCNEMxM0VBREJBNDQzMUZC?revision=3","title":"0EM1T000002bKgl.png","associationType":"BODY","width":982,"height":666,"altText":null},"TkbTopicMessage:message:279496":{"__typename":"TkbTopicMessage","subject":"1. SYN Cookie: Intro","conversation":{"__ref":"Conversation:conversation:279496"},"id":"message:279496","revisionNum":3,"uid":279496,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:56733"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":3058},"postTime":"2021-03-05T11:01:31.000-08:00","lastPublishTime":"2022-12-09T12:19:07.030-08:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" Introduction \n As for today one of the most common and easiest DDoS attacks to carry out is TCP SYN flood attack. Due to this, many efforts have been dedicated to implement the best solution to mitigate it. This is why you can find different countermeasures with the same goal, like reducing SYN-RECEIVED timer TCP state, increasing backlog, recycling old TCBs, using TCPCT (RFC6013), implementing SYN cache, etc. but the widest spread choice is TCP SYN Cookie. \n In this article series I explain several aspects of SYN Cookie like how this countermeasure works and how is implemented in BIG-IP, how must be configured, differences between hardware and software SYN Cookie, things to take into account when dealing with SYN Cookie and troubleshooting. All examples shown in these articles are based on TMOS v16, although there could be some slight difference with your specific version it will help you to understand what it is happening in your own system. \n Note that, SYN Cookie term refers to the countermeasure itself, but sometimes you will read SYN Cookie meaning in fact SYN Cookie challenge. I will talk about the difference throughout the articles. \n As a final comment, please be aware that I have tried as much as possible to avoid talking about DB keys or internal commands throughout these article series. In any case, as a rule of thumb, please do not change any DB key unless this change is recommended by an F5 engineer. \n Why SYN Cookie? \n If you review the well-known TCP state diagram you can probably notice a weak point. Below I have extracted the section of TCP diagram that describes a TCP passive open and I have filled in red the specific TCP state that support the TCP SYN flood attack. Reason is that in SYN_RCVD state the system already reserves memory for the incoming connection information, which is saved in the so called TCB (Transmission Control Block). This means that the system starts to consume memory even before the connection is already ESTABLISHED. \n \n Fig1. TCP state diagram section \n \n This can be dangerous due to a simple reason, if a device running a server and waiting for connections receives a huge enough amount of TCP SYN packets then the service could be unavailable for legitimate users. This is because, according to TCP standard, the server must answer with a SYN/ACK packet to all these TCP SYN packets, create a TCB entry for each connection and also wait for last ACK from client. Therefore, the server will need to allocate memory, even without knowing if these connections will be finished successfully or not. \n This is the base of a TCP SYN flood attack. An attacker just needs to generate enough amount of TCP SYN packets to overwhelm a server. Any ISP will allow TCP SYN packets inside their network infrastructure since they cannot know if these packets are legitimate or not, and hence, all these packets will reach the victim. \n TCP SYN flood attack can cause two different symptoms depending on reachability of attacker’s source IPs. Attending to which one you face maybe you could have clues about the origin of the attack: \n 1. Source IPs from where the TCP SYN flood attack is being run are reachable from the attacked device. \n In this case when the target victim replies with expected responses (SYN/ACK) to source IPs the source IPs will response with a RST packet to the server since they are not aware of any TCP connection started from them. \n \n \n Fig2. DDoS TCP SYN Flood attack (bots) \n \n This behaviour will cause that the server most probably detects a TCP RST flood attack together with TCP SYN flood attack: \n \n Feb 22 10:12:54 slot1/AFM1 err tmm2[14782]: 01010252:3: A Enforced Device DOS attack start was detected for vector TCP RST flood, Attack ID 31508769\n \n \n The good news in this case is that server will be able to free up space for more TCBs since upon receiving the RST packet TCP state changes to CLOSED and then to LISTEN and therefore reserved space used for TCP connection will be freed up. \n This is not the common behaviour since what an attacker wants is waste all server resources. Typically, source IPs are random and not reachable from server. \n Attending to this explanation, if you face a RST flood together with a SYN flood attack maybe attacker is just sending an hping3 from internal subnets, or near to your Big-IP device. \n 2. Source IPs are not reachable from the attacked device. \n This is the typical behaviour since, as commented, the idea for TCP SYN flood DDoS attack is consuming all server resources dedicated to TCP connections in order to avoid providing the service to legitimate users. \n Note that when I say ‘reachable’ I mean that TCP SYN/ACK packets sent by server never has a response. Source IP could be reachable by ICMP or by starting a new TCP connection from server, but unrelated SYN/ACK packets from server are dropped at any point in the path, or even in the client itself. So the result is the same as if they were not reachable at all. In this case TCP SYN/ACK packets sent by the server will be lost and hence space for TCB will be reserved until timeout. \n \n \n Fig3. TCP SYN Flood attack (generic) \n \n Note that the word ‘attack’ in this article series does not mandatorily refers to intentional attacker, but also can refer to legitimate devices doing something wrong by error or ignorance. Also a wrong SYN Cookie configuration can warn us about a non real TCP SYN flood attack. \n Conclusion \n At this point you know basic theory under TCP SYN flood attack, so the question now is, how can you avoid that a simple TCP SYN packet reserves space for TCB entry? \n You cannot. Since you have to keep with TCP standard only choice left is rejecting the TCP SYN packet and close the connection. Then the question is how to guarantee that legitimate clients will be able to connect to the server if you close their connections, and solution is, using TCP specification to your benefit. \n This is what TCP SYN Cookie does and what I will review in the next article, showing how it is implemented in BIG-IP. \n ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"6163","kudosSumWeight":3,"repliesCount":0,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0OTYtNzU4NmkyNEJDMkM4MTJCOEUzRDMz?revision=3\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0OTYtNjM3OGlEOUEzQjUxODdBNjQ2MTZC?revision=3\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yNzk0OTYtNTQwMWlCNEMxM0VBREJBNDQzMUZC?revision=3\"}"}}],"totalCount":3,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"Conversation:conversation:285612":{"__typename":"Conversation","id":"conversation:285612","topic":{"__typename":"TkbTopicMessage","uid":285612},"lastPostingActivityTime":"2022-08-12T12:18:55.912-07:00","solved":false},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTU5NjVpMEUyRkNBODBGNzU5MzU4Rg?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTU5NjVpMEUyRkNBODBGNzU5MzU4Rg?revision=2","title":"0151T000003pk8mQAA.png","associationType":"BODY","width":249,"height":216,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNTc1aUI0ODkxMjU1RDc3OTJCODY?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNTc1aUI0ODkxMjU1RDc3OTJCODY?revision=2","title":"0151T000003pk8rQAA.png","associationType":"BODY","width":902,"height":589,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNTYxMmkyQUU5RDJCMjhEQ0M1QkEw?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNTYxMmkyQUU5RDJCMjhEQ0M1QkEw?revision=2","title":"0151T000003pk8wQAA.png","associationType":"BODY","width":947,"height":888,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTUzMDRpNzZERTk0MkJDNzJBODExMQ?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTUzMDRpNzZERTk0MkJDNzJBODExMQ?revision=2","title":"0151T000003pk8sQAA.png","associationType":"BODY","width":985,"height":258,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNDgyMmk1OTUxMkU1NEZCNjEwQzJC?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNDgyMmk1OTUxMkU1NEZCNjEwQzJC?revision=2","title":"0151T000003pk91QAA.png","associationType":"BODY","width":965,"height":445,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTU5NzFpNDUxQTU0Mjc3OTdFRDdBOQ?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTU5NzFpNDUxQTU0Mjc3OTdFRDdBOQ?revision=2","title":"0151T000003pk9BQAQ.png","associationType":"BODY","width":592,"height":448,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItODk3NGk4OTNDMUNFRDgyNTlGQ0NC?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItODk3NGk4OTNDMUNFRDgyNTlGQ0NC?revision=2","title":"0151T000003pk9GQAQ.png","associationType":"BODY","width":644,"height":193,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNTEwMmlDNDgwNEE4MTYzRkI0ODQ1?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNTEwMmlDNDgwNEE4MTYzRkI0ODQ1?revision=2","title":"0151T000003pk9LQAQ.png","associationType":"BODY","width":991,"height":412,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTIwNTdpOTM1QjZENjQwMTUxNDE5OQ?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTIwNTdpOTM1QjZENjQwMTUxNDE5OQ?revision=2","title":"0151T000003pk9VQAQ.png","associationType":"BODY","width":984,"height":277,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNjQwNGk1NDdGQTU0NkVBNDE4MzY2?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNjQwNGk1NDdGQTU0NkVBNDE4MzY2?revision=2","title":"0151T000003pk9WQAQ.png","associationType":"BODY","width":955,"height":575,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTI0MDhpODJFMzMyMTk3OTg3MTgzOA?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTI0MDhpODJFMzMyMTk3OTg3MTgzOA?revision=2","title":"0151T000003pk9fQAA.png","associationType":"BODY","width":983,"height":165,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNjI4aTY3ODhGNTdFQjRDNTcwRkY?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNjI4aTY3ODhGNTdFQjRDNTcwRkY?revision=2","title":"0151T000003pk9kQAA.png","associationType":"BODY","width":654,"height":634,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTMwNDhpRTRDODYyNUZBQzhDNkU3OA?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTMwNDhpRTRDODYyNUZBQzhDNkU3OA?revision=2","title":"0151T000003pk9gQAA.png","associationType":"BODY","width":623,"height":155,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTA2OTZpNkM1QUI5RTVBRTM5MEY4Ng?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTA2OTZpNkM1QUI5RTVBRTM5MEY4Ng?revision=2","title":"0151T000003pk9uQAA.png","associationType":"BODY","width":991,"height":412,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNzg5NWlFMUMyOTU1MjczNjlEOEMy?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNzg5NWlFMUMyOTU1MjczNjlEOEMy?revision=2","title":"0151T000003pk9vQAA.png","associationType":"BODY","width":976,"height":274,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTE2MzhpMTQ3MUM0OUZGNjAxNEE5Mw?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTE2MzhpMTQ3MUM0OUZGNjAxNEE5Mw?revision=2","title":"0151T000003pk9hQAA.png","associationType":"BODY","width":958,"height":576,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItOTMwMWkzNkQzRjk4MDZDNzk3ODVE?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItOTMwMWkzNkQzRjk4MDZDNzk3ODVE?revision=2","title":"0151T000003pkAEQAY.png","associationType":"BODY","width":1006,"height":177,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNjQwMmlGMEQzRUFDQkJCMjQ1M0JB?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNjQwMmlGMEQzRUFDQkJCMjQ1M0JB?revision=2","title":"0151T000003pkATQAY.png","associationType":"BODY","width":654,"height":634,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMzIzM2k4MkYzQ0Q2NTY5RDNEOEVB?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMzIzM2k4MkYzQ0Q2NTY5RDNEOEVB?revision=2","title":"0151T000003pkAUQAY.png","associationType":"BODY","width":668,"height":103,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNTQwOGk2RDlDMDdERTYzQzJFRTAz?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNTQwOGk2RDlDMDdERTYzQzJFRTAz?revision=2","title":"0151T000003pkAYQAY.png","associationType":"BODY","width":661,"height":75,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTE4NjlpOTY0OTBDQ0UzQjE1OTQwNA?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTE4NjlpOTY0OTBDQ0UzQjE1OTQwNA?revision=2","title":"0151T000003pkAdQAI.png","associationType":"BODY","width":396,"height":221,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNjU5MGkyQ0VGNDhCQTc0RjJCRjI3?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNjU5MGkyQ0VGNDhCQTc0RjJCRjI3?revision=2","title":"0151T000003pk9XQAQ.png","associationType":"BODY","width":791,"height":524,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTI3MjJpRUMzMjdBOTA5RkJDOTNEMQ?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTI3MjJpRUMzMjdBOTA5RkJDOTNEMQ?revision=2","title":"0151T000003pkAVQAY.png","associationType":"BODY","width":520,"height":444,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNDk2OGlFNTIxOEVGQjhCRjU1QzZF?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNDk2OGlFNTIxOEVGQjhCRjU1QzZF?revision=2","title":"0151T000003pk9qQAA.png","associationType":"BODY","width":1043,"height":435,"altText":null},"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTAwMGlBNTQxQzdFMEU4NTI5NzZC?revision=2\"}":{"__typename":"AssociatedImage","url":"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTAwMGlBNTQxQzdFMEU4NTI5NzZC?revision=2","title":"0151T000003pkAiQAI.png","associationType":"BODY","width":1043,"height":338,"altText":null},"TkbTopicMessage:message:285612":{"__typename":"TkbTopicMessage","subject":"Orchestrated Infrastructure Security - Guided Configuration","conversation":{"__ref":"Conversation:conversation:285612"},"id":"message:285612","revisionNum":2,"uid":285612,"depth":0,"board":{"__ref":"Tkb:board:TechnicalArticles"},"author":{"__ref":"User:user:129415"},"teaser@stripHtml({\"removeProcessingText\":true,\"truncateLength\":-1})":"","introduction":"","metrics":{"__typename":"MessageMetrics","views":522},"postTime":"2020-10-09T14:10:38.000-07:00","lastPublishTime":"2022-08-12T12:18:55.912-07:00","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})":" The F5 Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latest here. \n \n Introduction \n This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability, Central Management with BIG-IQ, Application Visibility with Beacon and the protection of critical assets using F5 Advanced WAF and Protocol Inspection (IPS) with AFM. It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working. \n If you need help setting up SSL Orchestrator for the first time, refer to the Dev/Central article series Implementing SSL Orchestrator here. \n This article focuses on configuring SSL Orchestrator to decrypt inbound SSL and pass the decrypted content to F5 Advanced WAF and Protocol Inspection (IPS) with AFM for enhanced protection from threats. It covers the configuration of the SSL Orchestrator Topology, Services and more on an F5 BIG-IP running version 15.1.0.4 and SSL Orchestrator version 7.4.9. \n Configuration of BIG-IP deployed as SSL Orchestrator can be downloaded from here from GitLab. \n Please forgive me for using SSL and TLS interchangeably in this article. \n In this article we will walk you through the SSL Orchestrator Guided Configuration which covers the following: \n \n Inbound L2 Topology creation \n Certificate and Key used for SSL Decryption \n Adding the Advanced WAF and AFM devices \n Creating a Security Policy \n Creating an Interception Policy \n \n SSL Orchestrator Guided Configuration \n From the BIG-IP Configuration Utility select SSL Orchestrator > Configuration from the menu on the left. \n \n Note: There are Required Configuration options on the right you may need to configure. A Route is not needed when SSL Orchestrator is deployed in Layer 2 mode. \n The Configuration screen presents all of the configuration options that are available. Scroll to the bottom of the page and click Next. \n \n Give the Topology a name, InboundAppProtection in this example. You can optionally configure the Protocol and IP Family you want the Topology to support. We’re using the default of TCP and IPv4. Select L2 Inbound and click Save & Next. \n \n Configure the Certificate Key Chain by clicking the Pencil icon on the right. \n \n Choose the correct Certificate and Key from the drop menu. In this example we use subrsa.f5labs.com for the Certificate and Key. Click Done. \n \n There are Server-side SSL settings that you can optionally configure. Click Save & Next. \n \n On the next screen click Add Service. \n \n Scroll to the bottom, select Generic Inline Layer 2 and then Add. \n \n Give it a name, Advanced_WAF in this example. Under Network Configuration click Add. \n \n Here we create the VLANs & select the Interfaces the Advanced WAF devices are connected to. For the From and To VLAN options select Create New. Give them a unique name, egress_WAF1 and ingress_WAF1 in this example. Select the interfaces connected to the first WAF device, 4.1 and 4.2 in this example. Then click Done. \n \n Repeat this process for the 2 nd Advanced WAF device using interfaces 4.3 and 4.4. It should look like this when done. \n \n Note: In this case the SSL Orchestrator interfaces 4.1 and 4.2 are connected to Advanced WAF1 interfaces 2.1 and 2.2. SSL Orchestrator interfaces 4.3 and 4.4 are connected to Advanced WAF2 interfaces 2.3 and 2.4. \n You can optionally configure the Device Monitor and Service Down Action. Enable the Port Remap option and click Save. \n \n Click Add Service to add the AFM devices. \n \n Scroll to the bottom, select Generic Inline Layer 2 and then Add. \n \n Give it a name, AFM in this example. Under Network Configuration click Add. \n \n Here we create the VLANs & select the Interfaces the AFM devices are connected to. For the From and To VLAN options select Create New. Give them a unique name, egress_AFM1 and ingress_AFM1 in this example. Select the interfaces connected to the first AFM device, 5.1 and 5.2 in this example. Then click Done. \n \n Repeat this process for the 2 nd AFM device using interfaces 5.3 and 5.4. It should look like this when done. \n \n Note: In this case the SSL Orchestrator interfaces 5.1 and 5.2 are connected to AFM1 interfaces 5.0 and 6.0. SSL Orchestrator interfaces 5.3 and 5.4 are connected to AFM2 interfaces 5.0 and 6.0. \n You can optionally configure the Device Monitor and Service Down Action. Enable the Port Remap option and click Save. \n \n Click Save & Next at the bottom. \n \n \n \n Click Add to create the Service Chain. \n \n Give it a name, Inbound_Protect1 in this example. Select ssloS_AFM and ssloS_Advanced_WAF Services then click the arrow to move them to the right. Click Save. \n \n Note: It is recommended that AFM be placed first in the Service Chain Order. That way intrusion attempts are detected and blocked before they ever get to the Advanced WAF. This saves resources on the Advanced WAFs because they don’t have to process any of the attempted intrusion connections. \n Click Save & Next. \n \n For the Security Policy click the Pencil icon on the lower right to edit the rule. \n \n Set the Service Chain to the one created previously. Click OK. \n \n Click Save & Next at the bottom. \n \n For the Interception Rule, define the Destination Address or subnet of the application servers you wish to protect. In this example the application servers are all in the 10.4.1.0/24 subnet. Specify the correct port, typically 443. \n \n For the Ingress Network select the VLAN(s) that will be receiving traffic from external users, Direct_all in this example. Set the L7 Profile to http. Click Save & Next. \n \n Make any changes to the Log Settings if needed. Click Save & Next. \n \n On the Summary screen you can review and change any of the settings. Click Deploy when ready. \n \n You should get a Success message. \n \n If you receive an error you will need to go back into the configuration to resolve it. If successful, you should see a screen like this: \n \n Notice the Service Health status is indicated by the small green circle. \n Summary \n In this article you learned how to use the SSL Orchestrator Guided Configuration to create a Topology, select the certificate and key used for SSL Decryption, add the Advanced WAF and AFM devices, create a Security Policy and an Interception Policy. \n Next Steps \n Click Next to proceed to the next article in the series. ","body@stripHtml({\"removeProcessingText\":true,\"removeSpoilerMarkup\":true,\"removeTocMarkup\":true,\"truncateLength\":-1})@stringLength":"6829","kudosSumWeight":0,"repliesCount":0,"readOnly":false,"images":{"__typename":"AssociatedImageConnection","edges":[{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTU5NjVpMEUyRkNBODBGNzU5MzU4Rg?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNTc1aUI0ODkxMjU1RDc3OTJCODY?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDM","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNTYxMmkyQUU5RDJCMjhEQ0M1QkEw?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDQ","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTUzMDRpNzZERTk0MkJDNzJBODExMQ?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDU","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNDgyMmk1OTUxMkU1NEZCNjEwQzJC?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDY","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTU5NzFpNDUxQTU0Mjc3OTdFRDdBOQ?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDc","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItODk3NGk4OTNDMUNFRDgyNTlGQ0NC?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDg","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNTEwMmlDNDgwNEE4MTYzRkI0ODQ1?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDk","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTIwNTdpOTM1QjZENjQwMTUxNDE5OQ?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEw","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNjQwNGk1NDdGQTU0NkVBNDE4MzY2?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEx","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTI0MDhpODJFMzMyMTk3OTg3MTgzOA?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEy","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNjI4aTY3ODhGNTdFQjRDNTcwRkY?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDEz","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTMwNDhpRTRDODYyNUZBQzhDNkU3OA?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE0","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTA2OTZpNkM1QUI5RTVBRTM5MEY4Ng?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE1","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNzg5NWlFMUMyOTU1MjczNjlEOEMy?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE2","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTE2MzhpMTQ3MUM0OUZGNjAxNEE5Mw?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE3","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItOTMwMWkzNkQzRjk4MDZDNzk3ODVE?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE4","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNjQwMmlGMEQzRUFDQkJCMjQ1M0JB?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDE5","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMzIzM2k4MkYzQ0Q2NTY5RDNEOEVB?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDIw","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNTQwOGk2RDlDMDdERTYzQzJFRTAz?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDIx","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTE4NjlpOTY0OTBDQ0UzQjE1OTQwNA?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDIy","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNjU5MGkyQ0VGNDhCQTc0RjJCRjI3?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDIz","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTI3MjJpRUMzMjdBOTA5RkJDOTNEMQ?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI0","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItNDk2OGlFNTIxOEVGQjhCRjU1QzZF?revision=2\"}"}},{"__typename":"AssociatedImageEdge","cursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI1","node":{"__ref":"AssociatedImage:{\"url\":\"https://community.f5.com/t5/s/zihoc95639/images/bS0yODU2MTItMTAwMGlBNTQxQzdFMEU4NTI5NzZC?revision=2\"}"}}],"totalCount":32,"pageInfo":{"__typename":"PageInfo","hasNextPage":true,"endCursor":"MjUuMnwyLjF8b3wyNXxfTlZffDI1","hasPreviousPage":false,"startCursor":null}},"videos":{"__typename":"VideoConnection","edges":[],"totalCount":0,"pageInfo":{"__typename":"PageInfo","hasNextPage":false,"endCursor":null,"hasPreviousPage":false,"startCursor":null}}},"CachedAsset:text:en_US-components/community/Navbar-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/community/Navbar-1743097583657","value":{"community":"Community Home","inbox":"Inbox","manageContent":"Manage Content","tos":"Terms of Service","forgotPassword":"Forgot Password","themeEditor":"Theme Editor","edit":"Edit Navigation Bar","skipContent":"Skip to content","migrated-link-9":"Groups","migrated-link-7":"Technical Articles","migrated-link-8":"DevCentral News","migrated-link-1":"Technical Forum","migrated-link-10":"Community Groups","migrated-link-2":"Water Cooler","migrated-link-11":"F5 Groups","Common-external-link":"How Do I...?","migrated-link-0":"Forums","article-series":"Article Series","migrated-link-5":"Community Articles","migrated-link-6":"Articles","security-insights":"Security Insights","migrated-link-3":"CrowdSRC","migrated-link-4":"CodeShare","migrated-link-12":"Events","migrated-link-13":"Suggestions"},"localOverride":false},"CachedAsset:text:en_US-components/community/NavbarHamburgerDropdown-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/community/NavbarHamburgerDropdown-1743097583657","value":{"hamburgerLabel":"Side Menu"},"localOverride":false},"CachedAsset:text:en_US-components/community/BrandLogo-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/community/BrandLogo-1743097583657","value":{"logoAlt":"Khoros","themeLogoAlt":"Brand Logo"},"localOverride":false},"CachedAsset:text:en_US-components/community/NavbarTextLinks-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/community/NavbarTextLinks-1743097583657","value":{"more":"More"},"localOverride":false},"CachedAsset:text:en_US-components/authentication/AuthenticationLink-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/authentication/AuthenticationLink-1743097583657","value":{"title.login":"Sign In","title.registration":"Register","title.forgotPassword":"Forgot Password","title.multiAuthLogin":"Sign In"},"localOverride":false},"CachedAsset:text:en_US-components/nodes/NodeLink-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/nodes/NodeLink-1743097583657","value":{"place":"Place {name}"},"localOverride":false},"CachedAsset:text:en_US-components/tags/TagSubscriptionAction-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/tags/TagSubscriptionAction-1743097583657","value":{"success.follow.title":"Following Tag","success.unfollow.title":"Unfollowed Tag","success.follow.message.followAcrossCommunity":"You will be notified when this tag is used anywhere across the community","success.unfollowtag.message":"You will no longer be notified when this tag is used anywhere in this place","success.unfollowtagAcrossCommunity.message":"You will no longer be notified when this tag is used anywhere across the community","unexpected.error.title":"Error - Action Failed","unexpected.error.message":"An unidentified problem occurred during the action you took. Please try again later.","buttonTitle":"{isSubscribed, select, true {Unfollow} false {Follow} other{}}","unfollow":"Unfollow"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageListTabs-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageListTabs-1743097583657","value":{"mostKudoed":"{value, select, IDEA {Most Votes} other {Most Likes}}","mostReplies":"Most Replies","mostViewed":"Most Viewed","newest":"{value, select, IDEA {Newest Ideas} OCCASION {Newest Events} other {Newest Topics}}","newestOccasions":"Newest Events","mostRecent":"Most Recent","noReplies":"No Replies Yet","noSolutions":"No Solutions Yet","solutions":"Solutions","mostRecentUserContent":"Most Recent","trending":"Trending","draft":"Drafts","spam":"Spam","abuse":"Abuse","moderation":"Moderation","tags":"Tags","PAST":"Past","UPCOMING":"Upcoming","sortBymostRecent":"Sort By Most Recent","sortBymostRecentUserContent":"Sort By Most Recent","sortBymostKudoed":"Sort By Most Likes","sortBymostReplies":"Sort By Most Replies","sortBymostViewed":"Sort By Most Viewed","sortBynewest":"Sort By Newest Topics","sortBynewestOccasions":"Sort By Newest Events","otherTabs":" Messages list in the {tab} for {conversationStyle}","guides":"Guides","archives":"Archives"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/common/QueryHandler-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/common/QueryHandler-1743097583657","value":{"title":"Query Handler"},"localOverride":false},"CachedAsset:text:en_US-components/community/NavbarDropdownToggle-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/community/NavbarDropdownToggle-1743097583657","value":{"ariaLabelClosed":"Press the down arrow to open the menu"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/common/OverflowNav-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/common/OverflowNav-1743097583657","value":{"toggleText":"More"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageView/MessageViewInline-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageView/MessageViewInline-1743097583657","value":{"bylineAuthor":"{bylineAuthor}","bylineBoard":"{bylineBoard}","anonymous":"Anonymous","place":"Place {bylineBoard}","gotoParent":"Go to parent {name}"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/common/Pager/PagerLoadMore-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/common/Pager/PagerLoadMore-1743097583657","value":{"loadMore":"Show More"},"localOverride":false},"CachedAsset:text:en_US-components/customComponent/CustomComponent-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/customComponent/CustomComponent-1743097583657","value":{"errorMessage":"Error rendering component id: {customComponentId}","bannerTitle":"Video provider requires cookies to play the video. Accept to continue or {url} it directly on the provider's site.","buttonTitle":"Accept","urlText":"watch"},"localOverride":false},"CachedAsset:text:en_US-components/users/UserLink-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/users/UserLink-1743097583657","value":{"authorName":"View Profile: {author}","anonymous":"Anonymous"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageSubject-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageSubject-1743097583657","value":{"noSubject":"(no subject)"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageTime-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageTime-1743097583657","value":{"postTime":"Published: {time}","lastPublishTime":"Last Update: {time}","conversation.lastPostingActivityTime":"Last posting activity time: {time}","conversation.lastPostTime":"Last post time: {time}","moderationData.rejectTime":"Rejected time: {time}"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/nodes/NodeIcon-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/nodes/NodeIcon-1743097583657","value":{"contentType":"Content Type {style, select, FORUM {Forum} BLOG {Blog} TKB {Knowledge Base} IDEA {Ideas} OCCASION {Events} other {}} icon"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageUnreadCount-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageUnreadCount-1743097583657","value":{"unread":"{count} unread","comments":"{count, plural, one { unread comment} other{ unread comments}}"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageViewCount-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageViewCount-1743097583657","value":{"textTitle":"{count, plural,one {View} other{Views}}","views":"{count, plural, one{View} other{Views}}"},"localOverride":false},"CachedAsset:text:en_US-components/kudos/KudosCount-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/kudos/KudosCount-1743097583657","value":{"textTitle":"{count, plural,one {{messageType, select, IDEA{Vote} other{Like}}} other{{messageType, select, IDEA{Votes} other{Likes}}}}","likes":"{count, plural, one{like} other{likes}}"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageRepliesCount-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageRepliesCount-1743097583657","value":{"textTitle":"{count, plural,one {{conversationStyle, select, IDEA{Comment} OCCASION{Comment} other{Reply}}} other{{conversationStyle, select, IDEA{Comments} OCCASION{Comments} other{Replies}}}}","comments":"{count, plural, one{Comment} other{Comments}}"},"localOverride":false},"CachedAsset:text:en_US-components/messages/MessageBody-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-components/messages/MessageBody-1743097583657","value":{"showMessageBody":"Show More","mentionsErrorTitle":"{mentionsType, select, board {Board} user {User} message {Message} other {}} No Longer Available","mentionsErrorMessage":"The {mentionsType} you are trying to view has been removed from the community.","videoProcessing":"Video is being processed. Please try again in a few minutes.","bannerTitle":"Video provider requires cookies to play the video. Accept to continue or {url} it directly on the provider's site.","buttonTitle":"Accept","urlText":"watch"},"localOverride":false},"CachedAsset:text:en_US-shared/client/components/users/UserAvatar-1743097583657":{"__typename":"CachedAsset","id":"text:en_US-shared/client/components/users/UserAvatar-1743097583657","value":{"altText":"{login}'s avatar","altTextGeneric":"User's avatar"},"localOverride":false}}}},"page":"/tags/TagPage/TagPage","query":{"nodeId":"board:TechnicalArticles","tagName":"ddos"},"buildId":"q_bLpq2mflH0BeZigxpj6","runtimeConfig":{"buildInformationVisible":false,"logLevelApp":"info","logLevelMetrics":"info","openTelemetryClientEnabled":false,"openTelemetryConfigName":"f5","openTelemetryServiceVersion":"25.2.0","openTelemetryUniverse":"prod","openTelemetryCollector":"http://localhost:4318","openTelemetryRouteChangeAllowedTime":"5000","apolloDevToolsEnabled":false,"inboxMuteWipFeatureEnabled":false},"isFallback":false,"isExperimentalCompile":false,"dynamicIds":["./components/customComponent/CustomComponent/CustomComponent.tsx","./components/community/Navbar/NavbarWidget.tsx","./components/community/Breadcrumb/BreadcrumbWidget.tsx","./components/tags/TagsHeaderWidget/TagsHeaderWidget.tsx","./components/messages/MessageListForNodeByRecentActivityWidget/MessageListForNodeByRecentActivityWidget.tsx","./components/tags/TagSubscriptionAction/TagSubscriptionAction.tsx","./components/customComponent/CustomComponentContent/TemplateContent.tsx","../shared/client/components/common/List/ListGroup/ListGroup.tsx","./components/messages/MessageView/MessageView.tsx","./components/messages/MessageView/MessageViewInline/MessageViewInline.tsx","../shared/client/components/common/Pager/PagerLoadMore/PagerLoadMore.tsx","./components/customComponent/CustomComponentContent/HtmlContent.tsx","./components/customComponent/CustomComponentContent/CustomComponentScripts.tsx"],"appGip":true,"scriptLoader":[]}