DDoS attacks & other online vulnerabilities

Transcription

1 DDoS attacks & other online vulnerabilities Mitigating common threats FLARE enterprise@cloudflare.com

2 Denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks are on the rise and have evolved into complex and overwhelming security challenges for organizations large and small. Layer Application Presentation Session Transport Network Data link Physical layer Although DDoS attacks are not a recent phenomenon, the methods and resources available to conduct and mask such attacks have dramatically evolved. The fact is that these attacks can no longer be addressed by traditional on-premise solutions. CloudFlare s advanced DDoS protection, provisioned as a service at the network edge, matches the sophistication and scale of such threats and can be used to mitigate DDoS attacks of all forms and sizes. What is a DDoS attack? A DDoS attack is an attempt to make a server or network resource unavailable to Internet users. There are many ways to prevent users from getting to where they want to go on the Internet, but most attacks take place at the Network and Transport layers (Layers 3 and 4 respectively) and at the Application layer (Layer 7) of the Open System Interconnection (OSI) Model. Description Network process to application Mail, Chrome, Firefox Data representation and encryption TLS, JPEG, ASCII, EBCDIC Interhost communication HTTP, FTP, SMTP End-to-end connections and reliability TCP, UDP Path determination and logical addressing IPv4, IPv6 Physical addressing PPP, IEEE 802.2, L2TP Media, signal, and binary transmission DSL, USB THE OSI MODEL is a teaching tool that provides a standardized way to describe how the various layers of data communication systems interact. A particular concern with DDoS attacks is that a number of commercial stresser or booter sites exist on the Internet, allowing anyone with a credit card or bitcoin to purchase a DDoS for a relatively low fee (often under 100 USD). This lowers the bar for attacks and expands both the number of potential attackers and number of attacks dramatically. Other attacks are crafted specifically to compromise a given application and may be waged by sophisticated attackers with substantial in-house resources. Traditionally, DDoS attacks have targeted Layers 3 and 4 of the OSI model by attempting to flood an interface with illegitimate or junk traffic in order to overwhelm its resources. Usually, an attack fills up the capacity of a network switch, overwhelms a server s network card, or overwhelms a CPU s ability to handle the traffic. Large DDoS attacks are difficult if not impossible to mitigate with an on-premise solution. The fact is that if attacker is able to send more traffic than a network link can handle, no amount of additional hardware resources will help mitigate such an attack. 2

3 DDoS attacks that target Layer 7 are smaller in volume, but more sophisticated. These types of attacks are difficult to detect and mitigate because they mimic normal use of an application and attack specific web resources. Traditional solutions have required on premise Large DDoS attacks are difficult if not equipment that attempt to decode network traffic impossible to mitigate with an on-premise before deciding if the traffic is good or bad. This approach impacts legitimate visitors and adds solution. The fact is that if attacker is able to latency to each request. send more traffic than a network link can Layer 7 attacks can also aim to compromise the handle, no amount of additional hardware security of an application. One way this can be resources will help mitigate such an attack. done is by injecting an SQL statement that can query a database, retrieve information, and send it back to the attacker. This paper will describe the following types of DDoS and vulnerability attacks and the methods CloudFlare uses to mitigate them: Attack type OSI Layer(s) targeted Mitigation strategy DDoS: Amplification Layer 3 and 4 DDoS: DNS Flood Layer 3 and 4 DDoS: SYN Flood Layer 3 and 4 DDoS: Layer 7 Denial of Service Layer 7 Absorb Bandwidth Spikes Anycast Network Anycast Network Absorb Bandwidth Spikes CloudFlare s Automatic Learning Platform Anycast Network Absorb Bandwidth Spikes CloudFlare s Automatic Learning Platform Intelligent Network Protection I m Under Attack Mode Non-DDoS: Application Vulnerability Layer 7 Web Application Firewall (WAF) Amplification attacks Amplification attacks are one of the more common DDoS attacks currently targeting enterprise companies. They re the simplest attacks to launch because they rely on easily accessible, misconfigured servers and DNS resolvers that will accept queries from anyone on the Internet. The goal of an amplification attack is to generate huge volumes of traffic to a single IP address, taking up so much bandwidth that legitimate visitors cannot access a site or use a web property such as an API. This type of volumetric DDoS attack relies primarily on four UDP protocols: The Domain Name System (DNS), Network Time Protocol (NTP), Character Generator Protocol (CHARGEN), and Universal Plug and Play Protocol (UPnP). The reason these protocols are used is because they are carried by the UDP protocol. The UDP protocols are fire-and-forget protocols, meaning that there is no TCP handshake to establish where a packet is coming 3

