Hardware Security Modules
In this final stretch of security month, what hopefully has been a helpful serving of security content concludes with a look at some of the technologies that support our integrated solutions. In this article, we’ll cover the hardware security modules (HSM.) An HSM is a crypto management device that generates and stores keys locally, protects that key material from leaving the device as well as enforces policy over key material usage, and secures cryptographic operations. Back before I had the privilege to work for F5, my first exposure to HSM was working on a DoD contract. The web application infrastructure I was responsible for was subject to the FIPS requirements mandating key material be kept under hardware lock and, ahem, key. For years this was under the hood of your BIG-IP appliance (on select models ordered with FIPS cards,) and is still available in that configuration. The need for crypto offload Locking away the keys in a custom hardware module in your BIG-IP is all well and good, and still applicable in many situations, but with the advent of hybrid and completely virtualized infrastructures, the need for network-based HSMs, or netHSMs (and now cloudHSMs for that matter,) arose. F5’s integration points with netHSM technologies were developed specifically for this need, allowing VE, vCMP, Viprion chassis, as well as any other BIG-IP appliance without FIPS hardware to be utilized with FIPS deployments. In the fall, John covered some of the crypto offload options available to F5, FIPS compliant HSMs and otherwise in this Lightboard Lesson if you haven’t checked it out. The Fine Print With a netHSM deployment, there are considerations on both the client and server side. For BIG-IP, a separate license is required to use a netHSM. On the netHSM, depending on the number of clients (i.e., BIG-IP devices) you use, you might need additional licenses from the netHSM vendor. Just like your infrastructure and application servers, redundancy and scale should be considerations as well, so understanding your SSL traffic needs is important. The netHSM configurations require installation of the client software on BIG-IP, so that should be included not just as part of the initial deployment, but considered in future hotfix and upgrade plans as well, as the client software will not be carried forward and will need to be reinstalled. For vCMP and Viprion systems, please note that client software will need to be installed for each guest needing FIPS validation. For further questions on the deployment scenarios and nuances with regard to either the Thales (née SafeNet) or nCipher (née Thales) solution, drop a comment below, ask a question in Q&A , or reach out to your sales team. Resources Configuring one of our partner netHSMs on BIG-IP is a more complex scenario than most deployments. The install guides for Thales (née SafeNet) and nCipher (née Thales) are below in this list of resources. BIG-IP System and Safeness Luna SA HSM: Implementation BIG-IP System and Thales HSM: Implementation Top 10 Hardcore F5 Security Features in 11.5 (good BIG-IP FIPS/nCipher/Thales comparison chart here) US Federal: CCRI Season Lessons LearnedSilverline DDoS Architecture
I wrote on Wednesday about the why and what of F5 Silverline. Today we're going to dive a little deeper into the how of the DDoS service offering. Before we get into the scrubbing architecture itself, let’s take a look at the delivery options for getting traffic to and from the scrubbing centers! Proxy Configuration In the proxy configuration, there is no change to your infrastructure required save for the DNS changes that need to be done once the Silverline DDoS service is configured and ready to receive traffic. Let’s start with the diagram. Walking through the diagram, DNS A records are updated from the local VIPs to the Silverline proxies, and traffic begins flowing through the scrubbing datacenter and then to the customer over the public internet with source NAT-ing from Silverline, resulting in customer server egress traffic flowing through Silverline as well. With this deployment, it is highly recommended to apply ACLs matching Silverline source addresses to prevent direct IP-based attacks that will ignore the DNS instructions to flow through Silverline. One of the benefits of using the proxy scenario is that you can use it with an single IP service, including cloud services like Azure or AWS. Routed Configuration BGP routing was my bread and butter for years. I worked for several different backbone ISPs earlier in my career and I had THE text on BGP from Bassam Halabi(yes, this dates me..) pretty well memorized. This solution leans heavily on BGP to move the advertisement from the customer premises to Silverline so that even an IP-based attack would arrive at the front door of the scrubbing center. In this scenario, the route is advertised from the scrubbing centers so traffic will come to the nearest one. Once the scrubbing has occurred, the traffic leaves the scrubbing center with the original source IP and transits a GRE tunnel to the customer premises, is handed off to the server, and then egress traffic returns to the original client source over the public internet with no need to be passed through the scrubbing center on the return trip. This can save on latency, but does require that customers control (read-can advertise) a /24 network as ISPs typically will not pass smaller blocks across peering points. Not too challenging for most enterprises, but usually a show-stopper for cloud services. The Combo Meal: Routed + Proxy Configuration This final scenario is a combination of the routed and proxy configurations. The DNS changes push the front door to Silverline, and the route advertisement is moved from the customer premises to the back end of Silverline, eliminating the need to manage ISP ACLs to avoid direct IP attacks locally. Note that the traffic is sent across the GRE tunnel to the customer datacenter server infrastructure like the routed configuration, but returned not to the original client but the back end of the Silverline datacenter and then passed back to the original clients like the proxy configuration. Aye, There’s the (Sc)rub I know, terrible Shakespeare reference. But stay with me, we’re getting to the good part! I’ll let this diagram do most of the talking: There is quite a bit of intelligence in the inspection plane. At each stage of the scrubbing, various tools and monitors are reporting and acting on traffic at layers 3 through 7 on a variety of protocols. Notice the vertical paths from inspection to data plane, informing and acting at each layer, and the malicious traffic flows starting to drop off at each mitigation zone before finally reaching the back end of the scrubbing center where the policies/rules get clean traffic where it needs to go. And there it is, the architecture for the exciting and powerful Silverline DDoS service. The best part? It’s not just a mindless service acting in isolation, there is a most excellent SOC staff of talented F5ers watching over your applications, working directly with you to mitigate the attacks and defend your applications. If you haven’t checked out Silverline DDoS for your applications, schedule a demo today!OWASP Mitigation Strategies Part 1: Injection Attacks
The OWASP organization lists “injection” attacks as the number one security flaw on the Internet today. In fact, injection attacks have made the OWASP top ten list for the past 13years and have been listed as the number one attack for the past 9years. Needless to say, these attacks are serious business and should be guarded against very carefully. Every web application environment allows the execution of external commands such as system calls, shell commands, and SQL requests. What’s more, almost all external calls can be attacked if the web application is not properly coded. In the general sense of the word, an injection attack is one whereby malicious code is “injected” into one of these external calls. These attacks are typically used against SQL, LDAP, Xpath, or NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc. When a web application passes information from an HTTP request to an external system, it must be carefully scrubbed. Otherwise, the attacker can inject malicious commands into the request and the web application will blindly pass these on to the external system for execution. One of the most common types of injection attacks in a SQL injection. Many web applications utilize a backend database to store critical information like usernames, passwords, credit card numbers, personal information (address/phone number), etc. When you login to a website, you present your authentication credentials (i.e. username/password), and something on that backend has to validate that you are the correct user. There’s a database back there somewhere holding all that information. In effect, what has happened is that the website you are logging into sent an external command to a backend database and used the credentials you provided in the HTTP request to validate you against the stored database information. Along the way somewhere, some malevolent peeps had some crazy thoughts that went something like this: “hey, if my HTTP request is going to ultimately populate a SQL database command, maybe I could supply some crazy info in that HTTP request so that the SQL command ends up doing some really wild things to that backend database!!” That’s the idea behind the SQL injection attack. SQL commands are used to manipulate database information. You can add, delete, edit, display, etc any information in the database. Like any other system commands, these can be very helpful or very dangerous…it just depends on how they are used. Of course, these commands need to be locked down so that only trusted administrators can use them when running queries on the database. But imagine a web application that wasn’t built correctly and it allows SQL commands to be passed from the HTTP request to the backend database with no error checking at all. That would be a ripe web application for an injection attack! SQL Injection Attack The screenshot below shows a web application for an online auction site called “Hack-it-yourself auction”. This is a fictitious site that was purposely built with bad coding techniques and tons of vulnerabilities. It provides a great testing venue for things like injection attacks. It also showcases the power of a Web Application Firewall (WAF) and the protection it can provide even when your web application is totally vulnerable like this one. Notice in the screenshot that a user can login to the auction site via the “username” and “password” fields on the right side of the page. When a user submits login information on the website, the HTTP request takes the values from the “username” and “password” fields and uses them to formulate a SQL command to validate the user against the backend database that stores all the user information (name, address, credit card number, etc). The SQL command is designed to look something like this: SELECT id FROM users WHERE username = “username”and password = “password” This SQL command grabs the values for “username” and “password” that the user typed into each of those fields. If the username and password are correct, then the user is validated and the web application will allow the user’s information to be displayed. A SQL injection takes advantage of the fact that the HTTP request values are used to build the SQL command. An attacker could replace the “username” info with an interesting string of characters that don’t look very normal to the casual observer but are still understood by the backend database. Check out the screenshot below to see the unique SQL injection username. In this example, the username is ‘ or 1=1# and that will result in the SQL statement looking something like this: SELECT id FROM users WHERE username = ‘’ or 1=1#and password = '".md5($MD5_PREFIX.$password)."' Essentially, this statement is asking the database to select all records in the users table. It takes advantage of the fact that the web application is not validating user inputs and it uses the "or" expression on the username and then states a fact (in this case, 1=1) so that the database will accept it as a true statement. It also uses some creative MD5 hash techniques to access the password. Notice the username in the screenshot below: Apparently this SQL injection worked because now I am logged in as user ‘ or 1=1#. Not your typical, everyday username! So, the authentication was allowed to happen and the database is now ready to serve up any and all records that are located in the users table. I wonder what kind of goodness we can find there? Notice the “Your control panel” link on the page…that link takes you to the information stored for each user in the database. The database is ready to serve up ALL the records in the users table, so let’s click on that “Control Panel” link and see what kind of goodies we can find. Check out the screenshot below and notice in the address bar a familiar-looking username at the end of the URL: Clearly we have some serious issues here. At this point, the attacker has all the names, credit card numbers, emails, phone numbers, and addresses of every single user of this auction site. The attacker could simply copy all this information and use it later or he could manipulate it using other SQL commands or he could delete it all…the possibilities are seemingly endless. Think about some of the recent data breaches you’ve read about (or experienced) that have disclosed sensitive information…some of them happened because of a situation very similar to what I’ve just shown above. The correct answer for this problem is to fix the code that was used to develop this web application. Obviously, this specific code doesn’t check for valid usernames…it will pass along anything you put in that field. OWASP has a list of proactive controls that are great techniques to help prevent exploitation of one or more of the OWASP top ten vulnerabilities. For injection attacks specifically, code developers should do things like parameterize queries, encode data, and validate inputs. Ideally, code developers will write phenomenal code and you won’t ever have to worry about these vulnerabilities. And, in recent years, developers have done a great job of using secure coding practices to do just that. However, not all developers are perfect, and some of the code we use today is very old and hard to change…it’s also full of security vulnerabilities that allow for things like SQL injections. Web Application Firewall Mitigation The BIG-IP Application Security Manager (ASM) is a Web Application Firewall (WAF) that protects your web applications from attacks like the ones listed in the OWASP top ten. While it’s true that code should always be developed in a secure manner, those of us who live in the real world understand that we can’t rely on the hope of secure coding practices to protect our critical information all the time. That’s why you need a WAF. In the case of the very vulnerable “Hack-it-yourself auction” site, a WAF will protect the web application when it cannot protect itself. In the case of a SQL injection, a typical network firewall would have never blocked that attack because it was, in fact, a valid HTTP request on an open port (80, in this case). However, a WAF will inspect the HTTP request, notice that something isn’t quite right, and block it before it ever has a chance to do any damage to your backend database. I created a security policy using the BIG-IP ASM and then turned it on to protect the auction site. The ASM now sits between the user and the web application, so every HTTP request will now flow through the ASM before it heads over to the website. The ASM will inspect each request and either let it through or block it based on the configuration of the security policy. I won’t go into the details of how to build a policy in this article, but you can read more about how to build a policy here. After the security policy was created and activated, I tried the same SQL injection again. This time, instead of getting access to all those credit card numbers, I got a screen that looks like this (you can manipulate the screen to say whatever you want, by the way): Clearly the ASM is doing its job. Another cool thing about the ASM is that you can review the HTTP request logs to see exactly what an attacker is attempting to do when attacking your web application. The screenshot below shows some of the details of the SQL injection attempt. Notice the “Detected Keyword” portion of the screen…see anything familiar? Stay tuned for more exciting details on how the ASM can protect your web applications against other OWASP top ten (and more) vulnerabilities!Silverline WAF Architecture
In a previous article, Jason Rahm did a great job of outlining why you need F5’s Silverline services. The threat is global, and it’s time to reposition your defenses to meet the enemy where they are. Many companies can’t afford the cost of hiring a specialized team of security experts to protect their very important business applications…but neither can they afford to let those applications fall prey to an attack. We see attacks at all networking layers today, so it’s vitally important to have proper network defenses deployed at each layer. A Web Application Firewall (WAF) is a critical part of this network defense because it can uniquely defend against attacks that other devices can’t. F5 Silverline WAF is a cloud-based service built on the BIG-IP Application Security Manager (ASM) with 24x7x365 support from highly specialized security experts to help organizations protect web applications and data, and enable compliance with industry security standards (i.e. PCI DSS). With companies moving applications to the cloud, it becomes extremely important to have a cloud-based service like Silverline to handle your WAF functionality. F5 Silverline WAF protects web applications no matter where they reside with consistent policies and compliance across hybrid environments. The diagram below shows an architecture view of where the F5 Silverline WAF could be deployed to protect your cloud-based applications. You’ll notice from the diagram that the Silverline WAF allows for easy integration with VA/DAST Scanning tools and it also easily integrates with BIG-IP ASM to provide hybrid WAF services while providing access to F5’s wide array of robust APIs. One of the great benefits of F5 Silverline is that is gives you access to the F5 Security Operations Center (SOC). The SOC is a state-of-the-art security center with all the latest and greatest network defense tools you can imagine. But more than having a bunch of really cool and expensive tools, the SOC’s greatest asset is the team of F5 security experts who proactively monitor and fine-tune policies to protect web applications and data from new and emerging threats. Remember how you didn’t have the resources to staff a fully-functional network security team? Well, now you do…it’s called the F5 SOC! Our SOC experts will help you with things like security policy setup, policy fine-tuning, proactive alert monitoring, false positives tuning, detection tuning, and Whitelist / Blacklist setup and monitoring. Another great benefit of F5’s Silverline services is the F5 customer portal. This online portal allows you to securely communicate with Silverline SOC experts and view centralized attack and threat monitoring reports. The portal allows you to view and take action on things like violation logs/stats, policy audits, policy stats, attack types, WAF policies, and L7 profiles. It also allow you access to F5’s very powerful iRule editor where you can gain programmability control over your security policies and web applications. The portal also allows you to manage your SSL Certificates. The pictures below shows screenshots of the WAF portal where you can see attack types over time as well as by geolocation. Attack Type Over Time Violations By Geolocation F5’s Silverline services also include DDoS attack protection as well as an additional threat intelligence service. Silverline is a very powerful and robust option for protecting web applications in the cloud. Remember, meet your enemies where they are…and they are definitely in the cloud!OWASP Mitigation Strategies Part 2: XSS Attacks
Yesterday John showed you how BIG-IP Application Security Firewall can mitigate injection attacks. Today, we’ll cover number three on the list in cross-site scripting. XSS Scripting defined directly from the OWASP XSS page: Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. There are a few attack angles (persistent, reflected, don-based) as well as attack surfaces (client side, server side) and are all far better documented on OWASP and very well summarized on excess-xss.com as well. So what does that look like? Let’s use the example attack scenario from the OWASP page linked above: Here’s how the attack flow works (image recreated for this specific example from an image at excess-xss.com): In the phpauction site, I add a new item to sell, but instead of putting in an actual description, I inject the script: After saving the item, I visit it. Here’s the screen shot confirming that, after connecting to that auction item, my session data was transmitted in the foo query parameter to the attacker site (in yellow at the bottom of the image!) So how do we stop this nefarious behavior? Well that’s where ASM really shines. John covered how to build a policy in part 2 of his ASM series, which I followed for this example. Once I got the policy built and attached to the virtual server, I ran some test traffic to the auction site and attempted another xss injection, which was successful as the policy was in transparent mode. It did however publish some recommendations it learned from my injection attack, which I accepted and then applied the policy. Clicking the have suggestions column on the signatures row took me to the injections I applied: Which takes me to this screen showing me the matching signatures: Once those were accepted and the policy applied (and moved from transparent->blocking!) I then tried to attack again by inserting the same script into the description field of a new item. Good news! And here’s the report from ASM: Walking through the report step by step: In yellow, this is the log entry that matches my attack attempt The green shows me that it was blocked due to matched attack signatures Blue shows me the matching support id and the policy it applied to Purple is the list of matching attack signatures Light orange shows the actual payload that matched and the particular signature highlighted in red. XSS is challenging to stop. Thanks to the OWASP project, education is helping improve developer skills in encoding and validating inputs to protect against XSS attacks. But the reality is, there are billions of lines of code out there with no current protection, and even with new development the potential for oversights still exists. Deploying the Application Security Manager as a tool in your toolbox to help protection your applications puts you in a solid position enhancing your defense in depth strategy.Strong Authentication
It’s authentication, people! Only, wait for it….STRONGER (yes i did use the strong html tag for that.) Strong authentication is a nebulous term. Many will interchange strong authentication with two-factor authentication (2FA), but that is only one method for strong authentication, not necessarily a requirement. You could have a series of “something you know” challenges that makes the authentication process more in depth and thus stronger, but doesn’t require one or more of the other multi-factor pillars in “something you have” or “something you are." So what strong authentication solutions does F5 support? The Access Policy Manager actually shines here, because it is vendor agnostic. You can plug and play a myriad of authentication systems into the process and off you go. Some of the different authentication methods include: LDAP/S HTTP/S RADIUS TACACS+ If your authentication services can talk one or more of these protocols, APM will support it. We’ve posted solutions on DevCentral with Google Authenticator (LTM via ldap and APM,)Yubico Yubikey(LTM and APM,) as well asRSA SecurIDover the years. There are some nuanced differences between all the solutions, but this diagram from Brett Smith’s APM and Yubikey article linked previously shows the general process for APM’s support of multi-factor authentication. This directory server could be Active Directory, LDAP, or RADIUS to a cloud service like Thales' (née SafeNet’s) Authentication Services as discussed in this solution brief. Beyond just authenticating local services, these strong authentication services can be utilized with federation as well, using APM’s SAML support for SP and iDP deployments. Thales (née SafeNet) has quality write-ups for their APM-integrated enterprise and cloudiDP strong authentication services available on their site. For more information about how these authentication services plug in to the larger SAML federation services, take a look at John’s lightboard Lesson on the topic. Additional Resources APM Authentication and Single Sign-On Agility 2015 APM 101 Supporting Infrastructure Lab Documents Thales AuthenticationIntegrating WhiteHat Scans With BIG-IP ASM
Today’s web applications are under constant attack, and it’s critical to keep those applications secure at all times for the protection of yourself and your customers. Ideally, you would utilize a team of perfect web developers who create perfectly secure applications that have no bugs and no security vulnerabilities. But that’s fantasy. In the real world, web applications are deployed every day with a litany of vulnerabilities that provide a target-rich environment for online adversaries. Fortunately, there are companies that specialize in securing web applications, and they provide a way to scan your applications and find critical vulnerabilities. WhiteHat Security has long been a leader in this space, and they protect organizations by identifying website vulnerabilities that the bad guys exploit to cause harm. WhiteHat employs a world-class team of security professionals who constantly research and monitor current threats to web applications. Using this expertise, they develop fully customized tests to run against any web application in the world. These robust tests can be run automatically or manually by the WhiteHat team, and -- rest assured -- if your web application has any vulnerability at all, WhiteHat will find it. WhiteHat offers custom remediation guidance as well as metrics and reports on all the vulnerabilities they find. This allows you to easily and confidently remediate the vulnerabilities as they are discovered. From personal experience, let me say that it’s much better to have a trusted partner like WhiteHat find a vulnerability before a nefarious attacker finds it first. WhiteHat Sentinel, the company’s flagship cloud-based application security product,offers a very user-friendly web interface that outlines all the findings from a given scan. The screenshot below shows an example list of vulnerabilities that were found from a WhiteHat security scan. Notice that WhiteHat ranks each finding with a “rating” scale that allows you to know how severe a particular vulnerability is. Also, notice that each finding receives a numeric score that shows how likely this vulnerability is to be exploited. So, if you have a finding with a high score and a critical vulnerability, it’s time to take some action on getting that one fixed! Imagine this scenario: WhiteHat Sentinel has done a fantastic job of scanning your web applications for current vulnerabilities, and you now have an awesome list of findings to mitigate. But, what if it takes some time to mitigate those findings? What if some of them are so extensive that you might not ever get time to fix them? How will your web application stay secure in the meantime? Of course, I’m glad you asked! F5’s BIG-IP Application Security Manager (ASM) is a Web Application Firewall that is specifically designed to protect your web applications from the exact threats that are found by these WhiteHat scans. One of the powerful features of the ASM is that it has the capability to talk directly to WhiteHat Sentinel via the WhiteHat API and build a custom security policy for your specific web application based on the results of your WhiteHat scan. Here’s how it works (also, see the picture below): The BIG-IP ASM sits in front of your web applications and protects them from attack WhiteHat Sentinel scans your web applications and sends a list of vulnerabilities to the BIG-IP ASM The BIG-IP ASM configures a security policy based on the actual findings from the WhiteHat scan When you create a security policy on the BIG-IP ASM, there are several options to choose from. This specific article won’t go into every detail of policy building because it can get fairly extensive, but you can read this article for more details on policy building. As you build a security policy, you can select the “Vulnerability Assessment Tool” option, and you can see in the screenshot below that one of the scanning tools that integrates with the BIG-IP ASM is the WhiteHat Sentinel tool. Simply select that option from the dropdown box and then you’ll have an option to add an IP address and Netmask for the scanner. This tells the BIG-IP ASM that it should not block that IP address because it’s the one used by the WhiteHat Sentinel scanner. Note: WhiteHat will need to give you the specific IP address and Netmask they will be using for their scans. After you set up the security policy on the BIG-IP ASM, you will need to load in the API key from WhiteHat. This allows the BIG-IP and WhiteHat Sentinel to talk to one another and make updates automatically. The WhiteHat API is unique to your WhiteHat account and will not change. This is nice because you won’t ever need to reload this key once you initially set it up on the BIG-IP ASM. To retrieve the key, you login to your WhiteHat account and navigate to your profile page and you will see a link for the API key. The screenshot below shows the popup message you will see when displaying your API key. Now that you have your WhiteHat API key, you simply copy/paste it into the BIG-IP ASM (see screenshot below). Once you input the key, you should be able to click the “Refresh WhiteHat Site Names List” button and a list of all the sites on your WhiteHat account will auto-populate so that you can simply select the one(s) you want. You also have the option of selecting the “custom” option from the dropdown menu and typing in the site name yourself. When the BIG-IP ASM is protecting your web applications and WhiteHat Sentinel is constantly scanning them for new vulnerabilities, you can rest assured that your web applications are secure. WhiteHat will alert you when a vulnerability is found, and the BIG-IP ASM will protect that vulnerability from the bad guys. It’s a match made in heaven… Learn more about BIG-IP ASM and WhiteHat Sentinel by visiting these resources: https://f5.com/products/modules/application-security-manager https://f5.com/solutions/service-provider/reference-architectures/application-layer-security https://www.whitehatsec.com/offerings.html#sastF5 Silverline: There's a New Sheriff, er, Service in Town!
There are several excellent articles already in the DevCentral coffers covering the Silverline services offered by F5. But it’s security week, and before we deep dive into the services architectures this week, I’d like to take a few minutes of your time to do a brief recap of what Silverline is and why it matters. Let’s start with the why. I visited Gettysburg, PA with my family last week, site of the bloodiest battle in the US Civil War. We did the audio tour, visiting most of the 1st and 2nd day battlefield locations and listening to the history that unfolded there. Actually being on those hills, it was easier to understand the narrative of why the union retreated so quickly on day 1. It wasn’t a retreat in the sense they were staving off defeat, even for another day. In reality, they were repositioning their forces to better fend off the attacks of their enemy in the anticipated following waves from General Lee’s army. Taking the strategic high ground is vitally important, and proved (alongside many other strategic decisions) part of the winning strategy in the outcome of that battle. And so it is with protecting your applications. Sometimes you need to reposition your defenses and take the strategic high ground to the win the battles against all the threats out there in modern warfare. Even if your perimeter has yet to shift (but it will eventually,) the enemy has gone global. There isn’t a corner of cyberspace where you can’t be attacked from. That’s the why. So where does F5 Silverline fit? To start, it is a suite of cloud-based application services that deploys some of the strategic defenses from solely defending the perimeter to engaging in battle on other fronts. This is akin to General Meade redeploying brigades around the Gettysburg battlefront to meet the enemies where they were. By transitioning some of the defenses away from the perimeter, you can keep the attacks away from your precious assets, while still keeping those lines of defenses established at home. So what does F5 Silverline offer? F5 Silverline DDoS Protection Your infrastructure at the perimeter may well protect your applications. But can your plumbing handle the volume? This is the million dollar question you must ask yourself. And this is precisely why the F5 Silverline DDoS Protection is well-suited to your needs. It scrubs the bad actors flames and arrows of outrageous fortune so you don’t have to, as if you could with 300 GB of malicious traffic trying to fit down your 10G pipes! THE David Holmes highlighted the problem this solution overcomes in this article. F5 Silverline Web Application Firewall Application Security Manager is a fantastic offering on the BIG-IP platform. You might have it in-house already, or you might have a cloud-based application you need to protect and are in the hunt for a web application firewall. Either way, this managed service takes the load off your shoulders and places it squarely on the thick shoulders of our excellent security operations center. John covered the F5 Silverline WAF quite well last year, it would be well worth your time to dig in. F5 Silverline Threat Intelligence You guessed it. This is the new sheriff in town! Did your knees buckle when I threw that curveball? I’m sure after DDoS and WAF you were thinking “yeah, I know about this stuff, tell me something new!” Well, effective today, F5 Silverline adds threat intelligence to the suite of services! This is additive to either of the DDoS/WAF services, it is not a standalone service. Lori released a fantastic overview of the new service this morning over on F5.com, so make sure you check it out. Resources We’ve had some excellent discourse on F5 Silverline since launch, here are some of the articles for your reading pleasure. F5 Silverline Platform product page The IoT Ready Platform Strengthen Your Cloud-Based DDoS Protection F5 Silverline: DDoS Protection and Web Application Firewall as Managed Services Stay tuned..John is on deck with the F5 Silverline firewall architecture later today, and I’m in the hole with the DDoS architecture tomorrow.AFM Provisioning and Policy Building
The BIG-IP Advanced Firewall Manager (AFM) is a high-performance, stateful, full-proxy network firewall designed to guard against incoming threats that enter the network on the most widely deployed protocols. This article will show how to provision AFM on your BIG-IP system and then walk through some of the beginning steps to build a firewall policy. Provisioning the AFM In order to provision the AFM on your BIG-IP system, navigate to System >> Resource Provisioning and check the Advanced Firewall (AFM) box, then hit the “Submit” button at the bottom of the page. After you hit the Submit button, the BIG-IP will need to restart in order to apply the changes and activate the AFM module. See the screenshot below: AFM Policy Building After you provision the AFM, you can build out a firewall policy and then attach it to one or more virtual servers. Please keep in mind that the AFM is a sophisticated module with many different options. This article is not meant to cover all the features, but we will have more AFM articles in the coming months to show how to configure and utilize the various features of the AFM. For this article, let’s build a simple AFM policy and then attach it to a virtual server. On the BIG-IP, a policy is a feature that provides a way to classify traffic based on a list of matching rules and run specific actions on that traffic based on the associated rules. You might be familiar with Local Traffic Policies on the LTM…the firewall policy on the AFM follows the same basic idea: establish a list of rules and then take action on network traffic based on those rules. To create a new Network Firewall policy, navigate to Security >> Network Firewall >> Policies, and then click the “Create” button. See screenshot below: I created a policy and named it “My_AFM_Policy” and at this point in the process, that’s all it is…just an empty policy with a name. Now it’s time to build out the rules of what this policy will contain so that it can start doing some stuff. After you create the policy, you will see the policy listed on the “Policies” page and you can click on it to start adding rules. See the screenshot below: When you add a new rule to the policy, you have several options to choose from. You first name the rule, and then you select what order to put it in (last, first, before, after), you select the state (enabled, disabled, or scheduled for another time that you determine), you specify the protocol that will be affected by this rule, you specify the source and destination, you select any applicable iRules, you specify the action to take on this rule, etc. As for the action to take, you can select from the following options: Accept, Drop, Reject, or Accept Decisively. The Accept option allows packets with the specified source, destination, and protocol to pass through the firewall. Packets that match the rule, and are accepted, traverse the system as if the firewall were not present at all. The Drop option drops packets with the specified source, destination, and protocol. Dropping a packet is a silent action with no notification to the source or destination systems. Dropping the packet causes the connection to be retried until the retry threshold is reached. The Reject option rejects packets with the specified source, destination, and protocol. When a packet is rejected the firewall sends a destination unreachable message to the sender. Finally, the Accept Decisively option allows packets with the specified source, destination, and protocol to pass through the firewall, and does not require any further processing by any of the further firewalls. See the screenshot below for all the cool options. I named my rule “block_all_traffic” because, you know, that’s how I roll… Of course, you will want to add more rules than the crazy “block everything” rule, but you get the idea on creating rules for your policy. Now that you have a policy with a set of rules in it, you are ready to associate it with one or more virtual servers. When you do this, the traffic destined for that virtual server will have to satisfy the rules of your AFM policy in order to reach the virtual server. Pretty cool stuff. In order to activate a network firewall policy on a virtual server, navigate to Local Traffic >> Virtual Servers: Virtual Server List and click on the Virtual Server you want to activate this policy for. After you click on the virtual server name, click on the dropdown menu for “Security” and click on Policies. You will see the screenshot below: Notice the “Network Firewall” menu where you can select a policy from the “Enforcement” or “Staging” option. In order to enable the policy, you simply select the “Enabled” option next to “Enforcement” and then select from the dropdown list of policies. In this example, I chose the “My_AFM_Policy” that I created earlier. Finally, you click the “Update” button and you will notice the various rules on the bottom portion of the screen. These are the rules that are associated with the policy you selected (in our case, it’s just the one “block_all_traffic” rule). See the screenshot below for the details: Well, that does it for basic AFM provisioning and policy building. Be on the lookout for our upcoming AFM article series where we will dive into the details of how to configure all the cool features of this powerful module!Advanced 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 Practices
