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
BIG-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.
BIG-IP VE - qemu on an Apple Silicon Macbook
Hey all, I was wondering if anyone has managed to spin up a BIG-IP VE on an Apple Silicon Macbook using qemu? I've been using this guide: https://clouddocs.f5.com/cloud/public/v1/kvm/kvm_setup.html As a reference point, but this is obviously written from the persepctive of a native x86 chipset on the host. I've tried playing around with what I believe are the relevant settings, but the guest just crashes virt-manager every time I try to launch it. Don't suppose anyone has been through this pain and come out the other side successfully and could lend a hand? Thanks!Creating logs from a Virtual Server
Extremely new here , so forgive me, and I'm also trying to improve an existing production system. We have an Active Directory infrustructure and we have three critical services where we actually authenticate to the applicable 3rd party, and in turn they access our network through the F5 to authenticate to one of our three load balanced domain controllers. initially, we thought it would just be a matter of turning on our Active Directory Audit policies and dump the logs to our graylog server and we'd be able to monitor success and failure security logs. This has proven to be insufficient because you can't really get good authentication information from AD Domain controllers directly about specific server logins because that type of audit is best performed at the server level receiving the login requests. The other problem is these 3rd party servers are possesed by the 3rd partys. We had a theory that since the 3rd party servers use a url that points to the F5, we should be able to get the type of security logs we want from the virtual server that passes off the request to the DC's. What we like to know is how do we configure this virtual server to first create its security logs and then to dump them to our greylog server. Thanks in advance for any information.
BIG IP VM - Interface unintialized
Hi Team, I have installed Big IP VM edition in Esxi Server, after instial setup. We found interface 1.1, 1.2, etc are uninitialized state even after associating Interal, external and HA interface to vlan in Virtual machine. Still it show as unintialized only. Please share your inputs.
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'ssecure 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 youspin up new environments, youhave to contact IT to update the BIG-IPs. Youdon’t want to do this every time youhave a change. The speed and agility you werepromised 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 rockinF5 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 4