4 from. This means that attackers can forge the header of a IP address making it look like it is coming from an IP address they intend to attack. Once the header is forged, the attacker can send a query to an DNS, NTP, CHARGEN, or UPnP server and have the reply sent to their target IP address. To amplify the volume of response traffic, an attacker can send a query to a DNS, NTP, CHARGEN, or UPnP server that will result in a large response to their intended victim. An attacker could, for example, send the following query (where x.x.x.x is the IP of an open DNS resolver): dig ANY +edns=0 And get back the following gigantic response: ; <<>> DiG <<>> ANY ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5147 ;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 4, ADDITIONAL: 5 ;; QUESTION SECTION: ;isc.org. IN ANY ;; ANSWER SECTION: isc.org IN SOA ns-int.isc.org. hostmaster.isc.org isc.org IN A isc.org IN MX 10 mx.pao1.isc.org. isc.org IN MX 10 mx.ams1.isc.org. isc.org IN TXT v=spf1 a mx ip4: /21 ip4: /16 ip6:2001:04f8::0/32 ip6:2001:500:60::65/128 ~all isc.org IN TXT $Id: isc.org,v :36:09 bind Exp $ isc.org IN AAAA 2001:4f8:0:2::d isc.org IN NAPTR 20 0 S SIP+D2U _sip._udp.isc.org. isc.org. 484 IN NSEC _kerberos.isc.org. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY SPF isc.org IN DNSKEY BQEAAAAB2F1v2HWzCCE9vNsKfk0K8vd4EBwizNT9KO6WYXj0oxEL4eOJ axbax/bzpfx+3qo8b8pu8e/jjkwh0oayz4guuytvmt5eelg44vb1kssy q8w27oq+9qnip8jv6zdoj0ucb/n0fxfvl3371xbednfqoecfsfdza6hw ju1qzvessw0= isc.org IN DNSKEY BEAAAAOhHQDBrhQbtphgq2wQUpEQ5t4DtUHxoMVFu2hWLDMvoOMRXjGr hhcefvazih7yjhf8zgfw6hd38hxg/ xylyco6krpbdojwx8ymxla5/ka+ u50wil8zr1r6ktbsyvmf/qx5rinbpclw+vt+u8exejmo20jis1ulgqy3 47cBB1zMnnz/4LJpA0da9CbKj3A254T515sNIMcwsB8/2+2E63/zZrQz Bkj0BrN/9Bexjpiks3jRhZatEsXn3dTy47R09Uix5WcJt+xzqZ7+ysyL KOOedS39Z7SDmsn2eA0FKtQpwA6LXeG2w+jxmw3oA8lVUgEf/rzeC/bB ybnso70aeftd isc.org IN SPF v=spf1 a mx ip4: /21 ip4: /16 ip6:2001:04f8::0/32 ip6:2001:500:60::65/128 ~all isc.org. 484 IN RRSIG NS isc.org. ofeny69pn+/jnnltgpuzqnyzo1ygglmhs/szknlgymbz+tt2r/2v+x1j AkUl9GRW9JAZU+x0oEj5oNAkRiQqK+D6DC+PGdM2/JHa0X41LnMIE2NX UHDAKMmbqk529fUy3MvA/ZwR9FXurcfYQ5fnpEEaawNS0bKxomw48dcp Aco= isc.org. 484 IN RRSIG SOA isc.org. S+DLHzE/8WQbnSl70geMYoKvGlIuKARVlxmssce+MX6DO/J1xdK9xGac XCuAhRpTMKElKq2dIhKp8vnS2e+JTZLrGl4q/bnrrmhQ9eBS7IFmrQ6s 0cKEEyuijumOPlKCCN9QX7ds4siiTIrEOGhCaamEgRJqVxqCsg1dBUrR hkk= isc.org. 484 IN RRSIG MX isc.org. VFqFWRPyulIT8VsIdXKMpMRJTYpdggoGgOjKJzKJs/6ZrxmbJtmAxgEu / rkwd6q9jwsucepnc74eyxzxfvdannkp/qdmt2139h/xozsw0jva4z+b znq3knidjdv6zl6eltcvdqj3siwdzhyb/cr9pnno1faf2joijyswiwbs Lcw= isc.org. 484 IN RRSIG TXT isc.org. Ojj8YCZf3jYL9eO8w4Tl9HjWKP3CKXQRFed8s9xeh5TR3KI3tQTKsSeI JRQaCXkADiRwHt0j7VaJ3xUHa5LCkzetcVgJNPmhovVa1w87Hz4DU6q9 k9bbshvbytxof8xny/fcir5c6nvelmvvu4xeoqswipoo2zvieffp9der UhA= isc.org. 484 IN RRSIG AAAA isc.org. hutacro0nbmvku/m+2lf8sgiyyivwortp/utin8ksf1wowwm2qmga5c9 /rh/ ZQBQgN46ZMmiEm4LxH6mtaKxMsBGZwgzUEdfsvVtr+fS5NUoA1rF wg92ebbinndcvt0if8m1sldx5/hsqkn8easckfg5bmqp5ydfsllstaua 8Y4= isc.org. 484 IN RRSIG NAPTR isc.org. ZD14qEHR7jVXn5uJUn6XR9Lvt5Pa7YTEW94hNAn9Lm3Tlnkg11AeZiOU 3woQ1pg+esCQepKCiBlplPLcag3LHlQ19OdACrHGUzzM+rnHY50Rn/H4 XQTqUWHBF2Cs0CvfqRxLvAl5AY6P2bb/iUQ6hV8Go0OFvmMEkJOnxPPw 5i4= isc.org. 484 IN RRSIG NSEC isc.org. ry1hqzarym045vv3bmy0wgjhxhjqofkxlerlk20lau1mvtyu7uair7jb MwDVCVhxF7gfRdgu8x7LPSvJKUl6sn731Y80CnGwszXBp6tVpgw6oOcr Pi0rsnzC6lIarXLwNBFmLZg2Aza6SSirzOPObnmK6PLQCdmaVAPrVJQs FHY= isc.org. 484 IN RRSIG DNSKEY isc.org. i0s2mfqvhb3wohv2ipoze/iqabm/eddcv2d7dj3auowi1a3sbyq29xud BK82+mxxsET2U6hv64crpbGTNJP3OsMxNOAFA0QYphoMnt0jg3OYg+AC L2j92kx8ZdEhxKiE6pm+cFVBHLLLmXGKLDaVnffLv1GQIl5YrIyy4jiw h0a= isc.org. 484 IN RRSIG DNSKEY isc.org. j1kgww+wffw01e2z2kxq+bitg1rrng1xop17piotozhelgpy7f6kegyj fn6e2c+gvxxoaabq+qr76o+p+zuhrluei0ewtc3v4hzimel0z2/ne0mh qaedmeemezkn9o1eaoc7gz4nu5psmuylqxcckudbw0qhld+u/8+d6l1s nlrd/vei4r1sll2bd5vbtaxczoz+2beqlveut/ UusS1qhYcFjdCYbHqF JGQziTJv9ssbEDHT7COc05gG+A1Av5tNN5ag7QHWa0VE+Ux0nH7JUy0N ch1kvecpbxjvhrf97ceh5wcdegcfkayyhaxxh02fqbgfon8r5micgo/f DRdXjA== isc.org. 484 IN RRSIG SPF isc.org. IB/bo9HPjr6aZqPRkzf9bXyK8TpBFj3HNQloqhrguMSBfcMfmJqHxKyD ZoLKZkQk9kPeztau6hj2YnyBoTd0zIVJ5fVSqJPuNqxwm2h9HMs140r3 9HmbnkO7Fe+Lu5AD0s6+E9qayi3wOOwunBgUkkFsC8BjiiGrRKcY8GhC kak= isc.org. 484 IN RRSIG A isc.org. ViS+qg95DibkkZ5kbL8vCBpRUqI2/M9UwthPVCXl8ciglLftiMC9WUzq Ul3FBbri5CKD/ YNXqyvjxyvmZfkQLDUmffjDB+ZGqBxSpG8j1fDwK6n1 hwbkf7qse4lujzyegxfekp16cmvyzctituh2tndmrgsoxrvroqoepwhp 8+E= isc.org IN NS ns.isc.afilias-nst.info. isc.org IN NS ams.sns-pb.isc.org. isc.org IN NS ord.sns-pb.isc.org. isc.org IN NS sfba.sns-pb.isc.org. ;; AUTHORITY SECTION: isc.org IN NS ns.isc.afilias-nst.info. isc.org IN NS ams.sns-pb.isc.org. isc.org IN NS ord.sns-pb.isc.org. isc.org IN NS sfba.sns-pb.isc.org. ;; ADDITIONAL SECTION: mx.ams1.isc.org. 484 IN A mx.ams1.isc.org. 484 IN AAAA 2001:500:60::65 mx.pao1.isc.org. 484 IN A mx.pao1.isc.org. 484 IN AAAA 2001:4f8:0:2::2b _sip._udp.isc.org IN SRV asterisk.isc.org. ;; Query time: 176 msec ;; SERVER: x.x.x.x#53(x.x.x.x) ;; WHEN: Tue Oct 30 01:14: ;; MSG SIZE rcvd:

