F5 BIG-IP Advanced WAF – DOS profile configuration options.
F5 BIG IP Advanced WAF is the perfect tool for detection and prevention of application Distributed Denial-of-Service (DDoS) attacks against a web application. This article will review the possible configurations of the dos profile also known as Adv WAF anti DDoS feature to stop those attacks.
What is the best option in Hybrid defender when there expected legal campaign (legal huge traffic)
Hello, What is the best option when using Hybrid defender inAuto Detection / Multiplier Based and at a certain time we expect high traffic to be reached to us As certain company is hosted with us they have normal traffic, but at certain time they publish a new service and expect huge number of users to access it So what is the best option in that scenario?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
ASM L7DOS snmp traps
Dear, Do you know of any known issue about l7ddos snmp traps. For some reason they are not sent at all. The log entry in /var/log/dosl7/dosl7d.log is well present, but no snmp trap is sent. I checked the definition in the alertd config files and it looks like it is looking for a specific log entry in order to send the trap: alert.conf alert BIGIP_TS_TS_DOS_ATTACK_DETECTED_ERR { snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.91"; } bigip_ts_error_maps.h 3 LOG_ERR 01310046 BIGIP_TS_TS_DOS_ATTACK_DETECTED_ERR "[SECEV] DoS attack: %s. HTTP classifier: %s, Operation mode: %s" But the problem is that when testing a l7ddos, no log entry can be found in /var/log/asm, there are only logs in /var/log/dosl7/dosl7d.log And it looks like the alertd does not process the later file (K14397) My client is running version 11.5.4 Thanks in advance for your assistance. Abdessamad
ASM L7DOS snmp traps
Dear, Do you know of any known issue about l7ddos snmp traps. For some reason they are not sent at all. The log entry in /var/log/dosl7/dosl7d.log is well present, but no snmp trap is sent. I checked the definition in the alertd config files and it looks like it is looking for a specific log entry in order to send the trap: alert.conf alert BIGIP_TS_TS_DOS_ATTACK_DETECTED_ERR { snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.91"; } bigip_ts_error_maps.h 3 LOG_ERR 01310046 BIGIP_TS_TS_DOS_ATTACK_DETECTED_ERR "[SECEV] DoS attack: %s. HTTP classifier: %s, Operation mode: %s" But the problem is that when testing a l7ddos, no log entry can be found in /var/log/asm, there are only logs in /var/log/dosl7/dosl7d.log And it looks like the alertd does not process the later file (K14397) My client is running version 11.5.4 Thanks in advance for your assistance. AbdessamadAFM protected object address list creation
Hello, What is the best way to create protection objects which have the same protection profile Create a protection object on Address list containing these IPs or create separate protected objects? noting the number of objects are huge System by default does not allow you to assign a protection profile on a protected group created on address list so you have to apply the following workaround, but it is mentionedThis should be considered experimental only Enable afm.allowtmcvirtuals variable https://my.f5.com/manage/s/article/K59471927 so what is the best way?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)
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 aDOS profileof a Protected Object thethreshold 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 andhow 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
