F5 SSL Orchestrator and FireEye NX Integrated Solution
Blind Spots It is nearly impossible to defend against an attack you cannot see. Increased adoption of TLS/SSL is helping organizations secure IP communications between users and web services through encryption. But increased use of encryption also creates challenges for devices in the security stack, such as FireEye NX, that cannot inspect encrypted traffic for hidden threats. When encrypted communications cannot be seen as clear text, they are passed through without inspection and become security blind spots. Clearly this creates serious risks for businesses as they face the very real concern that attackers could hide malware inside encrypted traffic. Fortunately, solving this problem is simply a matter of decrypting SSL traffic and sending the unencrypted data to additional security devices for inspection. In fact, some security devices today do support SSL decryption natively—but at a cost: Decryption and re-encryption, especially of 2048-bit certificates, demands a lot of computing resources and can tremendously degrade the performance of these devices. An integrated solution from F5 Networks and FireEye solves this challenge by centralizing SSL inspection across the security stack. This joint solution utilizes a dedicated F5 SSL Orchestrator to decrypt and route traffic before inspection by FireEye NX or other security devices, thereby greatly expanding your ability to prevent hidden threats and block zero-day exploits. F5 Full Proxy Architecture F5 SSL Orchestrator is the core of F5’s SSL/TLS visibility and orchestration solution. When deployed on the wire between an intranet and the Internet, as shown in Figure below, F5 SSL Orchestrator installs a decrypt /clear-text zone between the client and web server, creating an aggregation visibility point for FireEye NX to inspect the traffic. F5 full proxy architecture establishing the inspection zone. When the client initiates an HTTPS connection to the web server, the F5 SSL Orchestrator intercepts and decrypts the client-encrypted traffic and steers it to a pool of FireEye NX devices for inspection. After inspection, the F5 SSL Orchestrator re-encrypts the same traffic before sending it to the web server. The return HTTPS response from the web server to the client is likewise intercepted and decrypted for inspection before being sent to the client. Solution Deployment F5 SSL Orchestrator intercepts both outbound and inbound traffic. Other security services like DLP (using ICAP), IPS, and next-generation firewalls can also be deployed alongside FireEye NX when configured in a service chain within the decrypt zone. The F5 SSLO FireEye NX solution with service chain I. Bill of Materials F5 SSL Orchestrator 5.1 Optional functional add-ons include URL filtering subscription, IP Intelligence subscription, network hardware security module (HSM), F5 Secure Web Gateway (SWG) Services and F5 Access Manager (APM). FireEye NX appliance II. Pre-requisites F5 SSL Orchestrator is licensed and set up with internal and external VLANs and Self-IP addresses. An SSL certificate—preferably a subordinate certificate authority (CA)—and private key are imported into F5 SSL Orchestrator. The CA certificate chain with root certificate is imported into the client browser. FireEye NX is setup with physical connectivity to F5 SSL Orchestrator. III. Configure FireEye Operation Mode Login to FireEye web user interface, navigate to Settings, and select Inline operation mode. FireEye supports both Inline and TAP mode of operation IV. Deploy F5 SSL Orchestrator using Guided Configuration SSL Orchestrator version 5.1 introduced Guided Configuration, a workflow-based architecture that provides intuitive, re-entrant configuration steps and presents a completely new and streamlined user experience. To deploy the SSL Orchestrator application, log into the F5 system. On the F5 Web UI Main menu, navigate to SSL Orchestrator > Configuration and follow the guided configuration steps. Step 1: Topology Properties SSL Orchestrator creates discreet configurations based on the selected topology. Selecting explicit forward proxy topology (as shown in the example) will ultimately create an explicit proxy listener. Step 2: SSL Properties Select the previously imported subordinate CA certificate (see Prerequisites, above) to sign and issue certificates to the end-host for client-requested HTTPS websites that are intercepted. Step 3: Create the FireEye Inline Service The services list section defines the security services that interact with SSL Orchestrator. The guided configuration includes a services catalog that contains common product integrations. In the service catalog, double click on the FireEye Inline service and configure the service settings: service name, VLAN pair and port remap. The ‘From VLAN’ and ‘To VLAN’ pairs (inward and outward VLANs) and the associated interfaces define the network connectivity from SSL Orchestrator to the inline security device. For the FireEye NX device to recognize that the steered traffic has been decrypted, it needs to be sent on a non-443 TCP port. Using the service catalog, create additional security services as required, before proceeding to the next step. Step 4: Service Chains Create a service chain, which is an arbitrarily ordered lists of security devices. The service chain determines which services receive traffic. Step 5: Security Policy SSL Orchestrator’s guided configuration presents an intuitive rule-based, drag-and-drop user interface for the definition of security policies. In the background, SSL Orchestrator maintains these security policies as visual per-request policies. If traffic processing is required that exceeds the capabilities of the rule-based user interface, the underlying per-request policy can be managed directly. Use this section to create custom rules as required. Step 6: Intercept Rule Interception rules are based on the selected topology and define the listeners (analogous to BIG-IP Local Traffic Manager virtual servers) that accept and process different types of traffic, such as TCP, UDP, or other. The resulting BIG-IP LTM virtual servers will bind the SSL settings, VLANs, IPs, and security policies created in the topology workflow. Step 7: Egress Settings The egress settings section defines topology-specific egress characteristics like NAT and outbound route. Step 8: Summary The configuration summary page presents an expandable list of all the workflow-configured objects. Review the setting and click the Deploy button to deploy SSL Orchestrator. SSL Orchestrator will be successfully deployed on the F5 system. V. Verification Navigate to http://www.eicar.org/ and download a malware test file via HTTP and HTTPS links from the client. Login to FireEye NX Web UI and navigate to Alerts to view the malware alert. Conclusion The joint solution from F5 Networks and FireEye brings together the best of application delivery and advanced content security to help you identify and stop even the most sophisticated attacks, whether in the data center or at the perimeter of your network. Together, we help you accelerate business growth while decreasing the risk of security breaches. Learn more: Product page: F5 SSL Orchestrator White paper: Beyond Advanced Threat ProtectionAdvanced Threat Mitigations via SSL Intercept
SSL offload has been around for quite some time. But this technology was primarily developed for the web farm audience, offloading SSL traffic from the application servers and putting the load on application delivery controllers like F5’s BIG-IP. With the push for SSL Everywhere in the last few years, the need for corporations to have visibility to the traffic from their internal clients (could be employees or internal application services reaching out to external services via APIs) to external services that are encrypted. Without the ability to decrypt and inspect that traffic before it leaves the perimeter and as it returns from the outer reaches of the internet, corporations are exposed to significant risks such as information leakage and loss, general malware at best but botnet command and control communication channels at worst, but corporations are also exposed to the softer productivity risks like employee time management while on the clock. This is where inspection via SSL intercept comes in. We partner with FireEye to offer combined best in class performance and visibility. Peter also sat down with Sam Ware from FireEye at RSA last year to discuss the solutions and partnership. But enough of the marketing…how does it work? In a traditional reverse proxy scenario, the SSL offload requires that you have the private key and certificate in order to decrypt and inspect. But with the forward proxy scenario, well, we don’t have the private keys to all the sites on the internet. So another solution is necessary. I’ve queued this episode of Whiteboard Wednesday at the point where the process of how to configure and insert the BIG-IP into the trust relationship between client and server is broken down. Once the air gap is in place with the SSL intercept configuration, this unencrypted traffic can be diverted through inspection devices like FireEye to monitor and act on any disallowed or malicious traffic. There are a couple ways this can be deployed. Layered SSL Intercept Solution In this solution, there is a front-side and a back-side BIG-IP handling the encryption with clients and servers, respectively. In the middle, interesting traffic is unencrypted and passed through the inspect points.The great thing about this solution is the initial inspection point is on the BIG-IP, so if there are some destinations that require no inspection, those can be immediately re-encrypted and sent on without sending through the external inspection point. One-Armed SSL Intercept Solution In this solution, there is only one BIG-IP, and so the front-side and back-side functions of the air gap are combined into the single device. Functionally they are equivalent, just less hardware in the picture. Clone Solution In the event the enforcement angle of the solution is not desired, the traffic can be cloned off to the FireEye for monitoring and alerting, but still be passed along uninhibited by the infrastructure. As simple as the drawings make it all look, the configuration is fairly complex. Thankfully there is a fantastic iApp supported by F5 to assist in the deployment. It is linked below in the resources. Resources FireEye Solutions on F5.com Air Gap Egress Inspection with SSL Intercept iApp Template Air Gap Deployment Guide SSL Everywhere Reference Architecture - Best PracticesOrchestrated Infrastructure Security - Change at the Speed of Business - FireEye NX
Editor's Note:The F5 Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latesthere Introduction This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability, Central Management with BIG-IQ, Application Visibility with Beacon and the protection of critical assets using F5 Advanced WAF, Protocol Inspection (IPS) with AFM as well as leading Security Solutions like the FireEye.It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working. If you need help setting up SSL Orchestrator for the first time, refer to the Dev/Central article series on Implementing SSL Orchestrator here or the CloudDocs Deployment Guide here. This article focuses on using SSL Orchestrator as a tool to assist with simplifying Change Management processes, procedures and shortening the duration of the entire process. Configuration files of FireEye can be downloaded fromherefrom GitLab. Please forgive me for using SSL and TLS interchangeably in this article. This article is divided into the following high level sections: Create a new Topology to perform testing Monitor FireEye statistics – change the weight ratio – check FireEye stats again Remove a single FireEye device from the Service Perform maintenance on the FireEye device Add the FireEye device to the new Topology Test functionality with a single client Add the FireEye device back to the original Topology Test functionality again Repeat to perform maintenance on the other FireEye device Create a new Topology to perform testing A new Topology will be used to safely test the Service after maintenance is performed.The Topology should be similar to the one used for production traffic.This Topology can be re-used in the future. From the BIG-IP Configuration Utility select SSL Orchestrator > Configuration.Click Add under Topologies. Scroll to the bottom of the next screen and click Next. Give it a name, Topology_Staging in this example. Select L2 Inbound as the Topology type then click Save & Next. For the SSL Configurations you can leave the default settings.Click Save & Next at the bottom. Click Save & Next at the bottom of the Services List. Click the Add button under Services Chain List.A new Service Chain is needed so we can remove Fireeye1 from the Production Service and add it here. Give the Service Chain a name, Staging_Chain in this example.Click Save at the bottom. Note: The Service will be added to this Service Chain later. Click Save & Next. Click the Add button on the right to add a new rule. For Conditions select Client IP Subnet Match. Enter the Client IP and mask, 10.1.11.52/32 in this example.Click New to add the IP/Subnet. Set the SSL Proxy Action to Intercept. Set the Service Chain to the one created previously. Click OK. Note: This rule is written so that a single client computer (10.1.11.52) will match and can be used for testing. Select Save & Next at the bottom. For the Interception Rule set the Source Address to 10.1.11.52/32.Set the Destination Address/Mask to 10.4.11.0/24.Set the port to 443. Select the VLAN for your Ingress Network and move it to Selected. Set the L7 Profile to Common/http. Click Save & Next. For Log Settings, scroll to the bottom and select Save & Next. Click Deploy. Monitor FireEye statistics – change the weight ratio – check FireEye statistics again Check the statistics on the FireEye we will be performing maintenance on.It’s “Fireeye1” in this example. From the FireEye Dashboard scroll down to the Monitored Traffic widget. Monitored Traffic can be filtered by Day, Week or Month.In this case it’s set to Day.Fireeye1 appears to be completely healthy. Change the Weight Ratio Back to the SSL Orchestrator Configuration Utility.Click SSL Orchestrator > Configuration > Services > then the Service name, ssloS_Fireeye in this example. Click the pencil icon to edit the Service. Click the pencil icon to edit the Network Configuration for Fireeye2. Set the ratio to 65535 and click Done. Click Save & Next at the bottom. Click OK if presented with the following warning. Click Deploy. Click OK when presented with the Success message. Check FireEye Statistics Again From the FireEye Dashboard scroll down to the Monitored Traffic widget.It should look like the image below, with the number of sessions tapering off until there is zero. Remove a single FireEye device from the Service Back to the SSL Orchestrator Configuration Utility.Click SSL Orchestrator > Configuration > Services > then the Service name, ssloS_Fireeye in this example. Click the pencil icon to edit the Service. Under Network Configuration, delete Fireeye1 Click Save & Next at the bottom. Click OK if presented with the following warning. Click Deploy. Click OK when presented with the Success message. Perform maintenance on the FireEye device At this point Fireeye1 has been removed from the Production Topology and is no longer handling production traffic.Fireeye2 is now handling all the production traffic. We can now perform a variety of maintenance tasks on Fireeye1 without disrupting production traffic.When done with the task(s) we can then safely test/verify the health of Fireeye1 prior to moving it back into production. Some examples of maintenance tasks: ·Perform a software upgrade to a newer version. ·Make policy changes and verify they work as expected. ·Physically move the device. ·Replace a hard drive, fan, and/or power supply. Add the FireEye device to the new Topology This will allow us to test its functionality with a single client computer, prior to moving it back to production. From the SSL Orchestrator Configuration Utility click SSL Orchestrator > Configuration > Topologies > sslo_Topology_Staging. Click the pencil icon on the right to edit the Service. Click Add Service. Select the FireEye NX Inline Layer 2 Service and click Add. Give it a name or leave the default.Click Add under Network Configuration. Set the FROM and TO VLANS to the following and click Done. Click Save at the bottom. Click the Service Chain icon. Click the Staging_Chain. Move the FEYE-test Service from Available to Selected and click Save. Click OK. Click Deploy. Click OK. Test functionality with a single client We created a policy with source IP = 10.1.11.52 to use the new FireEye Service that we just performed maintenance on. Go to that client computer and verify that everything is still working as expected. As you can see this is the test client with IP 10.1.11.52. The page still loads for one of the web servers. You can view the Certificate and see that it is not the same as the Production Certificate. To ensure that everything is working as expected you can view the FireEye Dashboard again and scroll down to the Monitored Traffic widget.You should see something like the image below, where Monitored Traffic is increasing. Add the FireEye device back to the original Topology From the SSL Orchestrator GUI select SSL Orchestrator > Configuration > Service Chains. Select the Staging_Chain. Select ssloS_FEYE-test on the right and click the left arrow to remove it from Selected Click Deploy when done. Click OK. Click OK to the Success message. From the SSL Orchestrator Guided Configuration select SSL Orchestrator > Configuration > Services. Select the FEYE-test Service and click Delete. Click OK to the Warning. When that is done click the ssloS_Fireeye Service. Click the Pencil icon to edit the Service. Under Network Configuration click Add. Set the Ratio to the same value as Fireeye2, 65535 in this example.Set the From and To VLAN the following and click Done. Click Save & Next at the bottom. Click OK. Click Deploy. Click OK. Test functionality again To ensure that everything is working as expected you can view the FireEye Dashboard again and scroll down to the Monitored Traffic widget.You should see something like the image below, where Monitored Traffic increases.Fireeye1 appears to be completely healthy. Repeat these steps to perform maintenance on the other FireEye device (not covered in this guide) ·Remove a single FireEye device from the Service ·Perform maintenance on the FireEye device ·Add the FireEye device to the new Topology ·Test functionality with a single client ·Add FireEye device back to the original Topology ·Test functionality again Congratulations, you're done!Lightboard Lessons: FireEye Ingress Solutions with BIG-IP
Most websites utilize https:// encryption to secure traffic to/from their webservers. This is a blessing and a curse...it's a blessing because the traffic is unreadable in its encrypted form. It's a curse because, well, the traffic is unreadable in its encrypted form. How will anyone know to block certain traffic (i.e. malware, etc) if its unreadable? The answer is...you can't. In order to inspect this encrypted traffic, you can implement a BIG-IP solution that decrypts the traffic and then sends it to a separate FireEye cluster of servers to inspect and take action on the traffic. In this Lightboard Lesson video, John explains the solution of using a BIG-IP and FireEye device to inspect traffic and keep your webservers safe. Enjoy! Related Resources: F5 and FireEye Integrated Solutions Beyond Advanced Threat Protection Lightboard Lessons: Air Gap ArchitecturesLightboard Lessons: FireEye Egress Solutions with BIG-IP
We all want to protect our web applications from malicious traffic coming in from external sources, but we also want to protect against internal users as well. In a previous Lightboard Lesson, we talked about how FireEye blocks malicious traffic from entering your network. In this Lightboard Lesson video, John explains how FireEye and F5 work together to block malicious traffic from internal users as well. Enjoy! Related Resources: F5 and FireEye Integrated Solutions Beyond Advanced Threat Protection Lightboard Lessons: FireEye Ingress Solutions with BIG-IP