5 Since many DNS servers have high bandwidth connections to the Internet, they have no problem pumping out a high volume of bytes. The request above is a 64 byte query that resulted in a 3,223 byte response. So a small UDP request, like dig ANY, when sent to open DNS resolvers, can return a crippling amount of traffic to the intended target in this case, an attacker could have achieved a 50x amplification over the traffic they initiated to an open DNS resolver. Amplification attacks can reach over 500Gbps, easily enough to saturate network links or overwhelm servers. This means that the majority of businesses are vulnerable to this attack vector. CloudFlare shields web properties from this type of volumetric attack in two ways: Using an Anycast network to spread traffic to all of our datacenters Absorbing excess traffic to individual data centers by having a diverse set of high bandwidth interconnections with other networks Understanding the differences between Unicast and Anycast Most of the Internet works via a routing scheme called Unicast. In a Unicast network, every node on the network gets an IP address which is unique to it. In this system, communication is between a single sender and a single receiver over a network. UNICAST (LEFT) is a one to one relationship between the user and the server. ANYCAST (RIGHT) is one to a possible many. The user s connection is directed to the closest server geophraphically. Seattle San Jose Los Angeles Dallas Chicago Toronto Newark Ashburn Atlanta Miami Medellín Düsseldorf Amsterdam Manchester Dublin London Paris Madrid Berlin Milan Marseille Frankfurt Stockholm Warsaw Prague Vienna Bucharest Doha Dubai Kuwait City Muscat Langfang Tianjin Zhengzhou Luoyang Xi an Shijiazhuang Chengdu Hengyang Guangzhou Nanning Foshan Shenyang Seoul Tokyo Osaka Qingdao Jiaxing Hangzhou Fuzhou Hong Kong Dongguan Lima Mombasa Kuala Lumpur Singapore Valparaíso São Paulo Buenos Aires Johannesburg Sydney Melbourne Auckland CLOUDFLARE NETWORK MAP (AS OF SEPTEMBER 2015) For the latest map, see 5

