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 SmartNICsBIG-IQ Reporting for Subscriptions and ELA - How to Generate and Revoke Licenses for Isolated BIG-IP VE Instances
October 2018 Rev:D Scenario Some network designs may disallow BIG-IQ from reaching BIG-IP VE instances over the network due to network design, network partitioning, security reasons... you get the idea. BIG-IQ’s usual operation requires BIG-IQ to connect to port 443 on the BIG-IP VE’s management IP address. However, when the networks are partitioned in a way that does not allow the BIG-IQ to connect to the BIG-IP, a system outside of BIG-IQ is required to: POST an operation to generate a license GET the license from BIG-IQ Copy the license to the target BIG-IP VE instance And later, when the BIG-IP VE is no longer operational, revoking the license from BIG-IQ. This document explains how to manage licenses on BIG-IP VEs in this network design. Step 1: Gather your BIG-IP VE information for the licensing operation In order to successfully license BIG-IP VE, BIG-IQ needs specific information from the BIG-IP VE to be licensed. Log into the BIG-IP VE instance using “root” credentials Execute the following command: # get_dossier -b TBD -c Record the MAC address. You will also need to know the hypervisor your BIG-IP VE is running on. Example: [root@biq1-yabba-dabba-do:Active:Standalone] config # get_dossier -b d -c F5_BIOS_ID=Phoenix Technologies LTD 6.00 04/05/2016 VMware Virtual Platform None F5_MAC=00:50:56:bf:02:02 F5_PROBES=0x01000013 F5_SYS_UUID=543ff2ec-1c2f-844a-23d0-1e226b90678e F5_KEY=d F5_VERSION=BIG-IQ 6.0.1 0.0.469 Step 2: Requesting a License from BIG-IQ for your BIG-IP VE For this step, you need to have the following information: The name of the license pool in BIG-IQ you want to license the BIG-IP VE from The IP address of the BIG-IP VE device The MAC address (from step 1) The hypervisor type The offering name you wish to assign to the BIG-IP VE instance We’ll walk you through each one. The name of the pool comes from your BIG-IQ centralized management console. To get the name of the pool: Log into BIG-IQ Click the Devices tab On the left navigation, open LICENSE MANAGEMENT On the left navigation, click on Licenses Here you will see your license pools – the pool names are shown in the red rectangle in the example screen shot below. In this case, there are two pools “Engineering-Pool” and “IT-Pool” The next one we’ll discuss is the offering (service catalog) name, this will become important when we form the JSON request for the post. Click on your pool name, this will open the properties of the pool It looks as shown in the following diagram, highlighted by the red rectangle: The BIG-IQ API allows you to specify one or two “search keywords” to be used for matching the offering you wish to assign to your BIG-IP VE instance. For example, the first search keyword could be the feature level you’d like and the second the throughput, such as “LTM” and “10G”. Or, you can just specify the entire offering name as the only search keyword for an exact patch, such as “F5-BIG-MSP-LTM-5G-LIC-DEV”. Once you have the information available, form your JSON request, here is an example you can start with, we’ll take you through each part: { "licensePoolName": "Engineering-Pool", "command": "assign", "address": "192.0.2.3", "assignmentType": "UNREACHABLE", "macAddress": "FA:16:3E:1B:6D:34", "hypervisor": "vmware", "unitOfMeasure": "yearly", "skuKeyword1": "LTM", "skuKeyword2": "10G" } Elements Description licensePoolName Name of your pool as previously discussed in this article command The request to BIG-IQ to assign/allocate a license for this instance of BIG-IP VE address IP of your BIG-IQ (use the management IP) assignmentType must be 'unreachable': this instructs BIG-IQ to avoid trying to POST the license to the BIG-IP VE macAddress The MAC addressed obtained using method previously discussed hypervisor Underlying hypervisor hosting the BIG_IP VE you wish to license. Valid values are "aws","azure","gce","vmware","hyperv","kvm", and "xen". unitOfMeasure Must be "yearly" when you are using a license pool as part of the F5 subscription license or Enterprise Licensing Agreement (ELA) programs. skuKeyword1 Is the first search keyword skuKeyword2 Is the second search keyword The search keywords are optional; if none are specified, you’ll get the first license pool BIG-IQ matches on. If only one is specified, you’ll get the first license pool finds matching the search string. Here is an example with a single search keyword: { "licensePoolName": "Engineering-Pool", "command": "assign", "address": "192.0.2.3", "assignmentType": "UNREACHABLE", "macAddress": "FA:16:3E:1B:6D:34", "hypervisor": "vmware", "unitOfMeasure": "yearly", "skuKeyword1": "F5-BIG-MSP-LTM-3G-LIC-DEV" } Next, you need to POST your JSON body to BIG-IQ. You’ll need to enable basic authentication on BIG-IQ in order to use username and password authentication, the default is to use token- based authentication. To enable basic authentication, log into BIG-IQ console as “root” and enter “set-basic-auth on”. For the example below, we’ll use CURL – the JSON body is stored in a file named “getlicense.txt”. # curl -k -l -H'Accept:application/json' -H'Content-Type:application/json' -X POST -T getlicense.txt "https://admin:admin@10.255.65.16/mgmt/cm/device/tasks/licensing/pool/member-management" In this case, the BIG-IQ is at 10.255.65.16 and we’re using the admin login account on BIG-IQ with password “admin”. Your POST must go to “/mgmt/cm/device/tasks/licensing/pool/member- management” This results in the following return, if BIG-IQ has accepted your request: { "address": "192.0.2.3", "assignmentType": "UNREACHABLE", "command": "assign", "generation": 1, "hypervisor": "vmware", "id": "64100009-e20c-4add-9d3f-6cf4ed6fde31", "identityReferences": [ { "link": "https://localhost/mgmt/shared/authz/users/admin" } ], "kind": "cm:device:tasks:licensing:pool:member-management:devicelicensingassignmenttaskstate", "lastUpdateMicros": 1531492957761866, "licensePoolName": "Engineering-Pool", "macAddress": "FA:16:3E:1B:6D:34", "ownerMachineId": "9890115d-3e0b-4e7f-a9a0-ebb22c5747e4", "selfLink": "https://localhost/mgmt/cm/device/tasks/licensing/pool/member-management/64100009-e20c-4add-9d3f-6cf4ed6fde31", "skuKeyword1": "F5-BIG-MSP-LTM-3G-LIC-DEV", "status": "STARTED", "taskWorkerGeneration": 1, "unitOfMeasure": "yearly", "userReference": { "link": "https://localhost/mgmt/shared/authz/users/admin" } } IG-IQ is an asynchronous, task-based design, as such, the license is not returned when the POST completes, but rather, the acceptance of your request to BIG-IQ. To get the license, you must poll the “selfLink” (highlighted above). # curl -k -l -H'Accept:application/json' -H'Content-Type:application/json' -X GET "https://admin:admin@10.255.65.16/mgmt/cm/device/tasks/licensing/pool/member-management/64100009-e20c- 4add-9d3f-6cf4ed6fde31" If successful, this GET will return the license for the BIG-IP VE instance described in the JSON request in the “licenseText” field of the JSON body. For brevity, it is omitted. If there was an error encountered, the error text is returned in the “errorMessage” field of the JSON return body. Step 2: Place the License on BIG-IP VE To complete the licensing operation, you’ll need to extract the license from the “licenseText” element in the returned JSON. You’ll need to login to the BIG-IP VE instance as “root” and do the following: Place the licenseText on the BIG-IP VE instance at the following location and file name: /config/bigip.license Restart BIG-IP VE services: bigstart restart At this point, your BIG-IP VE is licensed. Step 3: Revoking and Returning the License to BIG-IQ When your BIG-IP VE instance is no longer needed, it is time to return the license to the pool. This is called a revoke operation. You’ll need to gather the following information: The name of the license pool on BIG-IQ The IP address of the BIG-IP VE The MAC address of the BIG-IP VE Please see the information in the “Step 1” section on how to obtain and gather this information. The JSON body is then formed, here is an example: { "licensePoolName": "load7afterfix", "command": "revoke", "address": "192.0.2.3", "assignmentType": "UNREACHABLE", "macAddress": "FA:16:3E:1B:6D:34" } The “command” must be “revoke” to return the license to the pool. Here is the example CURL command to the revoke, the JSON body is stored in a file called “revokelicense.txt”: # curl -k -l -H'Accept:application/json' -H'Content-Type:application/json' -X POST -T revokelicense.txt "https://admin:admin@10.255.65.16/mgmt/cm/device/tasks/licensing/pool/member- management" If successful, this request will return a JSON body similar to the following: { "address": "192.0.2.3", "assignmentType": "UNREACHABLE", "command": "revoke", "generation": 1, "id": "c7348b6a-6973-4372-9b66-f07c40bd0fd5", "identityReferences": [ { "link": "https://localhost/mgmt/shared/authz/users/admin" } ], "kind": "cm:device:tasks:licensing:pool:member-management:devicelicensingassignmenttaskstate", "lastUpdateMicros": 1531490803422235, "licensePoolName": "load7afterfix", "macAddress": "FA:16:3E:1B:6D:34", "ownerMachineId": "9890115d-3e0b-4e7f-a9a0-ebb22c5747e4", "selfLink":"https://locahost/mgmt/cm/device/tasks/licensing/pool/member-management/c7348b6a-6973-4321-8f66-f07e41bf0ed4", "status": "STARTED", "taskWorkerGeneration": 1, "userReference": { "link": "https://localhost/mgmt/shared/authz/users/admin" } } Similar to the licensing operation, you can poll the selfLink using a GET operation to monitor BIG-IQ’s progress in finishing up the revoke.
Shed the Responsibility of WAF Management with F5 and Cloud Interconnect: Part 3 of 4
The challenge Devs are trying to manage BIG-IP VEs and don’t want to The solution Move to a colo facility and use BIG-IP and Cloud Interconnect In the last post, we talked about keeping the BIG-IP VE auto-scaled WAF up-to-date. This is the configuration we’re currently running: The issue with this configuration is that the maintenance of BIG-IP VEs in AWS is falling on the development team. This, of course, is problematic for a few reasons: The dev team wants to spend their time developing The network engineers have lost control over the security and stability of the environment, and want it back Another issue is that there is latency in the VPN and it’s relatively unstable. This causes issues keeping our inventory up-to-date, which in turn causes loss of sales, as shoppers go to other sites for inferior lemonade flavors. Enter F5 and Cloud Interconnect. If you haven’t heard of it already, the basic idea is that your BIG-IPs can live in the same data centers as the cloud servers that your applications run on. Interconnect refers to a vendor-neutral facility where cloud and service providers meet. If we take our existing setup and move it to a colocation data center, it would look something like this: You can think of Cloud Interconnect as a simple Layer 2 switch that provides L2 connectivity between your cage and the various virtual networks you carved out in the cloud (which we’ll call "cloud provider networks" from now on). Now we can use BGP (Border Gateway Protocol) to route traffic between the on-premise inventory database and our application on the cloud provider network. Because it's using Layer 2 connectivity and routing protocols, traffic is not exposed to the internet and it's secure and protected. In addition, we now have WAN connectivity between our on-premise data center and the colo location. The WAN is far more stable than the VPN, ensuring good synchronization between the database and our app. The WAN connection allows direct connectivity to the cloud provider networks, allowing for things like direct RDP and other SSH client access. With Cloud Interconnect, you get: Low latency: Fiber optic links are directly connected to the cloud virtual network High security: Nothing travelling over the Internet, just as it was when it was in the data center Performance SLAs: The colo provider guarantees network performance Scale and choice: Multiple cloud providers are in the colo location With BIG-IP and Cloud Interconnect, you get all of that and more, including: Federation Single Sign-on SSL-I SSL-O Layer 7 traffic manipulation iRules Web Application Firewall Caching/Acceleration Data leakage prevention Intrusion prevention And the administration of BIG-IP now rests with the team that knows BIG-IP best—NetOps/SecOps/IT. Get Started with Cloud Interconnect For more detailed information about Cloud Interconnect, see: https://f5.com/products/cloud-computing/cloud-interconnection For details on how to configure BIG-IP in a Cloud Interconnect environment, see: https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-cloud-interconnect-generic-implementation-12-1-0.html And if you want to work with Equinix specifically, you can follow this guide: https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-cloud-interconnect-equinix-implementation-12-1-0.html What's Next? This all sounds great, right? Developers are relieved at the prospect of no longer messing with the WAF. NetOps/SecOps is happy that they get the central point of control that they want and expect. The downside to this solution is that you’re almost back to where you started. As a developer, whenever you spin up new environments, you have to contact IT to update the BIG-IPs. You don’t want to do this every time you have a change. The speed and agility you were promised by the cloud are somewhat slowed by this new setup. All is not lost! Come back for part 4 in this series to hear about another rockin F5 solution. And 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 4Get 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 is delivered as a Docker container that's deployed in a cloud environment The Application Connector Service Center, which is deployed 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), and can 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 Center as well. The Application Connector Service Center lets 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
