F5 Distributed Cloud (XC) API Security in Out-of-Band Mode using BIG-IP
Introduction There are API Security use cases, which need to be deployed in out-of-band mode. An example of such use cases is an existing very high-critical API deployment, which cannot risk a new inline point. Another example is API security visibility deployment with so many deployment points, which renders new inline/proxy points becoming too expensive. F5 Distributed Cloud (XC) API Security solution by default, requires an inline deployment to be the most effective solution. It needs a different approach if out-of-band deployment is required. Out-of-band mode in this context, means that F5 XC is deployed outside of the API traffic path flow. This implies that F5 XC is in monitoring mode by receiving the API traffic from mirroring devices or API logging systems. While in monitoring mode, it cannot provide any protection or enforcement without any integration with existing security solutions; inline or F5 XC deployment is changed to be inline mode. The best deployment position for F5 XC API Security remains the inline mode. Architecture F5 XC is designed to be an inline solution. It receives the API request traffic, analyzes it, and forwards it to the backend/origin servers. Receives the API response traffic, analyzes it, and forwards it to the clients. F5 XC is not designed to handle API logs or mirrored traffic. Hence, it requires a separate component to receive the API logs or mirrored traffic and translate them into API request and response traffic, and send them to F5 XC. The architecture below uses BIG-IP as the separate component carrying out the needed functions. The above architecture takes an example of Apigee API Gateway platform, which sends an API trace in XML format containing the request and response traffic of an API call passing through it to a BIG-IP VE (Virtual Edition) deployed in AWS. The BIG-IP VE is licensed with LTM and configured with 3 virtual servers and 3 iRules to carry out the required functions. Step (1): BIG-IP VE receives the uploaded API trace in XML format via vs_log_receiver VS attached with an iRule 01_incoming_xml_to_log_converter. The iRule parses the trace, captures the API request and response traffic, create+save the simulated API response in the cache, create a unique link ID, create a simulated API request, and send the simulated API request to vs_http_to_https using Sideband iRule. Step (2): The vs_http_to_https VS receives the simulated API request traffic and forwards it as an HTTPS request to F5 Distributed Cloud (XC). F5 XC receives the simulated API request and forwards it back to the BIG-IP VE. Step (3): The BIG-IP VE receives the simulated API request from F5 XC, finds the corresponding API response from the cache using the unique link ID inside the request header, and sends the simulated API response to F5 XC. F5 XC then forwards the simulated API response to the BIG-IP VE completing the traffic flow cycle. With those steps, they mimic the situation where F5 XC receives normal API request and response traffic. The difference here is that the client and the server are the simulated one, not the real client and server. F5 XC processes the API traffic according to the API security configuration in a more passive role instead of an active role. The iRules are available at this link. Benefits The benefits of this architecture are: Deploy F5 XC API Security in out-of-band mode without disturbing/changing the existing API traffic flow, which makes the deployment faster and less intrusive. Get the API Discovery from F5 XC to discover API traffic endpoints and provide the analysis. Verify the API Authentication in each API request traffic. Conduct API Security posture management. Display the API security visibility in centralized manner without changing the API environment. Create the right justification cases for the higher-management approval to deploy the F5 XC API Security solution in inline mode. Getfull support for the solution from F5 ecosystem because the solution uses standard F5 solution components. Scaling Ifsignificant capacity is required to process the mirrored API traffic, it is possible to deploy multiple BIG-IP VE instances and load-balance them using AWS Network Load Balancer. A specific iRule to synchronize the response cache entries between BIG-IP VE instances needs to be developed. I leave this scope for further details on implementation. Let me know your thoughts by leaving a comment or two below 🙂
