F5 Essential App Protect and AWS CloudFront - Better Together.
What is the function of any application? In the simplest of terms an application must provide a value to the user. While the definition of "value" may differ, it is universally true that the user experience is critical to the perception of value.The user experience, loyalty, and your brand are predicated on the fact that the application be useable. So, what does it mean to be useable?It means that the application must be available, it must be secure, and it must be fast. Recently we announced that F5 Essential App Protect (EAP) would be integrating with AWS CloudFront to provide both security and Content Delivery Network (CDN) services for customers. This is an evolutionary step for F5 in our transition to a software and services company. Now, from the same portal where customers deploy applications and employ F5 Essential App Protect for security, in just a couple of clicks or a single API call, they can also access a global CDN leveraging AWS CloudFront. Let's review why EAP is cool, why AWS CloudFront is interesting, and take a look at the steps to enable the feature. F5 EAP is a high value, low time investment, WAF solution allowing customers to leverage F5's leading WAF Engine as a service using an intuitive interface.Customers can leverage EAP to meet security needs while incurring minimal operational overhead and pay based on traffic patterns. F5 EAP offers customers access to the sensitive data masking, security signatures, new threat campaigns, and IP reputation services that we have developed over nearly 20 years and continue to evolve. By subscribing to EAP customers can increase the efficacy of their SOC without increasing headcount or adding to operational burdens while gaining access to security protections that go far beyond what other services can provide. Below, the overview dashboard of an application protected by F5 Essential App Protect AWS CloudFront is a global CDN that allows users to deploy cacheable content across the globe in over 200 edge points of presence (PoP). AWS CloudFront is based on AWS best in class technology, expansive know how on building cloud services and leverages the AWS global network between the PoP closest to your customers and your Essential App Protect deployment (built on AWS). AWS CloudFront becomes the entry point for all traffic into the application, caching the content that is cacheable and passing the dynamic or non-cacheable portions to the origin. So why would you want to enable a CDN for your application? The simple answer is user experience. The better performing an application is the more likely it is that it will be used. By leveraging a CDN your content can be placed closer to your users and cached. This decreases page load time, something that always makes users happy. A more complete answer includes attributes such as reducing your WAF costs by not having to process cacheable content for each request and removing that traffic load from your origin application systems. The use of a CDN provides benefits for both the content provider and the content consumer. In the graph below you can clearly see the impact of enabling caching had on the origin servers in one of our test applications. So what does the high level architecture look like? Below you can see that DNS traffic is processed by AWS Route 53, directing the traffic to one of the AWS CloudFront edge locations. Traffic that has passed basic validations such as the host header matches the certificate name is either served from the edge cache or directed to F5 EAP for further processing. Traffic that passes WAF validation by F5 EAP is then passed to your origin application no matter if it is in AWS or located in your data center. For applications that reside in AWS all of this network traffic uses the AWS global network between the AWS CloudFront edge, F5 EAP and your app. For applications that reside in a non-AWS based location you can still use F5 EAP with the AWS CloudFront Integration (no AWS account required on your part) noting the slight difference in the data path as shown in the architecture below. Enabling your CDN Assuming that you already have an application deployed and protected by F5 EAP let's take a look at updating and adding AWS CloudFront functionality. From our F5 EAP portal we can see that our application has an FQDN of na2-auction.cloudservicesdemo.net. This application is already deployed and the DNS flow is as follows, a user's computer performs a DNS look up for na2-auction.cloudservicesdemo.net and it is a CNAME for your enabled F5 EAP dataplane locations. First let's enable caching on our Application which will enable AWS CloudFront. Next we need to configure the EdgeTiers (which geographies) that we would like to leverage to place the content closer to the users. Now we should filter any cookies or headers that we would like forwarded and enable compression. Since our application was already deployed on F5 EAP we will use the same CNAME and direct our traffic into AWS CloudFront. After a brief period our F5 Essential App Protect deployment will now have an integrated AWS CloudFront distribution and you will start to see caching metrics as traffic traverses the data path as described in the architecture. What if you need to invalidate some content? Well that is just as easy as enabling the feature! First you need to create the invalidation (purge), and when you click save the process will run deleting the items that match from the cache based on your EdgeTier selections. What about support for AWS CloudFront? That is on F5. We will deploy the AWS CloudFront distribution for you and it is part of our service that you subscribed to. If you experience issues you contact us at F5. We will diagnose and, if necessary, work with AWS to resolve the issue. No more having to coordinate multiple vendors for your application and no more getting stuck in the middle of two vendors not agreeing to a resolution. That's it! You have enabled an integrated security and CDN based on F5 EAP and AWS CloudFront in a few clicks from a single user interface! F5 Essential App Protect with our integrated AWS CloudFront offering can handle the the full lifecycle of your application security and edge performance optimization needs. Take it for a test drive from the F5 CloudServices portal.Adopting SRE practices with F5: Layered Security Policy for North-South Traffic
In an organization with enough maturity in cybersecurity and modern application architectures, there are two different cybersecurity teams that operate the more advanced security policies for the company. NetSecOps and DevSecOps are the two cybersecurity teams in an organization, and they typically have different security requirements. NetSecOps requires a ‘Standardized Application Security Policy'. They aim to block common attacks to the production network with a high level of confidence, resulting in a ‘low-false positive rate,’ at the network level. The OWASP Top 10 threats is a good example here. Moreover, the responsibility of NetSecOps is not limited to stopping basic attack types like the OWASP Top 10, but it also covers more advanced and complicated application-based attacks such as ‘Bot Attacks,’ ‘Fraud Attacks,’ and ‘DDoS Attacks.’ However, when it comes to the ‘Modern-App environment,’ it is not easy for the NetSecOps team to understand the details of the application traffic flow inside the Kubernetes or OpenShift cluster. For this reason, as far as modern applications are concerned, the security policies of NetSecOps often focus more on compliance and audit purposes. However, DevSecOps wants the application-specific security policies for different types of applications to be operating inside their Kubernetes or OpenShift clusters. This is possible since DevSecOps understands how their applications work and they want to apply more optimized security policies for their backend applications. This is why it is sometimes difficult to achieve both security team’s goals with a single security solution. This is why the enterprise needs to deploy two different WAFs to meet the different requirements from both NetSecOps and DevSecOps. This article will cover how two different security teams can achieve their goals with two separate WAF (Web Application Firewall) deployments in the network - F5 Advanced WAF for NetSecOps and NGINX App Protect for DevSecOps. Solution Overview The solution includes two F5 components – F5 Advanced WAF and NGINX App Protect. From a technological point of view, NGINX App Protectutilizes s a subset of F5 Advanced WAF functionality, meaning that their underlying technologies are the same. Each of those WAF components can run with different security policies in order to achieve different goals. In F5 Advanced WAF, NetSecOps can apply the WAF policy for the ‘coarse-grained model’ of security, while DevSecOps adopts the ‘fine-grained model’ with the NAP. In other words, this means that F5 Advanced WAF can be configured with a ‘Negative Policy,’ and NGINX App Protect can be configured with a ‘Positive Policy.’ In our use-case, we assumed that NetSecOps wants to block the OWASP Top 10 threats while DevSecOps has a different 'file accessing' policy for each backend application. The brief architecture is depicted below. Combining F5 Advanced WAF and NGINX App Protect enables layered application security policies to prevent the most complicated and advanced application-based attacks efficiently. This architecture utilizes the following workflow: 1.The F5 Advanced WAF blocks the most commonly used attack types including ‘Command Injection,’ ‘SQL Injection,’ ‘Cross-Site Scripting,’ and ‘Server Side Request Forgery’ attacks. 2.When the attacker tries to access the different files in each application, NGINX App Protect manually specifies the file types that are allowed (or disallowed) in traffic based on the security policies configured by the DevSecOps team. 3.All alert details from F5 Advanced WAF and NGINX App Protect are sent to the ‘Elasticsearch’ for central monitoring purposes. Each of the above workflows will be discussed in the following sections. ·This blog doesn’t include all the required steps to reproduce the use-case in the environment. Please refer to this link for all the required configuration steps. NGINX App Protect provides ‘Application-Specific’ policies NGINX App Protect can provide security protection and controls at the microservice level inside the Kubernetes or OpenShift cluster. The NGINX App Protect can be deployed in the OpenShift cluster as a container image. The NGINX App Protect policy configuration uses the declarative format built on a pre-defined base template. The policy uses the JSON format to represent the policy details. This file can be edited to apply a unique security policy to the NGINX App Protect instance. Once the policy is created, the policy can be attached to the 'nginx.conf' file by referencing the policy file. In this example, we used the ‘nginx_sre.conf’ file as the main configuration file for NGINX and the ‘NginxSRELabPolicy.json’ file represents the NGINX App Protect policy. NginxSRELabPolicy.json: | { "policy": { "name": "SRE_DVWA01_POLICY", "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" }, "applicationLanguage": "utf-8", "enforcementMode": "blocking", "response-pages": [ { "responseContent": "<html><head><title>SRE DevSecOps - DVWA01 - Blocking Page</title></head><body><font color=green size=10>NGINX App Protect Blocking Page - DVWA01 Server</font><br><br>Please consult with your administrator.<br><br>Your support ID is: <%TS.request.ID()%><br><br><a href='javascript:history.back();'>[Go Back]</a></body></html>", "responseHeader": "HTTP/1.1 302 OK\\r\\nCache-Control: no-cache\\r\\nPragma: no-cache\\r\\nConnection: close", "responseActionType": "custom", "responsePageType": "default" } ], "blocking-settings": { "violations": [ { "name": "VIOL_FILETYPE", "alarm": true, "block": true } ] }, "filetypes": [ { "name": "*", "type": "wildcard", "allowed": true, "checkPostDataLength": false, "postDataLength": 4096, "checkRequestLength": false, "requestLength": 8192, "checkUrlLength": true, "urlLength": 2048, "checkQueryStringLength": true, "queryStringLength": 2048, "responseCheck": false }, { "name": "pdf", "allowed": false } ] } } --- The above configuration file shows the NAP policy of application #01, where the DevSecOps team wants to disallow file access to the ‘PDF’ file format. For application #02, the NAP policy is configured to reject the access to the ‘JPG’ file. And the ‘remote logging’ configuration needs to be applied on the NGINX to export the NGINX App Protect's alert details. The below configuration shows how we exported the NGINX App Protect logging details to an external device, Elasticsearch. server { listen 8080; server_name dvwa02-http; proxy_http_version 1.1; real_ip_header X-Forwarded-For; set_real_ip_from 0.0.0.0/0; app_protect_enable on; app_protect_security_log_enable on; app_protect_policy_file "/etc/nginx/NginxSRELabPolicy.json"; app_protect_security_log "/etc/app_protect/conf/log_default.json" syslog:server=your_elk_ip_here; location / { client_max_body_size 0; default_type text/html; proxy_pass http://dvwa02; proxy_set_header Host $host; } Preventing OWASP Top 10 threats in F5 Advanced WAF F5 Advanced WAF is the next-generation WAF solution designed to prevent advanced application-based attacks. It supports 1000+ proven application-level signatures, custom signatures, Machine-Learning based DDoS prevention, Intelligence-based attack mitigation, and Behavioural-based WAF functions. But in this use-case, we focused on the prevention of the OWASP Top 10 attacks, which is only a small part of the F% Advanced WAF attack overall coverage. The important point here is how we can configure the F5 Advanced WAF to apply the WAF's efficient ‘Negative Security’ model. In order to configure the correct F5 Advanced WAF policy, one should follow the procedures below: 1. Go to 'Security' -> 'Application Security' -> 'Security Policies' -> 'Create' 2. Click the security policy that was just created (SRE_DEVSEC_01) ·Click the 'View Learning and Blocking Settings' under the 'Enforcement Mode' menu 3. Expand 'Attack Signatures' and Click 'Change' menu 4. Apply the check box. ·Click 'Close' ->click 'Save' -> click 'Apply Policy' ·Apply the policy to the virtual server. (Please make sure that we're on OCP partition.) 5. 'Local Traffic' -> 'Virtual Servers' -> 'devsecops_http_vs' -> Security -> Policies Please note that the ‘virtual server’ configuration is required in the BIG-IP before proceeding to this step. Configuring custom blocking page for F5 Advanced WAF 1.Click the security policy that was created (SRE_DEVSEC_01) 2.Go to 'Response and Blocking page' -> 'Blocking page default' -> 'Custom response' -> 'Response Body' <html><head><title>SRE DevSecOps Blocking Page</title></head><body><font color=red size=12>F5 Advanced WAF Blocking Page</font><br><br>Please consult with your administrator.<br><br>Your support ID is: <%TS.request.ID()%><br><br><a href='javascript:history.back();'>[Go Back]</a></body></html> Simulating the Attack The following steps show how to simulate the application-based attacks and to see how F5 Advanced WAF and NGINX App Protect can protect the applications efficiently. Preventing OWASP Top 10 Attacks - NetSecOps First, log in to the application through the GUI and go to the ‘Command Injection’ menu. And type the command ‘8.8.8.8 | cat /etc/passwd’ and click the ‘Submit’ button. If F5 Advanced WAF works correctly, you should be able to see the below ‘blocking page’. ·You can find the instructions from the Github link here how to simulate other attack types – SQL Injection, SSRF and XSS. Restrict file accessing based on the application types - DevSecOps 1.Access to application 01 on the browser with URL -> "http://your_app_domain.com/hackable/uploads/" 2.When the ‘PDF’ file is clicked on in this directory, the following blocking screen should be shown. Summary In modern application architectures, security concerns are becoming more serious. WAF is the major security solution available to enterprise applications. The security policy of the WAF has to protect backend applications correctly, but at the same time, it must also ensure legitimate user traffic access to the backend resources without creating issues. This sounds straightforward, but it is not easy to configure the right security policies to achieve both goals simultaneously. When it comes to modern application architectures, it is even more difficult to achieve this goal. Since traditional security teams lack understanding about the application flow inside a Kubernetes or OpenShift environment, it is challenging to apply the required security policies in the WAF to protect the microservices. Due to the nature of their microservices, different applications spin up and down frequently, and security requirements are also changed on a regular basis. The cybersecurity team needs to have a solution that can fit these unique requirements. For NetSecOps, they would require a solution that can have enterprise-level protection features and operational-efficiency for their SOC team. F5 Advanced WAF is designed to efficiently prevent known and unknown types of advanced application-based attacks, while NGINX App Protect easily provides ‘application-specific’ security policies for each application inside the microservice environment. The enterprises can acquire the proper protection for their modern app environment through the combination of F5 Advanced WAF and NGINX App Protect. Please visit the DevCentral GitHub repo and follow the guidelines to try this use-case in your environment.