6 Unicast networks work fine until one of the servers on that network goes down. Since traffic is routed to a single location, if a server in that location goes down, your website, API, or other web property is offline. The main reason why Unicast networks are especially vulnerable to DDoS attacks is because attackers can target and overwhelm a single server. CloudFlare uses a different networking design called Anycast. With an Anycast network, multiple machines can share the same IP address. This means that when a request is sent to an Anycasted IP address, routers will direct it to the machine on the network that is closest to the user. This has two positive effects. One, it makes response time to users faster by serving content from the server closest to them, and two, if an attacker tries to target one particular IP address, our Anycast system, by sharing the same IP address around the world, increases the surface area of the network and allows us to spread out and easily absorb the spike in traffic Prior to CloudFlare, a DDoS attack that was more than 20Gbps was considered difficult for most enterprises to mitigate. Because of the robust mitigation resources built into the CloudFlare network, we routinely mitigate DDoS attacks that reach 500Gbps. > dig ANY example.com ; <<>> DiG P1 <<>> example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4969 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com IN SOA sns.dns.icann.org. noc.dns.icann.org example.com IN RRSIG NSEC example.com. UJHsLeIUxISWr+z- Attacker > dig ANY example.com DNS servers ; <<>> DiG P1 <<>> example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4969 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 Your server Attacker DNS servers CloudFlare Your server AMPLIFICATION ATTACKS (TOP) Attackers pretending to be your server make tiny requests to a DNS, NTP, CHARGEN, or UPnP server. Those servers return huge responses to your server, knocking it offline. AMPLIFICATION ATTACKS WITH CLOUDFLARE (BOTTOM) Attackers pretending to be your server make tiny requests to a DNS, NTP, CHARGEN, or UPnP server. Those servers return huge responses. CloudFlare s Anycast network spreads out and absorbs traffic spikes. DNS flood attacks A DNS flood attack is another type of volumetric DDoS attack. While many volumetric attacks use amplified responses from DNS or NTP servers to overwhelm a web server, DNS flood attacks target DNS servers themselves. Instead of taking a web property offline by knocking out the server that is hosting it, a DNS flood attack aims to take out the DNS servers that tell Internet users where the site, API, or other web property is located. Sending a flood of packets large enough to overwhelm a DNS server can have two outcomes. One, the DNS server s processing capacity could be exhausted. The other is that the network link to the DNS server could be totally filled. An attacker doesn t care which one of these happens first because they both achieve the same goal: deny real users access to DNS servers so they can t find the web property they are looking for. 6

