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!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 LearnedAdvanced 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 PracticesStrong 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 AuthenticationFebruary Is Security Month On DevCentral
We are always interested in security at F5, but this month we are taking it a step further and highlighting lots of great security content on DevCentral. From discussing new features on our Advanced Firewall Manager, to showing off some OWASP Top 10 vulnerability mitigation options, to showcasing our new Silverline Cloud-Based application services platform, to featuring several partner integration options, the month of February on DevCentral will not disappoint! Here’s a quick overview of what we have planned: February 2016 Monday Tuesday Wednesday Thursday Friday 31 1 February is Security Month! 2 The Perimeter is Dead, Long Live the Perimeter! 3 AFM Provisioning & Policy Building 4 Advanced Firewall Manager Roundtable 5 AFM Series Teaser 6 7 8 The OWASP Top 10 9 Interview with Jim Manico 10 OWASP Mitigation Strategies with ASM Part 1: Injection Attacks 11 OWASP Mitigation Strategies with ASM Part 2: XSS Attacks 12 13 14 15 16 Silverline Services 17 Silverline Web Application Firewall Architecture 18 Silverline DDoS Protection Architecture 19 Silverline Threat Intelligence 20 21 22 Hardware Security Modules 23 Advanced Threat Mitigation 24 External Reporting With BIG-IP ASM 25 Integrating WhiteHat Scans with BIG-IP ASM 26 Strong Authentication 27 28 29 Security Octagon 1 2 3 4 5 We will be at the RSA conference in San Francisco at the end of February, so be sure to swing by the F5 booth(South Expo #S1515) and come talk to us about all the security content you’ve read throughout the month. As each piece of content gets published, I will add a link so you can navigate right to it from here. Be sure to check back early and often! .alert-info{display:none}Integrating 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#sastExternal Reporting with BIG-IP ASM
We all know that the BIG-IP ASM does a bunch of great things to protect web applications from malicious attackers. We also know that it’s extremely important to review logs to ensure visibility and awareness about application traffic. In fact, the OWASP organization published the “OWASP Top 10 Proactive Controls” as recommended steps to help mitigate each of their published Top 10 security vulnerabilities. Some of these proactive controls help mitigate more than one of the Top 10 vulnerabilities, but they list “Logging” as a control that helps mitigate all ten! They say it like this, “Logging and tracking security events and metrics helps to enable "attack-driven defense" making sure that your security testing and controls are aligned with real-world attacks against your system.” Needless to say, event logging is critical to the overall security of your web applications. BIG-IP ASM Logging Profiles The BIG-IP ASM dedicates significant resources to event logging. After all, when the ASM blocks a malicious request, you’ll likely want to know all the details associated with that request. Fortunately, you can create a “logging profile” and configure it to capture all kinds of great information. To create a logging profile, navigate to Security >> Event Logs >> Logging Profiles and then click the “Create” button on the upper right part of the page to begin creating a new logging profile. Check out the screenshot below to see the details: You can name your profile whatever you want, but in this case, we are going to set up a profile to send logs to Splunk, so I named mine “Splunk”. Because I’m sending these logs to a remote server, I enabled the “Remote Storage” checkbox and it gave me all the different options for choosing format, protocol, server address/port, and storage format. I chose the UDP protocol because that’s what Splunk uses, I typed in the IP address for the Splunk server I’m using (be sure to click the “Add” button after you input IP address and port), and I moved all the Storage Format items from “Available” to “Selected”. Finally, click the “Finished” button at the bottom of the screen to complete the profile creation. The screenshot below shows all the completed configurations for my profile: Now we have a complete profile that will send all the “Selected” items to the Splunk server using UDP port 514. There’s still one thing to do, though. We need to associate this profile with a virtual server on the BIG-IP. After all, the logging profile won’t know which server to be capturing log information for unless we tell it. To do this, navigate to Local Traffic >> Virtual Servers >> Virtual Server List and click on the virtual server you want to associate with this Logging Profile. When you select the virtual server, you’ll notice a series of menu choices across the top of the screen…click on the “Security” link and select the “Policies” option. When you do that, you’ll see the screen shown below: Notice that I have a security policy (auction_security_policy) and it is enabled on this virtual server. Additionally, I changed the “Log Profile” option from Disabled to Enabled. When it changes to Enabled, you’ll see a menu that allows you to move logging profiles from “Available” to “Selected”. I moved my Splunk logging profile to the Selected column and finally clicked the “Update” button. Now, I have a fully functional logging profile that has been enabled on my virtual server. It’s time to generate some logs by visiting (or, in my case, attacking) the web application that is being protected by my Application Security Policy. I’ll save you all the screenshots of my web application, but I will show you the log report captured on the BIG-IP when I attempted an injection attack against my web application. Navigate to Security >> Event Logs >> Application >> Requests and you’ll see the list of illegal requests that were blocked by the ASM security policy. Remember how the logging profile listed the “Remote Storage” as an option? Well, if you looked closely, you noticed that it also included “Local Storage” as well. That means the BIG-IP will keep a record of all these illegal requests in addition to sending them over to the Remote Storage server. You can obviously configure these settings differently depending on your needs. Anyway, back to the illegal request list. Notice that two of the ASM attack signatures detected a violation in the request. And, rightfully so…after all, I was attempting an injection attack! After I attempted the injection attack, I wanted to slightly change the configuration of the logging profile, so I changed the logging profile to only capture attack-type for each illegal request. I navigated back to my Splunk logging profile and moved everything but “attack_type” back from Selected to Available and then clicked Update. See the screenshot below: The nice thing about making this change in the logging profile is that I don’t have to change it anywhere else on the BIG-IP. Any virtual server that has this logging profile enabled will now only capture the attack_type field when logging an illegal request. So, enough with the BIG-IP…what about the remote Splunk server? Well, I logged into Splunk and set up a custom search on UDP port 514 since that is the port I configured to send logs to Splunk from the BIG-IP. Check out the screenshot below to see the details that Splunk captured: Notice the first request in Splunk lists all the details of the illegal request. If you look closely, you’ll notice that all these details match up to the list of “Selected” items chosen in the logging profile. Then, notice that the most current request (the one at the top of the list) only lists the attack_type…in this case it’s “SQL-Injection”. Pretty cool stuff, huh? The BIG-IP is capable of sending log information to much more than just Splunk, so get out there and configure those logging profiles to suite your specific needs. Remember, log review is one of the most critical things you can do to protect all your web applications!Silverline 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!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!F5 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.
