Mitigating 40Gbps DDoS Attacks with the new BIG-IP VE for SmartNICs Solution
Introduction First off, if this is the first you’ve heard of this new solution please do go and either check out this Lightboard Lesson or review this Newsroom Article for more context and to bring yourself up-to-speed with what it is and how it works. In a nutshell though, the BIG-IP VE for SmartNICs solution is comprised of a high performance BIG-IP AFM VE integrated with an Intel FPGA PAC N3000 SmartNIC. By programming an FPGA embedded within the SmartNIC to assume responsibility for detecting and mitigating DDoS attacks, we can offload this function from BIG-IP VE. Processing and blocking all malicious DDoS packets within the FPGA before they reach the network infrastructure alleviates much of the strain such attacks usually place on VE CPU resources while significantly bolstering DDoS performance. If all that sounds too much like marketing fluff for your liking, the purpose of this article is to show just how significant those performance improvements are and how this solution really can protect cloud environments against a range of voluminous, complex attacks. To do so, we are going to compare the performance of the BIG-IP AFM VE for SmartNICs solution against a High Performance BIG-IP AFM VE (software-only) when handling the four different DDoS attack scenarios below: 1.TCP SYN-ACK Flood Attack 2.UDP Flood Attack 3.ICMPv4 Flood Attack 4.Combination of UDP Flood, ICMPv4 Flood and TCP SYN-ACK Flood Attacks Diagram A shows our basic setup, we have an Ixia acting as client and server generating both Malicious and Normal Traffic through the N3000 SmartNIC and BIG-IP VE. Diagram B shows 3.5Gbps of baseline Normal Traffic to show the effect of the malicious traffic on both software-only and then with hardware mitigation ON (SmartNIC FPGA enabled). Note: We are generating Malicious and Normal Traffic off separate ports of the Ixia to max out the malicious traffic port. Diagram A - Simplified layout of the Test Harness Diagram B - Baseline 3.5Gbps of Normal Traffic (Goodput) Test 1 – TCP SYN-ACK Flood Attack Below in Figure 1 you will see a TCP SYN-ACK Flood Attack performed first with software-only (SmartNIC FPGA disabled); this shows an initial drop of our Goodput at 1.6Gbps of malicious traffic and approaching zero at only 2.4Gbps with 100% CPU usage. Figure 1 – SYN-ACK Flood Mitigation with High Performance AFM VE (Software-only) Next in Figure 2 you will see the same attack performed with the SmartNIC FPGA enabled; we pass the software-only limit of 2.4Gbps and increase the malicious traffic to 36Gbps with no effect on the Goodput with only 31.3% CPU usage. Figure 2 – SYN-ACK Flood Mitigation with BIG-IP AFM VE for SmartNICs Test 2 – UDP Flood Attack Below in Figure 3 you will see a UDP Flood Attack performed first with software-only (SmartNIC FPGA disabled); this shows an initial drop of our Goodput at 1.2Gbps of malicious traffic and approaching zero at only 2.4Gbps with 100% CPU usage. Figure 3 – UDP Flood Mitigation with High Performance BIG-IP VE AFM (Software-only) Next in Figure 4 you will see the same attack performed with the SmartNIC FPGA enabled; we pass the software-only limit of 2.4Gbps and increase the malicious traffic to 36Gbps with no effect on the Goodput with only 31.3% CPU usage. Figure 4 – UDP Flood Mitigation with BIG-IP AFM VE for SmartNICs Test 3 – ICMPv4 Flood Attack Below in Figure 5 you will see an ICMPv4 Flood Attack performed first with software-only (SmartNIC FPGA disabled); this shows an initial drop of our Goodput at 1.2Gbps of malicious traffic and approaching zero at only 2.4Gbps with 100% CPU usage. Figure 5 – ICMPv4 Flood Mitigation with High Performance BIG-IP AFM VE (Software-only) Next in Figure 6 you will see the same attack performed with the SmartNIC FPGA enabled; we pass the software-only limit of 2.4Gbps and increase the malicious traffic to 36Gbps with no effect on the Goodput with only 29.8% CPU usage. Figure 6 – ICMPv4 Flood Mitigation with BIG-IP AFM VE for SmartNICs Test 4 – Combined SYN ACK Flood, UDP Flood Attack and ICMPv4 Flood Attack Last, we are going to send a combined attack to show a complex mitigation scenario. We will be using the full 40G capability of the Ixia port to generate malicious traffic while still maintaining 3.5Gbps of Goodput from a second stream off another Ixia port. Below in Figure 7 you will see a complex multi-vector attack performed first with software-only (SmartNIC FPGA disabled); this shows an initial drop of our Goodput at 0.8 Gbps of malicious traffic and approaching zero at only 2.4Gbps with 100% CPU usage. Figure 7 – Combined attack mitigation with High Performance BIG-IP AFM VE (Software-only) In figure 8 you will see the same attack performed with the SmartNIC FPGA enabled; we pass the software-only limit of 2.4Gbps and increase the malicious traffic to 40Gbps with no effect on the 3.5Gbps of Goodput with only 27.4% CPU usage. Figure 8 – Combined attack mitigation with BIG-IP AFM VE for SmartNICs Wrap up From the results it is very clear that with the FPGA enabled on the Intel PAC N3000 SmartNIC, BIG-IP AFM VE can handle single or complex multi-vector attacks without affecting the CPU or normal traffic flowing through the system. With software-only mitigation the CPU must deal with every packet entering the system which quickly exhausts resources. With the assistance of the FPGA on the SmartNIC the malicious traffic is blocked before it ever reaches the CPU, preventing saturation. Our normal traffic or Goodput is allowed through without interruption; this is important because it reflects a customer application, web page, VOIP or other traffic which should not be affected during an attack otherwise the attacker has met their objective. In summary we have shown you that using a Common Off The Shelf (COTS) server in conjunction with a SmartNIC and BIG-IP VE delivers protection similar to our BIG-IP iSeries appliances in an augmented software VE (VNF) solution. Figure 9 – Magnitude of different DDoS attacks both solutions were capable of mitigating Additional Resources ·F5 Cloud Docs – BIG-IP VE for SmartNICs ·F5 & Intel Solution Brief - BIG-IP VE for SmartNICs
Get Back Speed and Agility of App Development in the Cloud with F5 Application Connector: Part 4 of 4
The challenge The speed and agility of the cloud is lost—dev must request environment changes from IT again. The solution Use the F5 Application Connector to automatically update the BIG-IP. In the last post, we showed how to get the stability and security of hosting BIG-IPs in the same data center as cloud servers (aka Cloud Interconnect). While this is a great solution, it re-created the problem of the dev team filing tickets with IT in order to move application servers to production. Enter the Application Connector from F5. With the Application Connector, any time you create or delete an application server in the cloud, the BIG-IPs automatically know about it, and update their configuration accordingly. And though the example below is talking about AWS, the application connector can be used in multiple clouds, helping prevent lock-in to any one cloud. The Application Connector is made up of two components: The Application Connector Proxy, which isdelivered as aDocker container that's deployed in a cloud environment The Application Connector Service Center, which isdeployed as an iAppsLX package on the BIG-IPs The Application Connector Proxy establishes an outbound connection to the BIG-IPs, using a secure TLS tunnel to encrypt traffic between the cloud app servers and BIG-IPs. In our example, we're showing the Application Connector in conjuction with Cloud Interconnect, but your BIG-IPs can be physical or virtual (aka BIG-IP VEs), andcan be on-premise or in a remote location. Auto-discovery of nodes As we said, after some initial configuration, the BIG-IPs are automatically updated with the latest nodes. In AWS, nodes are discovered and published automatically, and as of June, 2017, similar functionality is also planned for Azure and Google. With these functions, you eliminate the need for manual updates to the BIG-IP; developers no longer have to contact IT every time they add/remove cloud servers. In the following example, DevOps has chosen to disable two nodes in the Application Connector Proxy. This change is then reflected in the Application Connector Service Centeras well. The Application Connector Service Centerlets NetOps/SecOps access a full list of nodes and their statuses, no matter which cloud they are in. You can choose to disable automatic publishing to the BIG-IP, thus giving you the power to select which nodes you would like the BIG-IP to see. Scale out to other clouds You can now use multiple clouds and have BIG-IP automatically updated with all the nodes. Even if your IP address ranges overlap across multiple clouds, Application Connector handles it without issue. Security When you use the Application Connector, no public IP addresses need to be directly associated with the application servers. Because of this, the apps are hidden from clients and bad actors. Another security benefit it centralized encryption. Encryption keys no longer need to be stored in the cloud next to the application servers, but instead are stored on the BIG-IPs and can be shared across multiple clouds. Consistent Services & Policies When you're using the Application Connector, services configuration like load balancing, WAF, traffic manipulation, and authentication, as well as the policies that go with them, are all centrally managed on the BIG-IP by NetOps/SecOps/IT. Low Maintenance After the initial configuration of the Application Connector, no management or maintenance is necessary. It’s simpler than maintaining a VPN tunnel and it’s small—you don’t have to worry about it taking up too many resources. DevOps no longer has to request changes whenever they add/remove app servers. They can update the Application Connector proxy any time they choose. Get Started with Application Connector You probably want to get started, so here is a doc for you.https://support.f5.com/kb/en-us/products/app-connector/manuals/product/f5-application-connector-setup-config-1-1-0.html And when you’re ready, you can download the Application Connector from downloads.f5.com: https://downloads.f5.com/esd/product.jsp?sw=BIG-IP&pro=F5_Application_Connector And finally, in case you missed it, here are the previous posts: Successfully Deploy Your Application in the AWS Public Cloud: Part 1 of 4 Secure Your New AWS Application with an F5 Web Application Firewall: Part 2 of 4 Shed the Responsibility of WAF Management with F5 Cloud Interconnect: Part 3 of 4