7 > asfjkas.example.com, ksjgkjg.example.com, zbjskfj.example.com, sakdfsk.example.com, mhrnkin.example.com, skjasku.exa Attackers > asfjkas.example.com, ksjgkjg.example.com, zbjskfj.example.com, sakdfsk.example.com, mhrnkin.example.com, skjasku.exa Your DNS Server Visitors Attackers CloudFlare DNS Visitors DNS FLOOD ATTACK (TOP) Attackers overwhelm DNS servers with requests for a single website, making it impossible for real users to access. DNS FLOOD ATTACK WITH CLOUDFLARE (BOTTOM) Attackers target CloudFlare DNS servers, but their requests are distributed over our entire network. One way an attacker might try to take a DNS server offline is to spoof random prefix queries. By making thousands of requests to nonexistent subdomains, a DNS server s resources can be exhausted or the network link could be saturated. In both cases, a DNS server will be unable to answer queries for legitimate users, making it impossible for real visitors to find the targeted site. Large volumetric DDoS attacks like DNS floods are also difficult for on-premise solutions to mitigate and there are only a handful of companies that have build networks that can handle 500+ Gbps attacks. CloudFlare protects web properties from DNS flood attacks in two ways: Using an Anycast network to spread traffic to all of our datacenters (as described in detail above) Using proprietary technologies that automatically identify and block new attacks wxctkzubkb. ebepexklyfaxmloh. ktylstudkr. ohunarajmbkrej. wwtdheilzcv. zktvvotoyrewaku. khyhavsnijslyb. gchjpexychflvfv. ruqnpvp. fapzefvgowzonss. mcvhothfketpgre. asldfkaslfkf. meqtnretiah. qwmneqmen. SPOOFED PREFIX QUERIES By making thousands of requests to nonexistant subdomains, a DNS server s resources can be exhausted. CloudFlare s automatic learning platform CloudFlare has developed proprietary technology that leverages knowledge from a diverse community of websites, APIs, and other web properties to harness the power of numbers. This technology analyzes network traffic and metrics in real-time in order to identify anomalous or malicious requests. Once a new attack is identified, CloudFlare automatically starts to block that attack type for both the particular web property and the entire CloudFlare network community. This type of community learning means that the larger CloudFlare s user base becomes, the more protection every CloudFlare customer receives. CloudFlare has over 2 million domains using our service, and we see over 1 billion unique IP addresses each month. It is this breadth of traffic that allows the CloudFlare network to identify new attacks quickly and provide the best in enterprise-grade security. 7

