CloudFlare paid subscriptions, including CloudFlare App subscriptions,
are billed monthly, in advance. When you confirm a subscription on
CloudFlare.com, you will be charged at the time of confirmation for
the following one month period (or for the pro-rata remainder of time
in your current billing cycle if you already havean existing
subscription), and on a monthly recurring basis thereafter. When you
downgrade or otherwise cancel an account during a billing period,
thedowngrade or cancellation will take effect at the end of that
billing period.
Note:A cancellation or downgrade from a paid level of service does not
issue an account credit or refund. The billing subscription remains in
place for the 30 day period, but plan features are immediately
downgradedwhen you change plan levels. For example, if you downgrade
from the business plan those features immediately will not be
available, but you can re-upgrade to the business level plan any time
within those 30 days without being charged again.
Wednesday, July 17, 2013
Does CloudFlare accept PayPal?
CloudFlare currently only accepts payments through credit cards. We do
hope to offer support for PayPal in the near future, so we would
recommend following us on one of our social mediato stay updated on
our latest product news and developments.
hope to offer support for PayPal in the near future, so we would
recommend following us on one of our social mediato stay updated on
our latest product news and developments.
How do I become a CloudFlare Hosting Partner?
We would recommend reviewing the information about the CloudFlare
Hosting Partner programfirst. In order to become a CloudFlare
certified partner, you must first fill out the hosting partner formto
request an API key. All requests for a CloudFlare API key will be
responded to within 2 business days, excluding weekends.
Hosting Partner programfirst. In order to become a CloudFlare
certified partner, you must first fill out the hosting partner formto
request an API key. All requests for a CloudFlare API key will be
responded to within 2 business days, excluding weekends.
Are there any discounts on Business and Enterprise pricing?
Business and Enterprise pricing plansdo not give discounts for
multiple domains. All pricing is done on a per domain basis.
multiple domains. All pricing is done on a per domain basis.
How do I contact CloudFlare sales?
Our Sales team can be reached at 888.99.FLARE. Please note that the
number is not for resolving service issues and customers with customer
service issues should create a ticketforsupport assistance.
number is not for resolving service issues and customers with customer
service issues should create a ticketforsupport assistance.
Can CloudFlare protect me against DDoS attacks?
CloudFlare can help mitigate many DDoS attacks against sites. If you
are having issues with DDoS attacks, here are some quick tips that can
help mitigate an attack:
1. Enable CloudFlare's "I'm Under Attack Mode"in your Security
Settings. All CloudFlare Planshave this Basic DDoS Protection
available available in their CloudFlare Security Settings.
Need more advanced DDoS Protection?Please look at CloudFlare's
Business and Enterprise plans.
2. If you don't want to enable "I'm Under Attack Mode", because some
visitors with JavaScript and Cookies disabled won't be able to access
the site, then you can change your Basic Security Level in your
CloudFlare settings to High. A 'High' security settings will challenge
more visitors coming to your site, and will thwart many visits from a
botnet from even hitting your server.
3. If you know which countries are sending most of the bot traffic to
your site, you can block them in your CloudFlare Threat Control panel.
A blockwill challenge all visitors from that country, which means only
visitors that pass the captcha can enter your site. You also have the
option of blocking by individual IP or IP ranges in your Threat
Control panel, if desired.
are having issues with DDoS attacks, here are some quick tips that can
help mitigate an attack:
1. Enable CloudFlare's "I'm Under Attack Mode"in your Security
Settings. All CloudFlare Planshave this Basic DDoS Protection
available available in their CloudFlare Security Settings.
Need more advanced DDoS Protection?Please look at CloudFlare's
Business and Enterprise plans.
2. If you don't want to enable "I'm Under Attack Mode", because some
visitors with JavaScript and Cookies disabled won't be able to access
the site, then you can change your Basic Security Level in your
CloudFlare settings to High. A 'High' security settings will challenge
more visitors coming to your site, and will thwart many visits from a
botnet from even hitting your server.
3. If you know which countries are sending most of the bot traffic to
your site, you can block them in your CloudFlare Threat Control panel.
A blockwill challenge all visitors from that country, which means only
visitors that pass the captcha can enter your site. You also have the
option of blocking by individual IP or IP ranges in your Threat
Control panel, if desired.
What file extensions does CloudFlare cache for static content?
CloudFlare caches the following types of static content by extension
for all account types by default:
*.css
*.js
*.jpg
*.jpeg
*.gif
*.ico
*.png
*.bmp
*.pict
*.csv
*.doc
*.pdf
*.pls
*.ppt
*.tif
*.tiff
*.eps
*.swf
*.midi
*.mid
*.ttf
*.eot
*.woff
*.svg
*.svgz
*.webp
*.docx
*.xlsx
*.xls
*.pptx
*.ps
Note: CloudFlare can only cache resources on your site directly.
External resources (Facebook, Flickr, etc.) will not be cached.
CloudFlare does not cache by MIME type at this time.
for all account types by default:
*.css
*.js
*.jpg
*.jpeg
*.gif
*.ico
*.png
*.bmp
*.pict
*.csv
*.doc
*.pls
*.ppt
*.tif
*.tiff
*.eps
*.swf
*.midi
*.mid
*.ttf
*.eot
*.woff
*.svg
*.svgz
*.webp
*.docx
*.xlsx
*.xls
*.pptx
*.ps
Note: CloudFlare can only cache resources on your site directly.
External resources (Facebook, Flickr, etc.) will not be cached.
CloudFlare does not cache by MIME type at this time.
My website is offline or unavailable?
If CloudFlare can not connect to your server, a "Website Currently
Unavailable, no cached version" message will appear. This error
message occurs in two circumstances:
1.Your server or hosting provider is having issues
2.Your server or hosting provider is nothaving issues, but either your
hosting provider or server is limiting or blocking connections from
CloudFlare IPs
Tips to diagnose if your origin server isoffline
When you see the "Website Currently Unavailable" message, the first
step is to check to see if your origin server is having issues. To do
so, there are two tests that you can run.
Test 1)Try accessing the following subdomain for your website (i.e
yourdomain.com):
direct.yourdomain.com
If you can't get to the site going direct,then the issue is likely
with your serveror hosting provider. In this case, contact your
hosting provider to find out why your origin server is offline.
Note: CloudFlare adds the 'direct' subdomain when you sign up for the
service. It bypasses CloudFlare's network. Some users choose to edit
the name of the subdomain, so if you've changed the name, then you
should replace 'direct' with the revisedsubdomain name.
Test 2)Run the following curl command in Terminal or Putty:
curl -v -H 'Host: yourdomain.com' server IP address
So, as an example:
curl -v -H 'Host: yourdomain.com' 111.111.111.11
Tip: You can get your server IP address from your CloudFlare DNS
Settings page for the domain.
If the curl returns an error message like "can't connect to host" or
"500 internal server error", then the issue iswith your server or
hosting provider. Please contact your hosting provider for assistance.
If the curl returns HTML in the response, then the issue is that your
server or hosting provider has rules in place limiting connections
from CloudFlare IPs.
Proceed to the next section for Troubleshooting Help.
Tips to ensure CloudFlare's IPs are accepted by your server
If your server origin is online, then:
1.Make sure that you're not blocking CloudFlare IPs in .htaccess,
iptables , or your firewall.
2.Make sure your hosting provider isn'trate limiting or blocking IP
requests from the CloudFlare IPs and ask themto whitelist the IP
addresses below:
IPv4
204.93.240.0/24
204.93.177.0/24
199.27.128.0/21
173.245.48.0/20
103.21.244.0/22
103.22.200.0/22
103.31.4.0/22
141.101.64.0/18
108.162.192.0/18
190.93.240.0/20
188.114.96.0/20
197.234.240.0/22
198.41.128.0/17
162.158.0.0/15
IPv6
2400:cb00::/32
2606:4700::/32
2803:f800::/32
2405:b500::/32
2405:8100::/32
3) Make sure that you're operating off of the most recent versions of
Bad Behavior or mod_security. You want to ensure that mod_security's
core rules aren't blocking CloudFlare requests.
4) If you are running custom Apache modules, such asmod_antiloris and
mod_reqtimeout,disable and unload the modules. These modules will
block any time an IP connects more than 22 times. Since all
connections are now coming from a CloudFlare IP, you will definitely
hit the limit causing the error page. As soon as you unload the
module, the issue will disappear.
Unavailable, no cached version" message will appear. This error
message occurs in two circumstances:
1.Your server or hosting provider is having issues
2.Your server or hosting provider is nothaving issues, but either your
hosting provider or server is limiting or blocking connections from
CloudFlare IPs
Tips to diagnose if your origin server isoffline
When you see the "Website Currently Unavailable" message, the first
step is to check to see if your origin server is having issues. To do
so, there are two tests that you can run.
Test 1)Try accessing the following subdomain for your website (i.e
yourdomain.com):
direct.yourdomain.com
If you can't get to the site going direct,then the issue is likely
with your serveror hosting provider. In this case, contact your
hosting provider to find out why your origin server is offline.
Note: CloudFlare adds the 'direct' subdomain when you sign up for the
service. It bypasses CloudFlare's network. Some users choose to edit
the name of the subdomain, so if you've changed the name, then you
should replace 'direct' with the revisedsubdomain name.
Test 2)Run the following curl command in Terminal or Putty:
curl -v -H 'Host: yourdomain.com' server IP address
So, as an example:
curl -v -H 'Host: yourdomain.com' 111.111.111.11
Tip: You can get your server IP address from your CloudFlare DNS
Settings page for the domain.
If the curl returns an error message like "can't connect to host" or
"500 internal server error", then the issue iswith your server or
hosting provider. Please contact your hosting provider for assistance.
If the curl returns HTML in the response, then the issue is that your
server or hosting provider has rules in place limiting connections
from CloudFlare IPs.
Proceed to the next section for Troubleshooting Help.
Tips to ensure CloudFlare's IPs are accepted by your server
If your server origin is online, then:
1.Make sure that you're not blocking CloudFlare IPs in .htaccess,
iptables , or your firewall.
2.Make sure your hosting provider isn'trate limiting or blocking IP
requests from the CloudFlare IPs and ask themto whitelist the IP
addresses below:
IPv4
204.93.240.0/24
204.93.177.0/24
199.27.128.0/21
173.245.48.0/20
103.21.244.0/22
103.22.200.0/22
103.31.4.0/22
141.101.64.0/18
108.162.192.0/18
190.93.240.0/20
188.114.96.0/20
197.234.240.0/22
198.41.128.0/17
162.158.0.0/15
IPv6
2400:cb00::/32
2606:4700::/32
2803:f800::/32
2405:b500::/32
2405:8100::/32
3) Make sure that you're operating off of the most recent versions of
Bad Behavior or mod_security. You want to ensure that mod_security's
core rules aren't blocking CloudFlare requests.
4) If you are running custom Apache modules, such asmod_antiloris and
mod_reqtimeout,disable and unload the modules. These modules will
block any time an IP connects more than 22 times. Since all
connections are now coming from a CloudFlare IP, you will definitely
hit the limit causing the error page. As soon as you unload the
module, the issue will disappear.
CloudFlare will soon start broadcasting from new IP ranges.
CloudFlare will be broadcasting out over new IPs soon. As you may have
issues with your site if you have an outdated version of
mod_cloudflare installed or firewall settings that block IPs, please
make sure that all of CloudFlare's IPsare set to be accepted by your
server.
issues with your site if you have an outdated version of
mod_cloudflare installed or firewall settings that block IPs, please
make sure that all of CloudFlare's IPsare set to be accepted by your
server.
CloudFlare Phishing Alert: Limit Load Email
Some CloudFlare customers are currently being targeted with a phishing
email that was not sent by CloudFlare.Please do not click on the links
in the email.
If you did enter any information on thispage immediately use the
"forgot password" link on the CloudFlare page to reset your password
to a new secure password.
The phishing email states:
Dear cloudflare.com client, costumer (has user Domain.com in it)
Domain account (Domain of website) has exceeded the limit load
available for the existing pay rate plan.
Methods of load analysis and elimination :
(URL removed for obvious reasons)
In order to prevent your account frombeing locked out we recommend
that you change the existing rate plan onto a more powerful one or
limit the server load by means of code optimization.
email that was not sent by CloudFlare.Please do not click on the links
in the email.
If you did enter any information on thispage immediately use the
"forgot password" link on the CloudFlare page to reset your password
to a new secure password.
The phishing email states:
Dear cloudflare.com client, costumer (has user Domain.com in it)
Domain account (Domain of website) has exceeded the limit load
available for the existing pay rate plan.
Methods of load analysis and elimination :
(URL removed for obvious reasons)
In order to prevent your account frombeing locked out we recommend
that you change the existing rate plan onto a more powerful one or
limit the server load by means of code optimization.
CloudFlare's Railgun: Easier Than Ever??
Over the next few days we have a number of announcements regarding
CloudFlare's Railgun technology. We wanted to begin, however, with
what isin some ways the end: the ways in which you can take advantage
of Railgun yourself. Today we're proud to announce two ways in which
you can make your dynamic content faster than was ever possible
before.
Do It Yourself
First, today CloudFlare is announcing version 3.3.3 of Railgun. This
version hasbeen battle tested on high-traffic sites including Imgurand
4chan. It's run billions of requests in a number of different
environments through the new protocol and we're ready to push itout to
the world. To make the process of installing Railgun easy, we've
released RPMs for most the popular Linux and BSD variants including:
*.Ubuntu 12.10
*.Ubuntu 12.04
*.Ubuntu 11.10
*.Ubuntu 10.04
*.FreeBSD 9
*.FreeBSD 8
*.CentOS 6
*.CentOS 5
*.Debian 6
You can download any of these RPMs viathe CloudFlare Downloads page.
In addition, we've released an Amazon Machine Instance (AMI) for
Amazon WebServices that you can install if you want to have you own
Railgun listener. The AMI will be available soon via the AWS AMI
manager.
The largest platform we're missing is Windows Server and we are
working onupdates to the Go runtime in order to allow us to compile
for that platform and meet our quality standards. For the Windows
Server users out there, stay tuned. We haven't forgotten about you.
But Wait, There's More
But that's not the really exciting part. We're extremely excited to
announce that a majority of the world's leading hosting providers are
now supporting CloudFlare's Railgun technology. These 30 hosting
providers have already registered to be CloudFlare Optimized Hosts.
That means you can enable Railgun, usually with a single click and
without having to install any software or change any of your code.
Within the next few days, all of the following hosts will be
supporting CloudFlare's Railgun:
*. 040hosting
*. A2 Hosting
*. Arvixe
*. Bluehost
*. ByetHost
*. CoreCommerce
*. DreamHost
*. ELServer
*. FastDomain
*. GreenGeeks
*. HostPapa
*. HostMonster
*. Just Host
*. InterServer
*. MapleTime
*. (mt) Media Temple
*. MDDHosting
*. NameCheap
*. PacificHost
*. PRO ISP
*. SiteGround
*. Sliqua Enterprise Hosting
*. Softcloud Hosting
*. SparkRed
*. VentraIP
*. VEXXHOST
*. WebHostingBuzz
*. WebHostingPad
*. x10Hosting
*. Zuver
In most cases, if you're already hosted with one of these hosting
providers, getting the benefits of Railgun is free for you. If you're
using one of these hosts, look for an option in your control panel to
enable Railgun. If you're not already using one of these hosts, but
you want to use Railgun, you should either contact your hosting
provider to become a CloudFlare Optimized Partner, or consider
switching to one of the providers above.
Railgun is a revolutionary new protocol that makes dynamic web
performance significantly faster and less bandwidth-intensive than was
ever previously possible. Over the next few days, we'll be releasing
more details about the protocol. In the meantime, we wanted to make
sure you knew where you could go to get Railgun today if you're
interested. Stay tuned for more.
CloudFlare's Railgun technology. We wanted to begin, however, with
what isin some ways the end: the ways in which you can take advantage
of Railgun yourself. Today we're proud to announce two ways in which
you can make your dynamic content faster than was ever possible
before.
Do It Yourself
First, today CloudFlare is announcing version 3.3.3 of Railgun. This
version hasbeen battle tested on high-traffic sites including Imgurand
4chan. It's run billions of requests in a number of different
environments through the new protocol and we're ready to push itout to
the world. To make the process of installing Railgun easy, we've
released RPMs for most the popular Linux and BSD variants including:
*.Ubuntu 12.10
*.Ubuntu 12.04
*.Ubuntu 11.10
*.Ubuntu 10.04
*.FreeBSD 9
*.FreeBSD 8
*.CentOS 6
*.CentOS 5
*.Debian 6
You can download any of these RPMs viathe CloudFlare Downloads page.
In addition, we've released an Amazon Machine Instance (AMI) for
Amazon WebServices that you can install if you want to have you own
Railgun listener. The AMI will be available soon via the AWS AMI
manager.
The largest platform we're missing is Windows Server and we are
working onupdates to the Go runtime in order to allow us to compile
for that platform and meet our quality standards. For the Windows
Server users out there, stay tuned. We haven't forgotten about you.
But Wait, There's More
But that's not the really exciting part. We're extremely excited to
announce that a majority of the world's leading hosting providers are
now supporting CloudFlare's Railgun technology. These 30 hosting
providers have already registered to be CloudFlare Optimized Hosts.
That means you can enable Railgun, usually with a single click and
without having to install any software or change any of your code.
Within the next few days, all of the following hosts will be
supporting CloudFlare's Railgun:
*. 040hosting
*. A2 Hosting
*. Arvixe
*. Bluehost
*. ByetHost
*. CoreCommerce
*. DreamHost
*. ELServer
*. FastDomain
*. GreenGeeks
*. HostPapa
*. HostMonster
*. Just Host
*. InterServer
*. MapleTime
*. (mt) Media Temple
*. MDDHosting
*. NameCheap
*. PacificHost
*. PRO ISP
*. SiteGround
*. Sliqua Enterprise Hosting
*. Softcloud Hosting
*. SparkRed
*. VentraIP
*. VEXXHOST
*. WebHostingBuzz
*. WebHostingPad
*. x10Hosting
*. Zuver
In most cases, if you're already hosted with one of these hosting
providers, getting the benefits of Railgun is free for you. If you're
using one of these hosts, look for an option in your control panel to
enable Railgun. If you're not already using one of these hosts, but
you want to use Railgun, you should either contact your hosting
provider to become a CloudFlare Optimized Partner, or consider
switching to one of the providers above.
Railgun is a revolutionary new protocol that makes dynamic web
performance significantly faster and less bandwidth-intensive than was
ever previously possible. Over the next few days, we'll be releasing
more details about the protocol. In the meantime, we wanted to make
sure you knew where you could go to get Railgun today if you're
interested. Stay tuned for more.
How long does it take for a DNS change I made to push out?
CloudFlare's Automatic TTL is set at 300seconds (5 minutes), so any
changes oradditions you make to your CloudFlare zone file will push
out in 5 minutes or less. Please note that your local DNS cache may
take longer to update and that propagation everywhere may take a
little longer than 5 minutes.
changes oradditions you make to your CloudFlare zone file will push
out in 5 minutes or less. Please note that your local DNS cache may
take longer to update and that propagation everywhere may take a
little longer than 5 minutes.
My website is slow or having performance issues.
Please provide all of the information requested below in a support
ticketto our team so we can look at your issue in a timely manner.
1. The domain in question.
2. What you are using to test. If you areusing a report from an online
reportingtool, for example, please provide us with the URL linking to
the report.
3. Where the slowness is specifically onthe site.
4. A traceroute to your domain so we can see which CloudFlare
datacenter you are hitting. Directions for a traceroute can be found
here: https://support.cloudflare.com/entries
/22050846-how-do-i-run-a-trac...
5. The output of yourdomain.com/cdn- cgi/trace (replace
yourdomain.com with your actual site name).
6. If you have made any changes to your site recently, including
turning CloudFlare features on or off in your settings.
Important: Please check to make sure that requests from CloudFlare's
IPsare being accepted by your server. Performance issues and other
problems can occur when our IPs are either being blocked or rate
limited.
ticketto our team so we can look at your issue in a timely manner.
1. The domain in question.
2. What you are using to test. If you areusing a report from an online
reportingtool, for example, please provide us with the URL linking to
the report.
3. Where the slowness is specifically onthe site.
4. A traceroute to your domain so we can see which CloudFlare
datacenter you are hitting. Directions for a traceroute can be found
here: https://support.cloudflare.com/entries
/22050846-how-do-i-run-a-trac...
5. The output of yourdomain.com/cdn- cgi/trace (replace
yourdomain.com with your actual site name).
6. If you have made any changes to your site recently, including
turning CloudFlare features on or off in your settings.
Important: Please check to make sure that requests from CloudFlare's
IPsare being accepted by your server. Performance issues and other
problems can occur when our IPs are either being blocked or rate
limited.
How to Launch a 65Gbps DDoS, and How to Stop One
Yesterday I posted a post mortem on anoutage we had Saturday. The
outage was caused when we applied an overly aggressive rate limit to
traffic on our network while battling a determined DDoS attacker. In
the process of writing it I mentioned that we'd seen a 65Gbps DDoS
earlier on Saturday. I've received several questions since that all go
something like: "65Gbps DDoS!? Who launches such an attack and how do
youdefend yourself against it?!" So I thought I'd give a bit more
detail.
What Constitutes a Big DDoS?
A 65Gbps DDoS is a big attack, easily in the top 5% of the biggest
attacks we see. The graph below shows the volumeof the attack hitting
our EU data centers(the green line represents inbound traffic). When
an attack is 65Gbps that means every second 65 Gigabits of datais sent
to our network. That's the equivalent data volume of watching 3,400 HD
TV channels all at the same time. It's a ton of data. Most network
connections are measured in 100Mbps, 1Gbps or 10Gbps so attacks like
this would quickly saturate even a large Internet connection.
At CloudFlare, an attack needs to get over about 5Gbps to set off
alarms with our ops team. Even then, our automated network defenses
usually stop attacks without the need of any manual intervention. When
an attack gets up in the tens of Gigabits of data per second, our ops
team starts monitoring the attack: applying filters and shifting
traffic to ensure the attacked customer's site stays online and none
of the rest of our network is affected.
So You Want to Launch a DDoS
So how does an attacker generate 65Gbps of traffic? It is highly
unlikely that the attacker has a single machine with a big enough
Internet connection to generate that much traffic on its own. One way
to generate that much traffic is through a botnet. A botnet is a
collection of PCs that have been compromised with a virus and can be
controlled by what is known as a botnetherder.
Botnet herders will often rent out access to their botnets, often
billing in 15 minute increments (just like lawyers). Rental prices
depend on the size of the botnets. Traditionally, email spammers
purchased time on botnets in order to send their messages to appear to
come from a large number of sources. As email spam has become
lessprofitable with the rise of better spam filters, botnet herders
have increasinglyturned to renting out their networks of compromised
machines to attackers wanting to launch a DDoS attack.
To launch a 65Gbps attack, you'd need a botnet with at least 65,000
compromised machines each capable ofsending 1Mbps of upstream data.
Given that many of these compromised computers are in the developing
world where connections are slower, and many of the machines that make
up part of a botnet may not be online at any given time, the actual
size of the botnet necessary to launch that attack would likely need
to be at least 10x thatsize. While by no means unheard of, that's a
large botnet and using all its resources to launch a DDoS risks ISPs
detecting many of the compromised machines and taking them offline.
Amplifying the Attacks
Since renting a large botnet can be expensive and unwieldy, attackers
typically look for additional ways to amplify the size of their
attacks. The attack on Saturday used one such amplification technique
called DNS reflection. To understand how these work, you need to
understand a bit about how DNS works.
When you first sign up for an Internet connection, your ISP will
provide you with a recursive DNS server, also knownas a DNS resolver.
When you click on a link, your computer sends a lookup to your ISP's
DNS resolver. The lookup is asking a question, like: what is the IP
address of the server for cloudflare.com? If the DNS resolver you
query knows the answer, because someone has already asked it recently
and the answer is cached, it responds. If it doesn't, it passes the
request on to the authoritative DNS for the domain.
Typically, an ISP's DNS resolvers are setup to only answer requests
from the ISP's clients. Unfortunately, there are a large number of
misconfigured DNS resolversthat will accept queries from anyone on
the Internet. These are known as "open resolvers" and they area sort
of latent landmine on the Internet just waiting to explode when
misused.
DNS queries are usually sent via the UDPprotocol. UDP is a
fire-and-forget protocol, meaning that there is no handshake to
establish that where a packet says it is coming from actually is where
it is coming from. This means, if you're an attacker, you can forge
the header of a UDP packet to say it is coming from a particular IP
you want toattack and send that forged packet to an open DNS resolver.
The DNS resolver will reply back with a response to the forged IP
address with an answer to whatever question was asked.
To amplify an attack, the attacker asks a question that will result in
a very large response. For example, the attacker may request all the
DNS records for a particular zone. Or they may request the DNSSEC
records which, often, are extremely large. Since resolvers typically
have relatively high bandwidth connections to the Internet, they have
no problem pumping out tonsof bytes. In other words, the attacker can
send a relatively small UDP request and use open resolvers to fire
back at an intended target with a crippling amount of traffic.
Mitigating DNS Reflection Attacks
One of the great ironies when we deal with these attacks is we'll
often get an email from the owner of the network where an open
resolver is running asking us to shut down the attack our network is
launching against them. They're seeing a large number of UDP packets
with one of our IPs as the source coming in to their network and
assume we're the ones launching it. In fact, it is actually their
network which isbeing used to launch an attack against us. What's
great is that we can safely respond and ask them to block all DNS
requests originating from our network since our IPs should never
originate a DNS request to a resolver. Not only doesthat solve their
problem, but it means there's a smaller pool of open resolvers that
can be used to target sites on CloudFlare's network.
There have been a number of efforts to clean up open resolversthat
are currently active. Unfortunately, it is slow going and the default
installation of many DNS clients still has them open by default. While
we actively reach out to the worst offenders to protect our network,
to protect the Internet generally there will need to be a concerted
effort to clean up open DNS resolvers.
In terms of stopping these attacks, CloudFlare uses a number of
techniques.It starts with our network architecture. We use
Anycastwhich means the response from a resolver, while targeting one
particular IP address, will hit whatever data center is closest.
Thisinherently dilutes the impact of an attack, distributing its
effects across all 23 of our data centers. Given the hundreds of gigs
of capacity we have across our network, even a big attack rarely
saturates a connection.
At each of our facilities we take additional steps to protect
ourselves. We know, for example, that we haven't sent any DNS
inquiries out from our network. We can therefore safely filter the
responses from DNS resolvers: dropping the response packets from
theopen resolvers at our routers or, in some cases, even upstream at
one of our bandwidth providers. The result is that these types of
attacks are relatively easily mitigated.
What was fun to watch was that while the customer under attack was
being targeted by 65Gbps of traffic, not a single packet from that
attack made it to their network or affected their operations. In fact,
CloudFlare stopped the entire attack without the customer even knowing
there was a problem. From the network graph you can see after about 30
minutes the attacker gave up. We think that's pretty cool and,as we
continue to expand our network, we'll get even more resilient to
attacks like this one.
outage was caused when we applied an overly aggressive rate limit to
traffic on our network while battling a determined DDoS attacker. In
the process of writing it I mentioned that we'd seen a 65Gbps DDoS
earlier on Saturday. I've received several questions since that all go
something like: "65Gbps DDoS!? Who launches such an attack and how do
youdefend yourself against it?!" So I thought I'd give a bit more
detail.
What Constitutes a Big DDoS?
A 65Gbps DDoS is a big attack, easily in the top 5% of the biggest
attacks we see. The graph below shows the volumeof the attack hitting
our EU data centers(the green line represents inbound traffic). When
an attack is 65Gbps that means every second 65 Gigabits of datais sent
to our network. That's the equivalent data volume of watching 3,400 HD
TV channels all at the same time. It's a ton of data. Most network
connections are measured in 100Mbps, 1Gbps or 10Gbps so attacks like
this would quickly saturate even a large Internet connection.
At CloudFlare, an attack needs to get over about 5Gbps to set off
alarms with our ops team. Even then, our automated network defenses
usually stop attacks without the need of any manual intervention. When
an attack gets up in the tens of Gigabits of data per second, our ops
team starts monitoring the attack: applying filters and shifting
traffic to ensure the attacked customer's site stays online and none
of the rest of our network is affected.
So You Want to Launch a DDoS
So how does an attacker generate 65Gbps of traffic? It is highly
unlikely that the attacker has a single machine with a big enough
Internet connection to generate that much traffic on its own. One way
to generate that much traffic is through a botnet. A botnet is a
collection of PCs that have been compromised with a virus and can be
controlled by what is known as a botnetherder.
Botnet herders will often rent out access to their botnets, often
billing in 15 minute increments (just like lawyers). Rental prices
depend on the size of the botnets. Traditionally, email spammers
purchased time on botnets in order to send their messages to appear to
come from a large number of sources. As email spam has become
lessprofitable with the rise of better spam filters, botnet herders
have increasinglyturned to renting out their networks of compromised
machines to attackers wanting to launch a DDoS attack.
To launch a 65Gbps attack, you'd need a botnet with at least 65,000
compromised machines each capable ofsending 1Mbps of upstream data.
Given that many of these compromised computers are in the developing
world where connections are slower, and many of the machines that make
up part of a botnet may not be online at any given time, the actual
size of the botnet necessary to launch that attack would likely need
to be at least 10x thatsize. While by no means unheard of, that's a
large botnet and using all its resources to launch a DDoS risks ISPs
detecting many of the compromised machines and taking them offline.
Amplifying the Attacks
Since renting a large botnet can be expensive and unwieldy, attackers
typically look for additional ways to amplify the size of their
attacks. The attack on Saturday used one such amplification technique
called DNS reflection. To understand how these work, you need to
understand a bit about how DNS works.
When you first sign up for an Internet connection, your ISP will
provide you with a recursive DNS server, also knownas a DNS resolver.
When you click on a link, your computer sends a lookup to your ISP's
DNS resolver. The lookup is asking a question, like: what is the IP
address of the server for cloudflare.com? If the DNS resolver you
query knows the answer, because someone has already asked it recently
and the answer is cached, it responds. If it doesn't, it passes the
request on to the authoritative DNS for the domain.
Typically, an ISP's DNS resolvers are setup to only answer requests
from the ISP's clients. Unfortunately, there are a large number of
misconfigured DNS resolversthat will accept queries from anyone on
the Internet. These are known as "open resolvers" and they area sort
of latent landmine on the Internet just waiting to explode when
misused.
DNS queries are usually sent via the UDPprotocol. UDP is a
fire-and-forget protocol, meaning that there is no handshake to
establish that where a packet says it is coming from actually is where
it is coming from. This means, if you're an attacker, you can forge
the header of a UDP packet to say it is coming from a particular IP
you want toattack and send that forged packet to an open DNS resolver.
The DNS resolver will reply back with a response to the forged IP
address with an answer to whatever question was asked.
To amplify an attack, the attacker asks a question that will result in
a very large response. For example, the attacker may request all the
DNS records for a particular zone. Or they may request the DNSSEC
records which, often, are extremely large. Since resolvers typically
have relatively high bandwidth connections to the Internet, they have
no problem pumping out tonsof bytes. In other words, the attacker can
send a relatively small UDP request and use open resolvers to fire
back at an intended target with a crippling amount of traffic.
Mitigating DNS Reflection Attacks
One of the great ironies when we deal with these attacks is we'll
often get an email from the owner of the network where an open
resolver is running asking us to shut down the attack our network is
launching against them. They're seeing a large number of UDP packets
with one of our IPs as the source coming in to their network and
assume we're the ones launching it. In fact, it is actually their
network which isbeing used to launch an attack against us. What's
great is that we can safely respond and ask them to block all DNS
requests originating from our network since our IPs should never
originate a DNS request to a resolver. Not only doesthat solve their
problem, but it means there's a smaller pool of open resolvers that
can be used to target sites on CloudFlare's network.
There have been a number of efforts to clean up open resolversthat
are currently active. Unfortunately, it is slow going and the default
installation of many DNS clients still has them open by default. While
we actively reach out to the worst offenders to protect our network,
to protect the Internet generally there will need to be a concerted
effort to clean up open DNS resolvers.
In terms of stopping these attacks, CloudFlare uses a number of
techniques.It starts with our network architecture. We use
Anycastwhich means the response from a resolver, while targeting one
particular IP address, will hit whatever data center is closest.
Thisinherently dilutes the impact of an attack, distributing its
effects across all 23 of our data centers. Given the hundreds of gigs
of capacity we have across our network, even a big attack rarely
saturates a connection.
At each of our facilities we take additional steps to protect
ourselves. We know, for example, that we haven't sent any DNS
inquiries out from our network. We can therefore safely filter the
responses from DNS resolvers: dropping the response packets from
theopen resolvers at our routers or, in some cases, even upstream at
one of our bandwidth providers. The result is that these types of
attacks are relatively easily mitigated.
What was fun to watch was that while the customer under attack was
being targeted by 65Gbps of traffic, not a single packet from that
attack made it to their network or affected their operations. In fact,
CloudFlare stopped the entire attack without the customer even knowing
there was a problem. From the network graph you can see after about 30
minutes the attacker gave up. We think that's pretty cool and,as we
continue to expand our network, we'll get even more resilient to
attacks like this one.
The DDoS That Almost Broke the Internet
TheNew York Timesthis morning published a story about the Spamhaus
DDoS attack and how CloudFlare helped mitigate it and keep the site
online. TheTimescalls the attack the largest known DDoS attack ever on
the Internet. We wrote about the attack last week. At the time, it
was a large attack, sending 85Gbps of traffic. Since then, the attack
got much worse. Here are some of the technical details of what we've
seen.
Growth Spurt
On Monday, March 18, 2013 Spamhaus contacted CloudFlare regarding an
attack they were seeing against their website spamhaus.org. They
signed up for CloudFlare and we quickly mitigated the attack. The
attack, initially, was approximately 10Gbps generated largely from
open DNS recursors. On March 19, the attack increased in size, peaking
at approximately 90Gbps. The attack fluctuated between 90Gbps and
30Gbps until 01:15 UTC on on March 21.
The attackers were quiet for a day. Then, on March 22 at 18:00 UTC,
the attack resumed, peaking at 120Gbps of traffic hitting our network.
As we discussed in the previous blog post, CloudFlare uses Anycast
technology which spreads the load of a distributed attack across all
our data centers. This allowed us to mitigate the attack without it
affecting Spamhaus or any ofour other customers. The attackers ceased
their attack against the Spamhaus website four hours after it started.
Other than the scale, which was alreadyamong the largest DDoS attacks
we've seen, there was nothing particularly unusual about the attack to
this point. Then the attackers changed their tactics. Rather than
attacking our customers directly, they started going after the network
providers CloudFlare uses for bandwidth. More on that in a second,
first a bit about how the Internet works.
Peering on the Internet
The "inter" in Internet refers to the fact that it is a collection of
independent networks connected together. CloudFlare runs a network,
Google runs a network, and bandwidth providers like Level3, AT&T, and
Cogent run networks. These networks then interconnect through what are
known as peering relationships.
When you surf the web, your browser sends and receives packets of
information. These packets are sent from one network to another. You
can see this by running a traceroute. Here's one from Stanford
University's networkto the New York Times' website ( nytimes.com):
1rtr-servcore1-serv01-webserv.slac.stanford.edu(
134.79.197.130)0.572ms2rtr-core1-p2p-servcore1.slac.stanford.edu(
134.79.252.166)0.796ms3rtr-border1-p2p-core1.slac.stanford.edu(
134.79.252.133)0.536ms4slac-mr2-p2p-rtr-border1.slac.stanford.edu(
192.68.191.245)25.636ms5sunncr5-ip-a-slacmr2.es.net(
134.55.36.21)3.306ms6eqxsjrt1-te-sunncr5.es.net(
134.55.38.146)1.384ms7xe-0-3-0.cr1.sjc2.us.above.net(
64.125.24.1)2.722ms8xe-0-1-0.mpr1.sea1.us.above.net(
64.125.31.17)20.812ms9 209.249.122.125( 209.249.122.125)21.385ms
There are three networks in the above traceroute: stanford.edu,
es.net, and above.net. The request starts at Stanford. Between lines
4 and 5 it passes from Stanford's network to theirpeer es.net. Then,
between lines 6 and 7, it passes from es.net to above.net, which
appears to provide hosting for the New York Times. This means Stanford
has a peering relationship with ES.net. ES.net has a peering
relationship with Above.net. And Above.net provides connectivity for
the New York Times.
CloudFlare connects to a large number of networks. You can get a sense
of some, although not all, of the networks we peer with through a tool
like Hurricane Electric's BGP looking glass. CloudFlare connects to
peers in two ways. First, we connect directly to certain large
carriers and other networks to which we send a large amount of
traffic. In this case, we connect our router directly to the routerat
the border of the other network, usually with a piece of fiber optic
cable. Second, we connect to what are known as Internet Exchanges, IXs
for short, where a number of networks meet in a central point.
Most major cities have an IX. The model for IXs are different in
different parts of the world. Europe runs some of the most robust IXs,
and CloudFlare connects to several of them including LINX (the London
Internet Exchange), AMS-IX (the Amsterdam Internet Exchange), and
DE-CIX (the Frankfurt Internet Exchange), among others. The major
networks that make up the Internet --Google, Facebook Yahoo, etc. --
connect to these same exchanges to pass traffic between each other
efficiently. When the Spamhaus attacker realized he couldn't go after
CloudFlare directly, he began targeting our upstream peers and
exchanges.
Headwaters
Once the attackers realized they couldn't knock CloudFlare itself
offline even with more than 100Gbps of DDoS traffic, they went after
our direct peers.In this case, they attacked the providersfrom whom
CloudFlare buys bandwidth. We, primarily, contract with what are known
as Tier 2 providers for CloudFlare's paid bandwidth. These companies
peer with other providers and also buy bandwidth from so-called Tier 1
providers.
There are approximately a dozen Tier 1 providerson the Internet. The
nature of these providers is that they don't buy bandwidth from
anyone. Instead, they engage in what is known as settlement-free
peering with the other Tier 1 providers. Tier 2 providers interconnect
with each other and then buy bandwidth from the Tier 1 providers in
order to ensure they can connect to every other point on the Internet.
At the core of the Internet, if all else fails, it is these Tier 1
providers that ensure that every network is connected to every other
network. If one of them fails, it's a big deal.
Anycast means that if the attacker attacked the last step in the
traceroute then their attack would be spread across CloudFlare's
worldwide network, so instead they attacked the second to last step
which concentrated the attackon one single point. This wouldn't cause
a network-wide outage, but it could potentially cause regional
problems.
We carefully select our bandwidth providers to ensure they have the
ability to deal with attacks like this. Our direct peers quickly
filtered attack traffic at their edge. This pushed the attack upstream
to their direct peers, largely Tier 1 networks. Tier 1 networks don't
buy bandwidth from anyone, so the majority of the weight of the
attackended up being carried by them. While we don't have direct
visibility into the traffic loads they saw, we have been told by one
major Tier 1 provider that they saw more than 300Gbps of attack
traffic related to this attack. That wouldmake this attack one of the
largest everreported.
The challenge with attacks at this scale is they risk overwhelming the
systems that link together the Internet itself. The largest routers
that you can buy have, at most, 100Gbps ports. It is possible to bond
more than one of these ports together to create capacity that is
greater than 100Gbps however, at some point, there are limits to how
much these routers can handle. If that limit is exceeded then the
network becomes congested and slows down.
Over the last few days, as these attacks have increased, we've seen
congestion across several major Tier 1s, primarily in Europe where
most of the attacks were concentrated, that would have affected
hundreds of millions of people even as they surfed sites unrelated to
Spamhaus or CloudFlare. If the Internet felt a bit more sluggish for
you over the last few days in Europe, this may be part of the reason
why.
Attacks on the IXs
In addition to CloudFlare's direct peers, we also connect with other
networks over the so-called Internet Exchanges (IXs). These IXs are,
at their most basic level, switches into which multiple networks
connect and can then pass bandwidth. In Europe, these IXs are run as
non-profit entities and are considered critical infrastructure. They
interconnect hundreds of the world's largest networks including
CloudFlare, Google, Facebook, and just about every other major
Internet company.
Beyond attacking CloudFlare's direct peers, the attackers also
attacked the core IX infrastructure on the London Internet Exchange
(LINX), the Amsterdam Internet Exchange (AMS-IX),the Frankfurt
Internet Exchange (DE-CIX), and the Hong Kong Internet Exchange
(HKIX).From our perspective, the attacks had the largest effect on
LINX which caused impact over the exchange and LINX's systems that
monitor the exchange, as visible through the drop in traffic recorded
by their monitoring systems. (Corrected: see below for original
phrasing.)
The congestion impacted many of the networks on the IXs, including
CloudFlare's. As problems were detectedon the IX, we would route
traffic aroundthem. However, several London-based CloudFlare users
reported intermittent issues over the last several days. This is the
root cause of those problems.
The attacks also exposed some vulnerabilities in the architecture of
some IXs. We, along with many other network security experts, worked
with the team at LINX to better secure themselves. In doing so, we
developed alist of best practices for any IX in order to make them
less vulnerable to attacks.
Two specific suggestions to limit attacks like this involve making it
more difficult to attack the IP addresses that members of the IX use
to interchange traffic between each other. We are working with IXs to
ensure that: 1) these IP addresses should not be announced as routable
across the publicInternet; and 2) packets destined to these IP
addresses should only be permitted from other IX IP addresses. We've
been very impressed with the team at LINX and how quickly they've
worked to implement these changes and add additional security to their
IX and are hopeful other IXs will quickly follow their lead.
The Full Impact of the Open Recursor Problem
At the bottom of this attack we once again find the problem of open
DNS recursors. The attackers were able to generate more than 300Gbps
of traffic likely with a network of their own that only had access
1/100th of that amount of traffic themselves. We've written about how
these mis-configured DNS recursors as a bomb waiting to go offthat
literally threatens the stability of the Internet itself. We've now
seen an attack that begins to illustrate the full extent of the
problem.
While lists of open recursors have been passed around on network
security listsfor the last few years, on Monday the full extent of the
problem was, for the first time, made public. The Open Resolver
Projectmade available the full list of the 21.7 million open resolvers
online in an effort to shut them down.
We'd debated doing the same thing ourselves for some time but worried
about the collateral damage of what would happen if such a list fell
into the hands of the bad guys. The last five dayshave made clear that
the bad guys havethe list of open resolvers and they are getting
increasingly brazen in the attacks they are willing to launch. We are
in full support of the Open Resolver Project and believe it is
incumbent on all network providers to work with theircustomers to
close any open resolvers running on their networks.
Unlike traditional botnets which could only generate limited traffic
because of the modest Internet connections and home PCs they typically
run on, these open resolvers are typically running on big servers with
fat pipes. They are like bazookas and the events of the last week have
shown the damage they cancause. What's troubling is that, compared
with what is possible, this attack may prove to be relatively modest.
As someone in charge of DDoS mitigation at one of the Internet giants
emailed me this weekend: "I've often said we don't have to prepare for
the largest-possible attack, we just have to prepare for the largest
attack the Internet can send without causing massive collateral damage
to others. It looks like you've reached that point,
so...congratulations!"
At CloudFlare one of our goals is to makeDDoS something you only read
about in the history books. We're proud of how our network held up
under such a massive attack and are working with our peers and
partners to ensure that the Internet overall can stand up to the
threats it faces.
Correction: The original sentence about the impact on LINX was "From
our perspective, the attacks had the largesteffect on LINX which for a
little over an hour on March 23 saw the infrastructure serving more
than half ofthe usual 1.5Tbps of peak traffic fail." That was not well
phrased, and has been edited, with notation in place.
DDoS attack and how CloudFlare helped mitigate it and keep the site
online. TheTimescalls the attack the largest known DDoS attack ever on
the Internet. We wrote about the attack last week. At the time, it
was a large attack, sending 85Gbps of traffic. Since then, the attack
got much worse. Here are some of the technical details of what we've
seen.
Growth Spurt
On Monday, March 18, 2013 Spamhaus contacted CloudFlare regarding an
attack they were seeing against their website spamhaus.org. They
signed up for CloudFlare and we quickly mitigated the attack. The
attack, initially, was approximately 10Gbps generated largely from
open DNS recursors. On March 19, the attack increased in size, peaking
at approximately 90Gbps. The attack fluctuated between 90Gbps and
30Gbps until 01:15 UTC on on March 21.
The attackers were quiet for a day. Then, on March 22 at 18:00 UTC,
the attack resumed, peaking at 120Gbps of traffic hitting our network.
As we discussed in the previous blog post, CloudFlare uses Anycast
technology which spreads the load of a distributed attack across all
our data centers. This allowed us to mitigate the attack without it
affecting Spamhaus or any ofour other customers. The attackers ceased
their attack against the Spamhaus website four hours after it started.
Other than the scale, which was alreadyamong the largest DDoS attacks
we've seen, there was nothing particularly unusual about the attack to
this point. Then the attackers changed their tactics. Rather than
attacking our customers directly, they started going after the network
providers CloudFlare uses for bandwidth. More on that in a second,
first a bit about how the Internet works.
Peering on the Internet
The "inter" in Internet refers to the fact that it is a collection of
independent networks connected together. CloudFlare runs a network,
Google runs a network, and bandwidth providers like Level3, AT&T, and
Cogent run networks. These networks then interconnect through what are
known as peering relationships.
When you surf the web, your browser sends and receives packets of
information. These packets are sent from one network to another. You
can see this by running a traceroute. Here's one from Stanford
University's networkto the New York Times' website ( nytimes.com):
1rtr-servcore1-serv01-webserv.slac.stanford.edu(
134.79.197.130)0.572ms2rtr-core1-p2p-servcore1.slac.stanford.edu(
134.79.252.166)0.796ms3rtr-border1-p2p-core1.slac.stanford.edu(
134.79.252.133)0.536ms4slac-mr2-p2p-rtr-border1.slac.stanford.edu(
192.68.191.245)25.636ms5sunncr5-ip-a-slacmr2.es.net(
134.55.36.21)3.306ms6eqxsjrt1-te-sunncr5.es.net(
134.55.38.146)1.384ms7xe-0-3-0.cr1.sjc2.us.above.net(
64.125.24.1)2.722ms8xe-0-1-0.mpr1.sea1.us.above.net(
64.125.31.17)20.812ms9 209.249.122.125( 209.249.122.125)21.385ms
There are three networks in the above traceroute: stanford.edu,
es.net, and above.net. The request starts at Stanford. Between lines
4 and 5 it passes from Stanford's network to theirpeer es.net. Then,
between lines 6 and 7, it passes from es.net to above.net, which
appears to provide hosting for the New York Times. This means Stanford
has a peering relationship with ES.net. ES.net has a peering
relationship with Above.net. And Above.net provides connectivity for
the New York Times.
CloudFlare connects to a large number of networks. You can get a sense
of some, although not all, of the networks we peer with through a tool
like Hurricane Electric's BGP looking glass. CloudFlare connects to
peers in two ways. First, we connect directly to certain large
carriers and other networks to which we send a large amount of
traffic. In this case, we connect our router directly to the routerat
the border of the other network, usually with a piece of fiber optic
cable. Second, we connect to what are known as Internet Exchanges, IXs
for short, where a number of networks meet in a central point.
Most major cities have an IX. The model for IXs are different in
different parts of the world. Europe runs some of the most robust IXs,
and CloudFlare connects to several of them including LINX (the London
Internet Exchange), AMS-IX (the Amsterdam Internet Exchange), and
DE-CIX (the Frankfurt Internet Exchange), among others. The major
networks that make up the Internet --Google, Facebook Yahoo, etc. --
connect to these same exchanges to pass traffic between each other
efficiently. When the Spamhaus attacker realized he couldn't go after
CloudFlare directly, he began targeting our upstream peers and
exchanges.
Headwaters
Once the attackers realized they couldn't knock CloudFlare itself
offline even with more than 100Gbps of DDoS traffic, they went after
our direct peers.In this case, they attacked the providersfrom whom
CloudFlare buys bandwidth. We, primarily, contract with what are known
as Tier 2 providers for CloudFlare's paid bandwidth. These companies
peer with other providers and also buy bandwidth from so-called Tier 1
providers.
There are approximately a dozen Tier 1 providerson the Internet. The
nature of these providers is that they don't buy bandwidth from
anyone. Instead, they engage in what is known as settlement-free
peering with the other Tier 1 providers. Tier 2 providers interconnect
with each other and then buy bandwidth from the Tier 1 providers in
order to ensure they can connect to every other point on the Internet.
At the core of the Internet, if all else fails, it is these Tier 1
providers that ensure that every network is connected to every other
network. If one of them fails, it's a big deal.
Anycast means that if the attacker attacked the last step in the
traceroute then their attack would be spread across CloudFlare's
worldwide network, so instead they attacked the second to last step
which concentrated the attackon one single point. This wouldn't cause
a network-wide outage, but it could potentially cause regional
problems.
We carefully select our bandwidth providers to ensure they have the
ability to deal with attacks like this. Our direct peers quickly
filtered attack traffic at their edge. This pushed the attack upstream
to their direct peers, largely Tier 1 networks. Tier 1 networks don't
buy bandwidth from anyone, so the majority of the weight of the
attackended up being carried by them. While we don't have direct
visibility into the traffic loads they saw, we have been told by one
major Tier 1 provider that they saw more than 300Gbps of attack
traffic related to this attack. That wouldmake this attack one of the
largest everreported.
The challenge with attacks at this scale is they risk overwhelming the
systems that link together the Internet itself. The largest routers
that you can buy have, at most, 100Gbps ports. It is possible to bond
more than one of these ports together to create capacity that is
greater than 100Gbps however, at some point, there are limits to how
much these routers can handle. If that limit is exceeded then the
network becomes congested and slows down.
Over the last few days, as these attacks have increased, we've seen
congestion across several major Tier 1s, primarily in Europe where
most of the attacks were concentrated, that would have affected
hundreds of millions of people even as they surfed sites unrelated to
Spamhaus or CloudFlare. If the Internet felt a bit more sluggish for
you over the last few days in Europe, this may be part of the reason
why.
Attacks on the IXs
In addition to CloudFlare's direct peers, we also connect with other
networks over the so-called Internet Exchanges (IXs). These IXs are,
at their most basic level, switches into which multiple networks
connect and can then pass bandwidth. In Europe, these IXs are run as
non-profit entities and are considered critical infrastructure. They
interconnect hundreds of the world's largest networks including
CloudFlare, Google, Facebook, and just about every other major
Internet company.
Beyond attacking CloudFlare's direct peers, the attackers also
attacked the core IX infrastructure on the London Internet Exchange
(LINX), the Amsterdam Internet Exchange (AMS-IX),the Frankfurt
Internet Exchange (DE-CIX), and the Hong Kong Internet Exchange
(HKIX).From our perspective, the attacks had the largest effect on
LINX which caused impact over the exchange and LINX's systems that
monitor the exchange, as visible through the drop in traffic recorded
by their monitoring systems. (Corrected: see below for original
phrasing.)
The congestion impacted many of the networks on the IXs, including
CloudFlare's. As problems were detectedon the IX, we would route
traffic aroundthem. However, several London-based CloudFlare users
reported intermittent issues over the last several days. This is the
root cause of those problems.
The attacks also exposed some vulnerabilities in the architecture of
some IXs. We, along with many other network security experts, worked
with the team at LINX to better secure themselves. In doing so, we
developed alist of best practices for any IX in order to make them
less vulnerable to attacks.
Two specific suggestions to limit attacks like this involve making it
more difficult to attack the IP addresses that members of the IX use
to interchange traffic between each other. We are working with IXs to
ensure that: 1) these IP addresses should not be announced as routable
across the publicInternet; and 2) packets destined to these IP
addresses should only be permitted from other IX IP addresses. We've
been very impressed with the team at LINX and how quickly they've
worked to implement these changes and add additional security to their
IX and are hopeful other IXs will quickly follow their lead.
The Full Impact of the Open Recursor Problem
At the bottom of this attack we once again find the problem of open
DNS recursors. The attackers were able to generate more than 300Gbps
of traffic likely with a network of their own that only had access
1/100th of that amount of traffic themselves. We've written about how
these mis-configured DNS recursors as a bomb waiting to go offthat
literally threatens the stability of the Internet itself. We've now
seen an attack that begins to illustrate the full extent of the
problem.
While lists of open recursors have been passed around on network
security listsfor the last few years, on Monday the full extent of the
problem was, for the first time, made public. The Open Resolver
Projectmade available the full list of the 21.7 million open resolvers
online in an effort to shut them down.
We'd debated doing the same thing ourselves for some time but worried
about the collateral damage of what would happen if such a list fell
into the hands of the bad guys. The last five dayshave made clear that
the bad guys havethe list of open resolvers and they are getting
increasingly brazen in the attacks they are willing to launch. We are
in full support of the Open Resolver Project and believe it is
incumbent on all network providers to work with theircustomers to
close any open resolvers running on their networks.
Unlike traditional botnets which could only generate limited traffic
because of the modest Internet connections and home PCs they typically
run on, these open resolvers are typically running on big servers with
fat pipes. They are like bazookas and the events of the last week have
shown the damage they cancause. What's troubling is that, compared
with what is possible, this attack may prove to be relatively modest.
As someone in charge of DDoS mitigation at one of the Internet giants
emailed me this weekend: "I've often said we don't have to prepare for
the largest-possible attack, we just have to prepare for the largest
attack the Internet can send without causing massive collateral damage
to others. It looks like you've reached that point,
so...congratulations!"
At CloudFlare one of our goals is to makeDDoS something you only read
about in the history books. We're proud of how our network held up
under such a massive attack and are working with our peers and
partners to ensure that the Internet overall can stand up to the
threats it faces.
Correction: The original sentence about the impact on LINX was "From
our perspective, the attacks had the largesteffect on LINX which for a
little over an hour on March 23 saw the infrastructure serving more
than half ofthe usual 1.5Tbps of peak traffic fail." That was not well
phrased, and has been edited, with notation in place.
CloudFlare advantages for DDoS protection
*.Global, distributed network with 23 points of presence
*.Use of anycast for both DNS and TCP
*.Protection from all types of DDoS attacks
*.Expertise from protecting over 1 million businesses
*.No limit on attack size
*.Predictable pricing; pricing not based on attack size
*.Uptime guarantee
*.Legitimate traffic can still access your content
*.Use of anycast for both DNS and TCP
*.Protection from all types of DDoS attacks
*.Expertise from protecting over 1 million businesses
*.No limit on attack size
*.Predictable pricing; pricing not based on attack size
*.Uptime guarantee
*.Legitimate traffic can still access your content
How do I disable the CloudFlare service?
Overview
The CloudFlare service can easily be disabled for any domain, at any
time, in your AccountCenter.
Instructions
1.Log into your AccountCenter.
2.On theOverviewpage, scroll down toyourAdd-On Servicessection. Click
ontheAdminbutton to the right of yourCloudFlare service, see Figure 1:
Figure 1.
3.Your CloudFlare domains are listed. Click on the orange cloud to the
right of the domain for which you'd like to disable the CloudFlare
service. See Figure 2 below:
NOTE:
Please keep in mind that this may take up to 12 hours. The default TTL
value is 12 hours.
Figure 2:This process can take up to 12 hours to complete.
4.In the pop-up window, click thedisable this domainlink. See Figure 3below:
Figure 3.
5.You will be taken back to yourManage CloudFlarepanel. CloudFlare for
your domain should now be listedas disabled. See Figure 4:
The CloudFlare service can easily be disabled for any domain, at any
time, in your AccountCenter.
Instructions
1.Log into your AccountCenter.
2.On theOverviewpage, scroll down toyourAdd-On Servicessection. Click
ontheAdminbutton to the right of yourCloudFlare service, see Figure 1:
Figure 1.
3.Your CloudFlare domains are listed. Click on the orange cloud to the
right of the domain for which you'd like to disable the CloudFlare
service. See Figure 2 below:
NOTE:
Please keep in mind that this may take up to 12 hours. The default TTL
value is 12 hours.
Figure 2:This process can take up to 12 hours to complete.
4.In the pop-up window, click thedisable this domainlink. See Figure 3below:
Figure 3.
5.You will be taken back to yourManage CloudFlarepanel. CloudFlare for
your domain should now be listedas disabled. See Figure 4:
My WordPress blog is example.com. How can I get CloudFlare to work?
In order to use WordPress, you'll need to update WordPress to use
the"www." subdomain, i.e. www.example.com.
the"www." subdomain, i.e. www.example.com.
Will CloudFlare accelerate and protect a root domain (i.e. example.com)?
CloudFlare can only accelerate and protect CNAMEs. Since root domains
are an A record, we recommend that awebsite forwards its traffic to
'www' through their .htaccess file. If the user does not forward the
traffic, then any traffic to www.example.com will be accelerated and
protected by CloudFlare (and shown in the statistics) and any traffic
to example.com will not be served by CloudFlare. If traffic goes to a
root domain and you want to accelerate and protect the traffic using
CloudFlare, you can add a redirect to 'www' in your .htaccess file
are an A record, we recommend that awebsite forwards its traffic to
'www' through their .htaccess file. If the user does not forward the
traffic, then any traffic to www.example.com will be accelerated and
protected by CloudFlare (and shown in the statistics) and any traffic
to example.com will not be served by CloudFlare. If traffic goes to a
root domain and you want to accelerate and protect the traffic using
CloudFlare, you can add a redirect to 'www' in your .htaccess file
What if I have an SSL certificate?
If the SSL certificate is on a subdomainthat you want to use
CloudFlare, you'll need to upgrade to a paid service through
CloudFlare.
CloudFlare, you'll need to upgrade to a paid service through
CloudFlare.
Overview
Overview
CloudFlare is a performance and security service that (mt) Media
Temple is offering to our customers for free. It is a CDN (content
delivery network) with a security layer.
CloudFlare is a performance and security service that (mt) Media
Temple is offering to our customers for free. It is a CDN (content
delivery network) with a security layer.
4 Reasons why you should be using CloudFlare
a partnership with CloudFlare, where we make it easy for you to
enable CloudFlare on your account to take advantage of the benefits
that CloudFlare offers. If you aren't using CloudFlare on your hosting
account, here's 4 reasons why you should:
1. Increase in Site Performance
We use the best quality hardware and network available, so naturally
our web hosting is already fast…but CloudFlare provides an increase in
website performance through their global CDN (Content Delivery
Network). When enabled, the CDN will automatically cache your static
files (JavaScript, CSS, Images, etc.) on their servers locatedacross
strategic data centers around the world. When a visitor visits your
website hosted with GreenGeeks, CloudFlare's Anycast technology will
load those static files from a server located nearest to the visitor
and your dynamiccontent will load from our servers. This results in
fasterload times due to decreased latency between server and visitor.
Through feedback from customers, we've seenincreases of 50% or
moreonsite performance when CloudFlare is enabled.
2. Built-in Security
Security is a big focus here at GreenGeeks. We do everything to ensure
our servers and customer sites are secure from a server standpoint,
but most website defacement's occur due vulnerabilities in the website
code it self. With CloudFlare, you'll be protected against a range
ofthreats: cross site scripting, SQL injection, comment spam,
excessive bot crawling, email harvesters, and more. This is done
automatically and will stop most attacks without the confusing
configurations that are required with othersecurity plugins and tools.
Simply select your security level fromHigh,Medium,LowandEssentially
Off. CloudFlare will even learn about your site and traffic patterns
and adjust its security on the fly.
Of the sites that are using CloudFlare with our web hosting,
CloudFlarestopped over 200,000 threatsin just one week.
3. Easy to Enable with GreenGeeks
It's dead easy to install, so there's no excuse not to enable
CloudFlare. Here's a video that Lawrence made that shows exactly how
to enable CloudFlare on your GreenGeeks sharedand reseller
hostingaccounts. For our VPSand Dedicated customers, simply contact
our support by opening a ticket from within your GreenGeeks Account
Manager. One of our technicians will install the Plugin for you.
4. It's free!
The basic service which will satisfy most of our customers will
costnada, nothing, zilch!Need I say more?
If you're not using CloudFlare, I strongly recommend that you do. A
faster site and a secure site helps with search engine rankings and
really, your customers will have a much better experience on your
website.
enable CloudFlare on your account to take advantage of the benefits
that CloudFlare offers. If you aren't using CloudFlare on your hosting
account, here's 4 reasons why you should:
1. Increase in Site Performance
We use the best quality hardware and network available, so naturally
our web hosting is already fast…but CloudFlare provides an increase in
website performance through their global CDN (Content Delivery
Network). When enabled, the CDN will automatically cache your static
files (JavaScript, CSS, Images, etc.) on their servers locatedacross
strategic data centers around the world. When a visitor visits your
website hosted with GreenGeeks, CloudFlare's Anycast technology will
load those static files from a server located nearest to the visitor
and your dynamiccontent will load from our servers. This results in
fasterload times due to decreased latency between server and visitor.
Through feedback from customers, we've seenincreases of 50% or
moreonsite performance when CloudFlare is enabled.
2. Built-in Security
Security is a big focus here at GreenGeeks. We do everything to ensure
our servers and customer sites are secure from a server standpoint,
but most website defacement's occur due vulnerabilities in the website
code it self. With CloudFlare, you'll be protected against a range
ofthreats: cross site scripting, SQL injection, comment spam,
excessive bot crawling, email harvesters, and more. This is done
automatically and will stop most attacks without the confusing
configurations that are required with othersecurity plugins and tools.
Simply select your security level fromHigh,Medium,LowandEssentially
Off. CloudFlare will even learn about your site and traffic patterns
and adjust its security on the fly.
Of the sites that are using CloudFlare with our web hosting,
CloudFlarestopped over 200,000 threatsin just one week.
3. Easy to Enable with GreenGeeks
It's dead easy to install, so there's no excuse not to enable
CloudFlare. Here's a video that Lawrence made that shows exactly how
to enable CloudFlare on your GreenGeeks sharedand reseller
hostingaccounts. For our VPSand Dedicated customers, simply contact
our support by opening a ticket from within your GreenGeeks Account
Manager. One of our technicians will install the Plugin for you.
4. It's free!
The basic service which will satisfy most of our customers will
costnada, nothing, zilch!Need I say more?
If you're not using CloudFlare, I strongly recommend that you do. A
faster site and a secure site helps with search engine rankings and
really, your customers will have a much better experience on your
website.
CloudFlare Goes Out for an Hour, Takes 785,000 Sites Offline
The self-described "intelligent global network" provided by Internet
securityand caching service CloudFlare took a coffee break this
morning, forcing a number of the Web's top sites offline for the
better part of an hour or so.Or, as CloudFlare CEO Matthew Prince put
it in today's post-mortem blog post, "CloudFlare effectively dropped
off the Internet." And when he says that, he means it, literally – the
outagealso took CloudFlare's own site offline in addition to sites
like 4chan, Wikileaks, and the other 785,000 or so websites making use
of CloudFlare's services.So, what happened?First up, it's important to
understand what CloudFlare actually does. It servesas an intermediary
of-sorts for those looking to access sites that make use of the
service, caching static pages to speed up load times and using its
anycast DNS capabilities to filter out malicious traffic – like
distributed denial of service attacks – to keep its members' sites
online and unbothered.
as CloudFlare describes:"The nature of CloudFlare's Anycasted network
is that we inherently increasethe surface area to absorb such an
attack. A distributed botnet will have aportion of its denial of
service traffic absorbed by each of our data centers. "According to
CloudFlare, the company noticed a DDOS attack against one of its
member sites early this morning. A member of CloudFlare's operations
team sent out a tweak to CloudFlare's routers that was designed to get
themto drop any packets that appeared to be part of the attack –
identified as packets ranging from 99,971 to 99,985 bytes in
length."Flowspec accepted the rule and relayed it to our edge network.
What should have happened is that no packet should have matched that
rule because no packet was actually that large. What happened instead
is that the routers encountered the rule and then proceeded to consume
all their RAM until they crashed,"Prince wrote."In all cases, we run a
monitoring process that reboots the routers automatically when they
crash. That worked in a few cases. Unfortunately, many of the routers
crashed in such a way that they did not reboot automatically and we
were not able toaccess the routers' management ports. Even though some
data centers came back online initially, they fell back over again
because all the traffic across our entire network hit them and
overloaded their resources."CloudFlare's network and operations teams
ultimately had to remove the aforementioned filter rule from its
routers and have its data center employees manually reboot the
affected routers. For CloudFlare customers protected by service-level
agreements, the company plans to issue credit for today's hour or so
worth of downtime.
securityand caching service CloudFlare took a coffee break this
morning, forcing a number of the Web's top sites offline for the
better part of an hour or so.Or, as CloudFlare CEO Matthew Prince put
it in today's post-mortem blog post, "CloudFlare effectively dropped
off the Internet." And when he says that, he means it, literally – the
outagealso took CloudFlare's own site offline in addition to sites
like 4chan, Wikileaks, and the other 785,000 or so websites making use
of CloudFlare's services.So, what happened?First up, it's important to
understand what CloudFlare actually does. It servesas an intermediary
of-sorts for those looking to access sites that make use of the
service, caching static pages to speed up load times and using its
anycast DNS capabilities to filter out malicious traffic – like
distributed denial of service attacks – to keep its members' sites
online and unbothered.
as CloudFlare describes:"The nature of CloudFlare's Anycasted network
is that we inherently increasethe surface area to absorb such an
attack. A distributed botnet will have aportion of its denial of
service traffic absorbed by each of our data centers. "According to
CloudFlare, the company noticed a DDOS attack against one of its
member sites early this morning. A member of CloudFlare's operations
team sent out a tweak to CloudFlare's routers that was designed to get
themto drop any packets that appeared to be part of the attack –
identified as packets ranging from 99,971 to 99,985 bytes in
length."Flowspec accepted the rule and relayed it to our edge network.
What should have happened is that no packet should have matched that
rule because no packet was actually that large. What happened instead
is that the routers encountered the rule and then proceeded to consume
all their RAM until they crashed,"Prince wrote."In all cases, we run a
monitoring process that reboots the routers automatically when they
crash. That worked in a few cases. Unfortunately, many of the routers
crashed in such a way that they did not reboot automatically and we
were not able toaccess the routers' management ports. Even though some
data centers came back online initially, they fell back over again
because all the traffic across our entire network hit them and
overloaded their resources."CloudFlare's network and operations teams
ultimately had to remove the aforementioned filter rule from its
routers and have its data center employees manually reboot the
affected routers. For CloudFlare customers protected by service-level
agreements, the company plans to issue credit for today's hour or so
worth of downtime.
How to setup CloudFlare in Site5
In this article, we will show you how tosetup CloudFlare for your website.
1) Visit CloudFlareand create an account.
2) Enter the website you wish to add CloudFlare to and click Add website
3) Watch the introduction video while CloudFlare attempts to pull your
current DNS information. Once the scan is complete, click continue.
4) Check your DNS entries and ensure that all the records you need are
included. If you see any missing ones, you can add them at the bottom
of thepage. Once done, click the "I've added all missing records,
continue" button.
5) Select the plan you wish to use. For this article, we will use the
free plan. If you pick any other plan, you will be asked for payment
information on thispage.
6) Select the type of performance and the security level you wish to
use. Oncefinished, click continue.
7) You will now be prompted to updateyour domains DNS name servers.
You can do this by vising your domain registrar. Once you have updated
your name servers, click continue.
That's it! Please keep in mind that it can take time for the DNS name
serverchanges to be picked up by CloudFlare. If CloudFlare does not
pick up the changes right away, you can request that they "re-test"
the account from the websites tab of your CloudFlare account.
We will now go over the basic pages that you can use to manage your site(s).
Apps
You can access the apps section by clicking on the apps link from the
websites section of your CloudFlare account.
Here you can install different applications that range in a variety of purposes.
Analytics
You can access the Analytics section byclicking on the Analytics link
from the websites section of your CloudFlare account.
This section will allow you to see the visitor traffic for your website.
Threat control
You can access the threat control section by clicking on the Threat
control link from the websites section of your CloudFlare account.
This section allows you to monitor possible threats for your
website(s). For example, if a DDoS attack was on-going you would be
able to see it here. You also have the ability to block/white-list IP
address, countries, or ip ranges.
You can also manage the domain itself by clicking the gear icon.
1) Visit CloudFlareand create an account.
2) Enter the website you wish to add CloudFlare to and click Add website
3) Watch the introduction video while CloudFlare attempts to pull your
current DNS information. Once the scan is complete, click continue.
4) Check your DNS entries and ensure that all the records you need are
included. If you see any missing ones, you can add them at the bottom
of thepage. Once done, click the "I've added all missing records,
continue" button.
5) Select the plan you wish to use. For this article, we will use the
free plan. If you pick any other plan, you will be asked for payment
information on thispage.
6) Select the type of performance and the security level you wish to
use. Oncefinished, click continue.
7) You will now be prompted to updateyour domains DNS name servers.
You can do this by vising your domain registrar. Once you have updated
your name servers, click continue.
That's it! Please keep in mind that it can take time for the DNS name
serverchanges to be picked up by CloudFlare. If CloudFlare does not
pick up the changes right away, you can request that they "re-test"
the account from the websites tab of your CloudFlare account.
We will now go over the basic pages that you can use to manage your site(s).
Apps
You can access the apps section by clicking on the apps link from the
websites section of your CloudFlare account.
Here you can install different applications that range in a variety of purposes.
Analytics
You can access the Analytics section byclicking on the Analytics link
from the websites section of your CloudFlare account.
This section will allow you to see the visitor traffic for your website.
Threat control
You can access the threat control section by clicking on the Threat
control link from the websites section of your CloudFlare account.
This section allows you to monitor possible threats for your
website(s). For example, if a DDoS attack was on-going you would be
able to see it here. You also have the ability to block/white-list IP
address, countries, or ip ranges.
You can also manage the domain itself by clicking the gear icon.
CloudFlare accelerates 235,000 websites
Just over two years since its launch, the CloudFlare content
distribution network is being actively used to accelerate traffic to
more than 235,000 websites in Netcraft's Web Server Survey. In total,
we found 785,000 sites currently configured to use CloudFlare's DNS
servers. Once a domain has been configured to use these servers, any
of its subdomains can be routed through the CloudFlare system at the
click of a button. Paying customers can also route their traffic
through CloudFlare by setting up a CNAMEwithin their own DNS.
CloudFlare's network is globally spread across 23 datacenters, half of
which are entirely remotely operated. Nine of these datacenters were
opened during a month-long expansion effort which ended in August and
resulted in a 70% increase in network capacity. CloudFlare's content
distribution network spreads website content around these datacenters,
allowing visitors to request pages from geographically closer
locations. This typically reduces the number of network hops,
resulting in an average request taking less than 30ms.
In addition to moving static files closer to visitors, CloudFlare also
offers an automatic web optimisation feature called Rocket Loader.
This combines multiple JavaScript files into a single request, which
saves both time and bandwidth. Pro, Business and Enterprise users can
also enable beta support for SPDYrequests, which achieve better
latency than HTTP through the use of compression, multiplexing and
prioritisation.
In October, CloudFlare introduced support for OCSP stapling, which it
claims has increased the speed of SSL requests by 30%. The Online
Certificate Status Protocolallows browsers to ask a certificate
authority (CA) whether an SSL certificate it has issued has been
revoked. Handling these requests in realtime can be challenging,
particularly if the CA has issued a large number of certificates, or
has issued certificates to extremely busy websites. OCSP stapling
solves this problem by delivering the OCSP response directly from
CloudFlare's network, removing the need for the browser to perform an
additional DNS lookup and send a request to the CA's own OCSP server.
OCSP performance is often overlooked when considering which CA to buy
a certificate from, but can have a crucial impact on the overall
performance of a customer's website.
With its insight into the kind of requests being sent to many
different websites, CloudFlare is well-positioned to identify
malicious traffic and provide protection to all of its customers.
Depending on which level of security is enabled, CloudFlare can deny
requests which are attempting SQL injection attacks, comment spam,
excessive crawling, email harvesting, or exploiting cross-site
scripting vulnerabilities. Business and Enterpriseusers can also
benefit from CloudFlare's advanced DDoS (distributed denial of
service) protection.
CloudFlare's growth accelerated significantly in the summer of last
year. This is when many people first became aware of the service,
after it was used to handle traffic for the Lulz Securitywebsite.
High profile attacks against Sony, Fox, PBS and the X Factor helped
LulzSec garner 350,000 followers on Twitter, where it extolled the
virtues of using CloudFlare to mitigate DDoS attacks.
distribution network is being actively used to accelerate traffic to
more than 235,000 websites in Netcraft's Web Server Survey. In total,
we found 785,000 sites currently configured to use CloudFlare's DNS
servers. Once a domain has been configured to use these servers, any
of its subdomains can be routed through the CloudFlare system at the
click of a button. Paying customers can also route their traffic
through CloudFlare by setting up a CNAMEwithin their own DNS.
CloudFlare's network is globally spread across 23 datacenters, half of
which are entirely remotely operated. Nine of these datacenters were
opened during a month-long expansion effort which ended in August and
resulted in a 70% increase in network capacity. CloudFlare's content
distribution network spreads website content around these datacenters,
allowing visitors to request pages from geographically closer
locations. This typically reduces the number of network hops,
resulting in an average request taking less than 30ms.
In addition to moving static files closer to visitors, CloudFlare also
offers an automatic web optimisation feature called Rocket Loader.
This combines multiple JavaScript files into a single request, which
saves both time and bandwidth. Pro, Business and Enterprise users can
also enable beta support for SPDYrequests, which achieve better
latency than HTTP through the use of compression, multiplexing and
prioritisation.
In October, CloudFlare introduced support for OCSP stapling, which it
claims has increased the speed of SSL requests by 30%. The Online
Certificate Status Protocolallows browsers to ask a certificate
authority (CA) whether an SSL certificate it has issued has been
revoked. Handling these requests in realtime can be challenging,
particularly if the CA has issued a large number of certificates, or
has issued certificates to extremely busy websites. OCSP stapling
solves this problem by delivering the OCSP response directly from
CloudFlare's network, removing the need for the browser to perform an
additional DNS lookup and send a request to the CA's own OCSP server.
OCSP performance is often overlooked when considering which CA to buy
a certificate from, but can have a crucial impact on the overall
performance of a customer's website.
With its insight into the kind of requests being sent to many
different websites, CloudFlare is well-positioned to identify
malicious traffic and provide protection to all of its customers.
Depending on which level of security is enabled, CloudFlare can deny
requests which are attempting SQL injection attacks, comment spam,
excessive crawling, email harvesting, or exploiting cross-site
scripting vulnerabilities. Business and Enterpriseusers can also
benefit from CloudFlare's advanced DDoS (distributed denial of
service) protection.
CloudFlare's growth accelerated significantly in the summer of last
year. This is when many people first became aware of the service,
after it was used to handle traffic for the Lulz Securitywebsite.
High profile attacks against Sony, Fox, PBS and the X Factor helped
LulzSec garner 350,000 followers on Twitter, where it extolled the
virtues of using CloudFlare to mitigate DDoS attacks.
CloudFlare - Free Reverse Proxy, Firewall, and Global CDN
CloudFlare is a FREE reverse proxy, firewall, and global content
delivery network and can be implemented without installing any server
software or hardware.
On average, CloudFlare-powered websites load 30% faster, use 60% less
bandwidth, and process 65% fewer requests. CloudFlare-powered websites
are protected from many forms of malicious activity including: comment
spam, email harvesting, SQL injection, cross-site scripting, and
DDoS(denial of service) attacks.
That sounds fine and dandy, but can I see the performance of
CloudFlare-enabled site?
Sure, visit my site: Brian Stevenson.
What does this module do?
1.Corrects$_SERVER["REMOTE_ADDR"]so it contains the IP address of your
visitor, not CloudFlare's reverse proxyserver.
2.Integrates with CloudFlare's Threat API so you can ban and whitelist
IP addresses from the Drupal Comment administration screen.
3.Integrates with CloudFlare's Spam API.
4.Integrates with CloudFlare's Client Interface API (planned).
How do I get started with CloudFlare?
1.Visit http://www.cloudflare.comto sign up for a free account.
2.Follow their 5-minute configuration wizard.
Installation Instructions:
1.Install and Enable this module.
2.Add one line of code at the end of your settings.php file:
3.$_SERVER['REMOTE_ADDR'] =$_SERVER["HTTP_CF_CONNECTING_IP"]
?$_SERVER["HTTP_CF_CONNECTING_IP"] :$_SERVER["REMOTE_ADDR"];
4.Save your email address and CloudFlare API key to the CloudFlare
administration screen on your Drupalweb site
(admin/settings/cloudflare).
How do I use this module?:
Presently you can submit Spam reports& ban/whitelist IP addresses from
the Comment Administration section (/admin/content/comment). Look for
the "Update Options" drop down listbox and choose one of the available
CloudFlare Actions.
delivery network and can be implemented without installing any server
software or hardware.
On average, CloudFlare-powered websites load 30% faster, use 60% less
bandwidth, and process 65% fewer requests. CloudFlare-powered websites
are protected from many forms of malicious activity including: comment
spam, email harvesting, SQL injection, cross-site scripting, and
DDoS(denial of service) attacks.
That sounds fine and dandy, but can I see the performance of
CloudFlare-enabled site?
Sure, visit my site: Brian Stevenson.
What does this module do?
1.Corrects$_SERVER["REMOTE_ADDR"]so it contains the IP address of your
visitor, not CloudFlare's reverse proxyserver.
2.Integrates with CloudFlare's Threat API so you can ban and whitelist
IP addresses from the Drupal Comment administration screen.
3.Integrates with CloudFlare's Spam API.
4.Integrates with CloudFlare's Client Interface API (planned).
How do I get started with CloudFlare?
1.Visit http://www.cloudflare.comto sign up for a free account.
2.Follow their 5-minute configuration wizard.
Installation Instructions:
1.Install and Enable this module.
2.Add one line of code at the end of your settings.php file:
3.$_SERVER['REMOTE_ADDR'] =$_SERVER["HTTP_CF_CONNECTING_IP"]
?$_SERVER["HTTP_CF_CONNECTING_IP"] :$_SERVER["REMOTE_ADDR"];
4.Save your email address and CloudFlare API key to the CloudFlare
administration screen on your Drupalweb site
(admin/settings/cloudflare).
How do I use this module?:
Presently you can submit Spam reports& ban/whitelist IP addresses from
the Comment Administration section (/admin/content/comment). Look for
the "Update Options" drop down listbox and choose one of the available
CloudFlare Actions.
CloudFlare
CloudFlare
CloudFlare is a service that does one thing: make websites better.
With a single change to DNS, sites are instantly protected from a wide
range of online threats, see an increase in page load speeds, and have
their content dynamically optimized across the Internet. CloudFlare's
core service is free.
CloudFlare is a service that does one thing: make websites better.
With a single change to DNS, sites are instantly protected from a wide
range of online threats, see an increase in page load speeds, and have
their content dynamically optimized across the Internet. CloudFlare's
core service is free.
General Information
Website cloudflare.com
Blog blog.cloudflare.com
Twitter @cloudflare
Category Other
Phone650-319-8930
Email info@cloudflare.com
Employees 22
Founded7/09
DescriptionPerformance & Security for Any Website
Blog blog.cloudflare.com
Twitter @cloudflare
Category Other
Phone650-319-8930
Email info@cloudflare.com
Employees 22
Founded7/09
DescriptionPerformance & Security for Any Website
Availability and How to Enable
Shared and Reseller plans may enable CloudFlare services via cPanel.
It is also available on VPS and Dedicated Servers upon request, though
it is not currently available on Windows servers.
To enable CloudFlare through cPanel:
1.Log into cPanel.
2.Under theAdvancedsection, click theCloudFlareicon.
1.Click the checkbox to accept the Terms of Service and enter your
email address.
1.ClickCreate Account.
For more information on CloudFlare, visit:
*. http://www.cloudflare.com /faqs.html
*. http://www.projecthoneypot.org/
It is also available on VPS and Dedicated Servers upon request, though
it is not currently available on Windows servers.
To enable CloudFlare through cPanel:
1.Log into cPanel.
2.Under theAdvancedsection, click theCloudFlareicon.
1.Click the checkbox to accept the Terms of Service and enter your
email address.
1.ClickCreate Account.
For more information on CloudFlare, visit:
*. http://www.cloudflare.com /faqs.html
*. http://www.projecthoneypot.org/
Advantages of CloudFlare
There are several advantages to usingthe CloudFlare service.
*.Site Performance Improvement: CloudFlare has proxy servers located
throughout the world. Proxy servers are located closer to your
visitors, which means they will likely see page load speed
improvements as the cached content is delivered fromthe closest
caching box instead of directly off our server. There is a lot of
research that shows the faster the site, the longer a visitor stays.
*.Bot and Threat Protection: CloudFlare uses data from Project Honey
Pot and other third party sources, as well as the data from its
community to identify malicious threats online and stop the attacks
before they even get to your site. You can see which threats are being
stopped through your CloudFlare dashboard here:
https://www.cloudflare.com/your- websites.html
*.Spam Comments Protection: CloudFlare leverages data from thirdparty
resources to reduce the number of spam comments on your site.
*.Alerting Visitors of Infected Computers: CloudFlare alerts human
visitors that have an infected computer that they need to take action
to clean up the malware or virus on their machine. The visitor can
enter a CAPTCHA to gain access to your site.
*.Offline Browsing Mode: In the event that our server is unavailable,
visitors should still be able to access your site since CloudFlare
serves the visitor a page from its cache.
*.Lower CPU Usage: As fewer requests hit our server, the overall CPU
usage of your account is reduced.
*.New Site Stats: CloudFlare gives you insight into search engine
crawlers and threats.
*.Site Performance Improvement: CloudFlare has proxy servers located
throughout the world. Proxy servers are located closer to your
visitors, which means they will likely see page load speed
improvements as the cached content is delivered fromthe closest
caching box instead of directly off our server. There is a lot of
research that shows the faster the site, the longer a visitor stays.
*.Bot and Threat Protection: CloudFlare uses data from Project Honey
Pot and other third party sources, as well as the data from its
community to identify malicious threats online and stop the attacks
before they even get to your site. You can see which threats are being
stopped through your CloudFlare dashboard here:
https://www.cloudflare.com/your- websites.html
*.Spam Comments Protection: CloudFlare leverages data from thirdparty
resources to reduce the number of spam comments on your site.
*.Alerting Visitors of Infected Computers: CloudFlare alerts human
visitors that have an infected computer that they need to take action
to clean up the malware or virus on their machine. The visitor can
enter a CAPTCHA to gain access to your site.
*.Offline Browsing Mode: In the event that our server is unavailable,
visitors should still be able to access your site since CloudFlare
serves the visitor a page from its cache.
*.Lower CPU Usage: As fewer requests hit our server, the overall CPU
usage of your account is reduced.
*.New Site Stats: CloudFlare gives you insight into search engine
crawlers and threats.
How Does it Work?
Once CloudFlare is enabled for your website, it is designated as your
authoritative name servers; this allows CloudFlare to clean and
accelerate your traffic as all requests to your website are now routed
through CloudFlare. With network routing technology and 23 data
centers around the world, CloudFlare is able to:
*.Screen your website's traffic for malicious visitors- CloudFlare
receives requests for your website and analyzes them to determine if a
visitor is a threat based on the visitor's IP, the resource being
requested, the payload being postedand how frequently requests are
being made among other things. Threats are blocked and "good" visitors
are able to quickly access the pages they request.
*.Cache static content on your website- CloudFlare caches static
content on your website like images, JavaScript and CSS, not HTML.
Cached content is refreshed frequently and delivered directly to
visitors from a local CloudFlare data center at an extremely fast
speed. Even when data is not cache-able, CloudFlare is able to respond
to requests just as fast through premium routes.
*.Optimize your web content- Rocket Loader technology is included in
all CloudFlare plans (even the free one) and helps your website to
more efficiently process requests for third party scripts like apps,
widgets and tags. Rocket Loader ensures that no script blocks your
page content fromloading by bundling all script requests into a single
request and loading them one at a time.
authoritative name servers; this allows CloudFlare to clean and
accelerate your traffic as all requests to your website are now routed
through CloudFlare. With network routing technology and 23 data
centers around the world, CloudFlare is able to:
*.Screen your website's traffic for malicious visitors- CloudFlare
receives requests for your website and analyzes them to determine if a
visitor is a threat based on the visitor's IP, the resource being
requested, the payload being postedand how frequently requests are
being made among other things. Threats are blocked and "good" visitors
are able to quickly access the pages they request.
*.Cache static content on your website- CloudFlare caches static
content on your website like images, JavaScript and CSS, not HTML.
Cached content is refreshed frequently and delivered directly to
visitors from a local CloudFlare data center at an extremely fast
speed. Even when data is not cache-able, CloudFlare is able to respond
to requests just as fast through premium routes.
*.Optimize your web content- Rocket Loader technology is included in
all CloudFlare plans (even the free one) and helps your website to
more efficiently process requests for third party scripts like apps,
widgets and tags. Rocket Loader ensures that no script blocks your
page content fromloading by bundling all script requests into a single
request and loading them one at a time.
Subscribe to:
Comments (Atom)