8 SYN flood A SYN flood DDoS attack is also a type of volumetric attack, but it works differently from DNS flood and amplification attacks. During a SYN flood, an attacker sends a succession of SYN requests to a server in order to exhaust its resources and prevent real users from creating connections. 1 SYN SYN-ACK 2 Visitor 3 ACK Your server SYN-ACK THREE WAY HANDSHAKE The typical process for initiating a TCP connection is a three step, back-and-forth process. SYN floods work by breaking the normal TCP three-way handshake connection establishment process. In a successful TCP connection, a client and server exchange a series of messages to establish a stable connection. The first part of that connection is called a synchronized message or SYN. Once a server receives a SYN it then responds with an acknowledgement SYN-ACK and expects to receive a follow up acknowledgement ACK from the client so a connection can be established. During a SYN flood DDoS attack, an attacker sends a huge number of SYN requests and then breaks the response cycle to the server. The server, having received a SYN message, will wait for the acknowledgement with half-open connections that take up resources. If enough half-open connections are created, the server s CPU will be exhausted and no new connections can be made. This ultimately denies legitimate traffic from reaching the server. Since the attacker sending these requests doesn t care about getting a response, they can spoof the IP address and direct the flood of SYN requests toward the target server. SYN SYN-ACK SYN Attacker Your server Visitor SYN Attacker CloudFlare Your server SYN FLOOD ATTACK (TOP) Attacker sends many SYN requests then breaks the response cycle creating many open connections and overwhelming the server. Legitimate users are unable to connect. SYN FLOOD ATTACK WITH CLOUDFLARE (BOTTOM) CloudFlare protects origin servers from floods of SYN requests, allowing legitimate traffic to get through. 8

9 Since SYN attacks are a form of volumetric DDoS attack, CloudFlare mitigates them with the same methods used for other volumetric attacks: spreading out the flood of requests via our Anycast network, having huge amounts of bandwidth to absorb the extra traffic, and leveraging CloudFlare s automatic learning platform to filter out malicious traffic, ensuring our customers origin servers are protected. Layer 7 attacks Layer 7 (Application layer) attacks are a relatively new breed of attack. They are the most complicated and sophisticated types of network based attacks. By mimicking normal use of an application, Layer 7 attacks are able to get past most DDoS mitigation equipment and vulnerability protection services. There are two main types of Layer 7 attacks: Layer 7 denial of service attacks and Layer 7 application vulnerability attacks. Layer 7 Denial of Service Attacks Like Layer 3 and 4 volumetric attacks, Layer 7 denial of service attacks use a high volume of requests to prevent real users from accessing a website. While web properties generally have excess capacity to handle bursts in traffic, Layer 7 denial of service attacks can cause high CPU load and bandwidth consumption. This easily saturates the excess capacity, overwhelming on-premise solutions and most cloud provider network connections. Layer 7 denial of service attacks focus on specific characteristics of web applications that present bottlenecks. For example, the so-called slow read attack sends packets very slowly across multiple connections. Since Apache opens a new thread for each connection, and since connections are maintained as long as there is some traffic being sent, an attacker can overwhelm a web server by exhausting its thread pool relatively easily. CloudFlare protects web properties from Layer 7 denial of service attacks in two ways: Using the intelligence gained from our global network to introduce new layers of protection Offering I m Under Attack Mode for added protection Intelligent Network Protection CloudFlare protects web properties from Layer 7 denial of service attacks by leveraging the intelligence of our global network. With 2 million websites running on our network, CloudFlare sees over a 1 billion unique IP addresses per month. This breadth of web traffic allows us to quickly identify new types of malicious traffic and compromised botnets that are being used in both Layer 7 denial of service and Layer 7 application vulnerability attacks. One way to think about this is that CloudFlare is crowdsourcing threat data across all domain types to create an immune system for the Internet. With each new attack against any one of our customers, our system learns and becomes stronger. This intelligent learning benefits every customer on our network. While all customers get the benefit of the intelligence of the entire network, CloudFlare also has technology that protects specific domains from new attack types. With this technology, we can detect new attacks that arise against any web property in real-time and create rules to stop those attacks without customers having to do anything on their origin server. 9

10 I m Under Attack Mode In the event that CloudFlare s system doesn t learn fast enough, we have an easy to turn on first line of defense called I m Under Attack Mode that takes less than 30 seconds to take effect. Once this setting is enabled, CloudFlare will add an additional set of protections to stop malicious Layer 7 traffic from being passed to your server. I m Under Attack Mode has been designed to avoid blocking search engine crawlers, your existing whitelists, and other pre-vetted traffic. As a result, enabling I m Under Attack Mode when under a DDoS attack will not negatively impact your SEO or known legitimate visitors. Layer 7 application vulnerability attacks Layer 7 attacks are also capable of more targeted actions. Instead of saturating network connections, taking down a DNS server, or exhausting CPU, a Layer 7 attack can also compromise the security of an application. Common Layer 7 application vulnerability attacks are SQL injection and cross-site scripting (XSS) attacks. With an SQL injection attack, an attacker tries to insert a SQL statement into a database. If they succeed, that SQL statement can query the database, retrieve information, and send it back to the attacker. In an XSS attack, attackers try to inject client-side script into a web page. There are a variety of ways this can be problematic. For example, an attacker could insert a piece of JavaScript into a web page so that when a user logs into their account, the attacker s script could send a copy of that username and password to themselves and then pass it on to the server so that the user would never know their information has been stolen. Attackers Your application Visitors Your application Attackers CloudFlare Visitors LAYER 7 DENIAL OF SERVICE ATTACKS (TOP) Attackers use advanced software that mimics real user behavior to overload the slow points in your software. LAYER 7 DENIAL OF SERVICE ATTACKS WITH CLOUDFLARE (BOTTOM) CloudFlare s multi-layered security system detects and blocks advanced attacks before they can overload the slow points in your software. 10

11 Web application firewall (WAF) CloudFlare protects against Layer 7 application vulnerability attacks with our web application firewall (WAF). CloudFlare s WAF is compatible with rules written for Apache ModSecurity but was built from the ground up as a dynamic system that is customizable. Our WAF adds less than 1ms of latency per request which means that for the first time you can get the best in security without any performance tax. In addition to deploying the OWASP Core rule set, CloudFlare has built its own rule sets and can create and deploy new WAF rules on the fly. This means that if a new Layer 7 application vulnerability attack comes up, we can study it, recognize the pattern of the attack, define that pattern in a rule, and instantly protect all of our customers from that vulnerability. With thousands of CloudFlare customers using a variety of web content platforms such as WordPress, Joomla!, and Drupal, we re able to monitor the latest attack vectors targeting these technologies. Once we see an attack directed at one target, we can immediately create and apply WAF rules to protect the customer under attack and then deploy those new rules across our entire network to protect all of our customer s web properties. Any new rule released by CloudFlare will propagate to all of CloudFlare s nodes within 30 seconds. Since CloudFlare can create and deploy WAF rules quickly, we ve been able to protect our customers against major zero-day vulnerabilities. When the Shellshock vulnerability was announced in September 2014, CloudFlare responded by creating and deploying a WAF rule immediately. Before that, in April of 2014 when the Heartbleed bug was discovered, CloudFlare patched the OpenSSL vulnerability for all of our customers giving users breathing room to upgrade their origin servers. We think of this as patching the web in real-time. Making DDoS a thing of the past As technology advances, DDoS attacks will continue to increase in complexity and magnitude. Traditional on-premise DDoS solutions simply can not adapt to the wide range of new attack vectors and are rendered completely ineffective for attacks that exceed an organization s network capacity. CloudFlare s globally distributed network (see image above) and automatic learning platform are designed to keep pace with the changing DDoS threat landscape, ensuring that DDoS attacks are no longer a worry for our customers. We regularly blog about new DDoS attack vectors. If you d like to read about the latest attack types from the front lines of DDoS protection, please visit: blog.cloudflare.com. To learn more about CloudFlare s attack mitigations, contact us at enterprise@cloudflare.com. 11

12 FLARE CloudFlare Inc. All rights reserved. The CloudFlare logo is a trademark of CloudFlare. All other company and product names may be trademarks of the respective companies with which they are associated.