Stratusclear

2022-02-01T10:16:33+00:00

We enjoy working with companies who share a focus on website security. When GamaSec, an online web vulnerability-assessment service, inquired about ways to integrate, we were excited to make their scanning service available as a CloudFlare app, where any CloudFlare customer can easily turn on GamaSec.

GamaSec's cloud-based security scan serves as an early-warning system of defense for web operation, applications, and online information. GamaSec can be used by any website of any size and is now available to all CloudFlare customers: https://www.cloudflare.com/apps/gamasec

Vulnerability Scanning

GamaSec goes beyond signature-based tools to find more "real" vulnerabilities.

The GamaSec Application Vulnerability Scanner identifies application vulnerabilities such as Cross Site Scripting (XSS), SQL injection, and Code Inclusion, as well as site exposure risks. It also ranks threat priority, produces highly graphical, intuitive HTML reports, and indicates site security posture by vulnerabilities and threat exposure.

Benefits of GamaSec

Regular use of GamaSec's on-demand vulnerability assessment service provides the following benefits:

Fully automated scans
Easy dashboard & reporting
Web application SaaS Scanner
Update vulnerability protection
Trusted Website Security Seal
Web Application Scan via Cloud Computing

Plans, pricing and getting started

Like all CloudFlare apps, GamaSec is one-click simple, turned on in a customer's app dashboard.

There are two different plans, including Basic for $7.99 a month, per domain, and Premium for $16.99 a month, per domain, to fit the varied needs of different customers.

Visit the GamaSec app page to learn more and to get signed up!

P.S. GamaSec followed the CloudFlare app development process. CloudFlare is hiring to extend our platform.

2022-02-01T10:16:33+00:00

You care about your website, and you want it to be found. For many visitors, finding your website starts with search engines. Together, Google, Bing, Baidu and others are huge sources of traffic for every website.

The extra speed and security CloudFlare delivers are helpful for search engine ranking, but there are many other factors, including site content, organization and proper promotion.

The newest CloudFlare App, Clearspike automates the search engine optimization (SEO) process to help your website attract more organic search engine traffic.

We know you cared enough to make your website faster and safer. Improving your SEO is a complementary step, and we're pleased to make it easy to use the Clearspike service and tap into the expertise of the Clearspike team for additional benefits.

How it works

Like other CloudFlare Apps, Clearspike is easy to activate, with different levels of service available immediately, and no long-term commitment.

Self-Service Plan: Get custom recommendations and update website yourself. $24 / month.
Automated Plan: Use Clearspike tools to get website optimized automatically. $49 / month.
Do-It-For-Me Plan: Get Clearspike experts to optimize your website. $199 / month.

There's no tricks: the experts at Clearspike capture a wealth of experience in an easy-to-use service which makes their expertise usable and easy to apply.

At every level of service, Clearspike actively reviews your site for possible improvements, making recommendations and giving you tools to take action. The service includes keyword recommendations, page title optimizations, submission to appropriate directories, finding broken links, checking sitemaps and more. Clearspike helps you measure your progress, too, so you can see the return on your investment in SEO.

Try Clearspike now.

P.S. Clearspike made their service available to CloudFlare customers using the app development platform. CloudFlare is hiring to extend the platform.

2022-02-01T10:16:33+00:00

This has been a rough week in the security industry with big attacks and compromises reported at companies from Facebook to Apple. We're therefore happy to end the week with some good news: the web's open resolvers, one of the sources of the biggest DDoS attacks, are getting closed.

Sad State of Affairs

Last October, we wrote a blog post about DDoS amplification attacks. This type of attack makes up some of the largest DDoSs CloudFlare sees, sometimes exceeding 100 gigabits per second (100Gbps). The attacks use DNS resolvers that haven't been properly secured in order to "amplify" the resources of the attacker. An attacker can achieve more than a 50x amplification, meaning that for every byte they are able to generate themselves they can pummel a victim with 50 bytes of garbage data.

The problem stems from misconfigured DNS resolver software (e.g., BIND) that is setup to respond to a query from any IP address. Since DNS requests typically are sent over UDP, which, unlike TCP, does not require a handshake, an attacker can spoof a victim's IP address as the source address in a packet and a misconfigured DNS resolver will happily bombard the victim with responses.

Closing the Open Resolvers

While CloudFlare's network is very good at absorbing even these large attacks, the long term solution for the web is for providers to clean up the open resolvers running on their networks. We wanted to help with that so we engaged in a bit of name-and-shame at the end of the last blog post, listing the networks with the largest number of open resolvers. The good news is it worked: almost four months later our tests show that the number of open resolvers across the Internet is down more than 30%. The chart below shows the progress individual networks have made in cleaning up the problem.

ASN | Network ------- | ---------------------------------- 21844 | THEPLANET-AS - ThePlanet.com 3462 | HINET Data Communication Business Group 36351 | SOFTLAYER - SoftLayer Technologies Inc. 9394 | CRNET CHINA RAILWAY Internet(CRNET) 4713 | OCN NTT Communications Corporation 45595 | PKTELECOM-AS-PK Pakistan 4134 | CHINANET-BACKBONE No.31,Jin-rong Street 33182 | DIMENOC - HostDime.com, Inc. 7018 | ATT-INTERNET4 - AT&T Services, Inc. 24940 | HETZNER-AS Hetzner Online AG RZ 26496 | AS-26496-GO-DADDY-COM-LLC - GoDaddy.com, LLC 20773 | HOSTEUROPE-AS Host Europe GmbH 16276 | OVH OVH Systems 13768 | PEER1 - Peer 1 Network Inc. 14383 | VCS-AS - Virtacore Systems Inc 32613 | IWEB-AS - iWeb Technologies Inc. 23352 | SERVERCENTRAL - Server Central Network 2514 | INFOSPHERE NTT PC Communications, Inc. 2519 | VECTANT VECTANT Ltd. 15003 | NOBIS-TECH - Nobis Technology Group, LLC 22773 | ASN-CXA-ALL-CCI-22773-RDC 6830 | LGI-UPC UPC Broadband Holding B.V. 12322 | PROXAD Free SAS 21788 | NOC - Network Operations Center Inc. 17506 | UCOM UCOM Corp. 6939 | HURRICANE - Hurricane Electric, Inc. 16265 | LEASEWEB LeaseWeb B.V. 3269 | ASN-IBSNAZ Telecom Italia S.p.a. 29550 | SIMPLYTRANSIT Simply Transit Ltd 19262 | VZGNI-TRANSIT - Verizon Online LLC | 10/30/12 | 2/22/13 | % Change ---------------------------- | ------------- | ----------- | ------------ Internet Services, In | 2925 | 2216 | -24% | 2739 | 2213 | -19% | 1075 | 781 | -27% | 1052 | 774 | -26% | 1044 | 722 | -31% Telecom Company Limited | 1030 | 716 | -30% | 970 | 705 | -27% | 940 | 638 | -32% | 934 | 624 | -33% | 872 | 593 | -32% | 855 | 560 | -35% | 835 | 517 | -38% | 803 | 511 | -36% | 707 | 421 | -40% | 596 | 420 | -30% | 585 | 367 | -37% | 577 | 350 | -39% | 561 | 341 | -39% | 531 | 326 | -39% | 521 | 322 | -38% - Cox Communications Inc | 484 | 315 | -35% | 453 | 307 | -32% | 449 | 299 | -33% | 442 | 295 | -33% | 422 | 293 | -31% | 414 | 284 | -31% | 407 | 284 | -30% | 402 | 281 | -30% | 392 | 271 | -31% | 390 | 262 | -33%

Kudos

A few other organizations deserve a special shout out for helping with this effort. The great folks at Team Cymru have been tracking open resolvers and other badness online since before CloudFlare was even an idea. Their consistent efforts in this area have been awesome and we're in the process of partnering with them to help get the word out.

In addition, SoftLayer has been especially vocal and active in spearheading clean up efforts on its network. As they pointed out in a great blog post, because of the size and nature of their network, it's often difficult for them to police the configuration of software their customers run. Even so, they are actively reaching out to customers to educate them about the dangers of running open resolvers on their networks.

We greatly appreciate country CERTs/CSIRTs and various Information Sharing and Analysis Centers (ISACs) reaching out to us offering to get in touch with some of the less responsive network providers.

Going forward, we are happy to provide the IP addresses running open resolvers directly to any network provider that is interested in cleaning up their networks. If you're running a network on the list above, please don't hesitate to reach out to us and we'll get you the data you need to help with cleanup.

2022-02-01T10:16:33+00:00

There is currently a significant attack being launched at a large number of WordPress blogs across the Internet. The attacker is brute force attacking the WordPress administrative portals, using the username "admin" and trying thousands of passwords. It appears a botnet is being used to launch the attack and more than tens of thousands of unique IP addresses have been recorded attempting to hack WordPress installs.

One of the concerns of an attack like this is that the attacker is using a relatively weak botnet of home PCs in order to build a much larger botnet of beefy servers in preparation for a future attack. These larger machines can cause much more damage in DDoS attacks because the servers have large network connections and are capable of generating significant amounts of traffic. This is a similar tactic that was used to build the so-called itsoknoproblembro/Brobot botnet which, in the Fall of 2012, was behind the large attacks on US financial institutions.

Patching the Internet

We just pushed a rule out through CloudFlare's WAF that detects the signature of the attack and stops it. Rather than limiting this to only paying customers, CloudFlare is rolling it out the fix to all our customers automatically, including customers on our free plan. If you are a WordPress user and you are using CloudFlare, you are now protected from this latest brute force attack.

Because CloudFlare sits in front of a significant portion of web requests we have the opportunity to, literally, patch Internet vulnerabilities in realtime. We will be providing information about the attack back to partners who are interested in hardening their internal defenses for customers who are not yet on CloudFlare.

If you are running a WordPress blog and want to ensure you are protected from this attack, you can sign up for CloudFlare's free plan and the protection is automatic. We'll continue to monitor the details of the attack and publish details about what we learn.

2022-02-01T10:16:33+00:00

Almost exactly a year ago, CloudFlare announced a feature called Mirage. Mirage was designed to make the loading of images faster in two primary ways: 1) deliver smaller images for devices with smaller screens; and 2) "lazy load" images only when they appeared in the viewport. Both of these optimizations were designed primarily to accelerate web performance on mobile devices.

Mobile devices present a number of challenges to delivering fast web performance. Because they rely on radio networks, the bandwidth to a mobile phone or tablet is often slow. However, the problem isn't limited to just slow bandwidth. Mobile connections are much more likely to experience "loss." To optimize for mobile performance you need to prioritize the most important data and download it first and you need to minimize the number of individual connections in order to limit the impact of packet loss.

The first version of Mirage was designed to accomplish these goals, but it was relatively naive in the way that it did it. We would store multiple versions of images, which make up the bulk of the data transferred for most websites, and then attempt to deliver the one that best matched the screen size. The problem was that the new versions of the images often weren't perfectly matched for the layout of the page or the size of the screen, especially if the page relied on the image's actual dimensions rather than including dimensions in the tag.

For the last year, we've studied sites using Mirage and taken what we've learned to refine and improve every aspect of the feature. Today we're excited to announce Mirage 2.0 which is designed from the ground up to solve the mobile browsing speed challenge.

Virtualized Images

Mirage 2.0 starts with the idea of image virtualization. When CloudFlare caches an image on our network for a site with Mirage 2.0 enabled, we store two versions. The first version is the full-resolution image, the second is a virtualized image that includes meta data about all the full-resolution image's dimensions but with the image itself is massively reduced in size. The reduced sized version typically as little as 1% the size of the full-resolution image.

If you enable Mirage 2.0, CloudFlare's network modifies the image tags on your page on the fly so they can be loaded by the Virtualized Image Packager ("VIP"). In parallel with the HTML of your page loading, the Mirage 2.0 VIP begins downloading the virtualized images that appear on the page. The VIP will virtualize images served from your own domain as well as images served from third party domains (e.g., Flickr or Imgur). Because the virtualized images have the full-resolution image's dimensions embedded as meta data, the VIP is able to place the images into the browser's DOM correctly sized so the browser can almost immediately begin the process of rendering the page.

Minimizing Requests

Rather than initiating a new request for each image, the VIP is able to stream all the images from CloudFlare's network with a single request. This uses the same mechanism we created for Rocket Loader, our Javascript performance accelerator. This means that even a page with hundreds of images can begin rendering in the browser with as few as two requests. Even users on slow mobile connections can begin interacting with the page immediately, rather than having to wait for all the full-resolution images to load.

After the page is rendered with the virtualized images, the VIP begins to replace them with the full-resolution versions. Since the images are already correctly sized for their tags on the page, the browser does not need to reflow the page as the full-resolution versions are loaded. The VIP prioritizes what full-resolution images to load first based on what images are in the browser's viewport. Visually, images appear to "rez" in, starting as low quality and then coming into sharp focus, similar to how a progressive JPEGs load in a browser.

While you can enable CloudFlare features such as Polish in order to optimize your images, by default Mirage 2.0 does not transcode or otherwise alter the original full-resolution images. The VIP will pull third party content directly from the original servers without passing through CloudFlare's network -- unless, of course, the third part is also using CloudFlare.

Learning Loader

With Mirage 2.0, we've also completely rethought how we detect different browsers and respond to their capabilities. Mirage 2.0 is optimized to be more or less aggressive depending on the capabilities of the browser as well as its connection to the Internet. An iPhone connecting to the web over a wifi network is optimized for different loading priorities than the same device connecting over a cellular network. We even detect the different download speeds of cellular networks from LTE to 3G to Edge and optimize for each connection speed appropriately.

Mirage 2.0 gathers real browsing intelligence from all its connections which we then use to further optimize the VIP's performance. As more sites enable Mirage 2.0 the CloudFlare's systems automatically begins to optimize for the fastest possible browsing experience from any device on any network. In other words, the same way we use data about security threats in order to protect the sites on our network, we are now using data about real user's browsers around the world in order to ensure everyone on the CloudFlare network has the fastest possible site.

Reviews Are In

We've been testing Mirage 2.0 on some of our most image heavy sites that get significant traffic from mobile browsers. The reaction has been terrific: "As one of the largest image sharing sites in the world, speed has always been really important to us," explained Alan Schaaf, founder and CEO of Imgur. "We've invested a lot of time into getting images to load as fast as possible over mobile networks, especially since we've been developing our mobile app, and we've seen great improvements with Mirage 2.0. We're really happy that CloudFlare continues to launch innovative products to ensure pages on Imgur.com load as fast as possible."

You can see Mirage 2.0 in action for yourself in the following video:

Available Now

Mirage 2.0 is currently in beta and will be made available over the next few weeks to all paid CloudFlare accounts, including our lowest level PRO accounts which are priced at only $20/month. Mirage 2.0 will fully replace the original version of Mirage in the following months and users with the old Mirage enabled will be upgraded to the newer, better version. Given the importance of mobile browsing, and the massive performance benefit Mirage 2.0 delivers with a single click, we think it is one of the most compelling features we've ever offered. Give it a try and let us know what you think.

2022-02-01T10:16:33+00:00

The web is one of the greatest inventions of human history because it has made the world more transparent. Fundamentally, that's what the web does: it takes information that was inaccessible and opaque and makes it available and lucid.

At CloudFlare, our mission is to build a better web. We hire great engineers to invent the technical systems that provide anyone a global platform through which to share their ideas. But, beyond the technical, if we are to build a better web, we believe it is also incumbent on us to engage in policy making in furtherance of that mission.

Troubled Waters

It is from this perspective that we have watched the recent disclosures over government Internet surveillance with increasing concern. We are troubled, and I think it is fair to say that the web in general is troubled, at the secrecy surrounding these programs. No sensible person disputes that there is a proper and limited role for law enforcement online. However, the secrecy of this role as it is currently framed, its lack of transparency, strikes against the core of what the web stands for. And it is this secrecy that is fundamentally contrary to CloudFlare's mission.

We need to have a public debate about the extent to which governments should or should not surveil the Internet. But, in order to even begin that debate, first we need to properly understand the current state of affairs.

Muzzled

What's absurd is that, today, the Internet's largest stakeholders are muzzled from disclosing this topic in any sensible way. If we follow the letter of the law, we cannot disclose even the fact that we've received certain kinds of legal orders, let alone their contents or what we've done to challenge them. That's resulted in a sort of Kabuki dance, where Internet giants find themselves forced to parse the meaning of phrases like "direct access," rather than answering their users' legitimate questions about what's going on and how this applies to them and their private data.

Fundamentally, CloudFlare, Google, Microsoft, Twitter, and all the Internet giants are in the business of trust. Revealing our customers' private information to governments or anyone else risks that trust and is therefore something we will always fight vigorously against.

Silent Fight

At CloudFlare, we hold the data our customers trust with us sacrosanct. While, to date, we have never been approached to take part in PRISM or any other similar program, we have on occasion received legal requests we believe are unreasonable. When that has happened, we have challenged them on our customers' behalf—sometimes even going so far as to take the government to court to fight for our customers' rights.

We have great stories to tell about how we've stood up for our customers. Hopefully someday we will be able to tell them.

I am encouraged that, from what I've seen, by in large just arguments can still carry the day. I recognize it doesn't always look that way from the outside, and I am troubled that our courts and governments may be headed in the wrong direction. If the goal is justice, then it is in everyone's best interest that we be as transparent as possible about exactly what is going on. It is time for us to have a public debate, but the first step is to get the most basic facts on the table.

Challenges

When law and technology intersect there have always been challenges. Technology often serves to undercut law and flow around the restrictions law puts in place. Occasionally, at the opposite extreme, technology serves to amplify law and extend its reach beyond where we, as a society, were ever comfortable.

When the laws that gave rise to the FISA court and National Security Letters (NSLs) were passed, only just a decade ago, it was hard to imagine you could record and store every telephone conversation. Today that is conceivable. Without a public vote or any conscious decision, technology has amplified the reach of the law to a place where many of us are no longer comfortable.

It is time for us, as a society, to have a debate about what laws we are comfortable with given today's technology. In order to do that, we need to have a clear and honest accounting of the current state of affairs. And, in order for that to happen, we need to remove the muzzle and allow companies and governments to talk honestly about what is going on.

Next Steps

Today we did a very modest thing: CloudFlare joined with more than 40 other companies and organizations signing a letter calling for greater transparency in law enforcement actions online. This is not the end, but it is a necessary beginning. It is time for us to have a public debate and the first step is getting the basic facts on the table.

President Barack Obama
The White House

Director of National Intelligence James R. Clapper
Office of the Director of National Intelligence

The Honorable Harry Reid
Senate Majority Leader, United States Senate

The Honorable John Boehner
Speaker of the House, United States House of Representatives

The Honorable Patrick J. Leahy
Chairman, Committee on the Judiciary, United States Senate

The Honorable Bob Goodlatte
Chairman, Committee on the Judiciary

The Honorable Dianne Feinstein
Chairman, Senate Permanent Select Committee on Intelligence, United States Senate

The Honorable Mike Rogers
Chairman, House Permanent Select Committee on Intelligence

Attorney General Eric Holder
United States Department of Justice

General Keith Alexander
Director
National Security Agency

The Honorable Mitch McConnell
Senate Minority Leader
United States Senate

The Honorable Nancy Pelosi
House Minority Leader
United States House of Representatives

The Honorable Charles E. Grassley
Ranking Member
Committee on the Judiciary
United States Senate

The Honorable John Conyers, Jr.
Ranking Member
Committee on the Judiciary

The Honorable Saxby Chambliss
Vice Chairman
Senate Permanent Select Committee on Intelligence
United States Senate

The Honorable Dutch Ruppersberger
Ranking Member
House Permanent Select Committee on Intelligence

July 18, 2013

We the undersigned are writing to urge greater transparency around national security-related requests by the US government to Internet, telephone, and web-based service providers for information about their users and subscribers.

First, the US government should ensure that those companies who are entrusted with the privacy and security of their users' data are allowed to regularly report statistics reflecting:

The number of government requests for information about their users made under specific legal authorities such as Section 215 of the USA PATRIOT Act, Section 702 of the FISA Amendments Act, the various National Security Letter (NSL) statutes, and others;
The number of individuals, accounts, or devices for which information was requested under each authority; and
The number of requests under each authority that sought communications content, basic subscriber information, and/or other information.

Second, the government should also augment the annual reporting that is already required by statute by issuing its own regular "transparency report" providing the same information: the total number of requests under specific authorities for specific types of data, and the number of individuals affected by each.

As an initial step, we request that the Department of Justice, on behalf of the relevant executive branch agencies, agree that Internet, telephone, and web-based service providers may publish specific numbers regarding government requests authorized under specific national security authorities, including the Foreign Intelligence Surveillance Act (FISA) and the NSL statutes. We further urge Congress to pass legislation requiring comprehensive transparency reporting by the federal government and clearly allowing for transparency reporting by companies without requiring companies to first seek permission from the government or the FISA Court.

Basic information about how the government uses its various law enforcement-related investigative authorities has been published for years without any apparent disruption to criminal investigations. We seek permission for the same information to be made available regarding the government's national security-related authorities.

This information about how and how often the government is using these legal authorities is important to the American people, who are entitled to have an informed public debate about the appropriateness of those authorities and their use, and to international users of US-based service providers who are concerned about the privacy and security of their communications.

Just as the United States has long been an innovator when it comes to the Internet and products and services that rely upon the Internet, so too should it be an innovator when it comes to creating mechanisms to ensure that government is transparent, accountable, and respectful of civil liberties and human rights. We look forward to working with you to set a standard for transparency reporting that can serve as a positive example for governments across the globe.

Thank you.

Companies
AOL
Apple Inc.
CloudFlare
CREDO Mobile
Digg
Dropbox
Evoca
Facebook
Google
Heyzap
LinkedIn
Meetup
Microsoft
Mozilla
Reddit
salesforce.com
Sonic.net
Stripe
Tumblr
Twitter
Yahoo!
YouNow

Investors
Boston Common Asset Management
Domini Social Investments
F&C Investments
New Atlantic Ventures
Union Square Ventures
Y Combinator

Nonprofit Organizations & Trade Associations
Access
American Booksellers Foundation for Free Expression
American Civil Liberties Union
American Library Association
American Society of News Editors
Americans for Tax Reform
Brennan Center for Justice at NYU Law School
Center for Democracy & Technology
Center for Effective Government
Committee to Protect Journalists
Competitive Enterprise Institute
Computer & Communications Industry Association
The Constitution Project
Demand Progress
Electronic Frontier Foundation
First Amendment Coalition
Foundation for Innovation and Internet Freedom
Freedom to Read Foundation
FreedomWorks
Global Network Initiative
GP-Digital
Human Rights Watch
Internet Association
National Association of Criminal Defense Lawyers
National Coalition Against Censorship
New America Foundation's Open Technology Institute
OpenTheGovernment.org
Project On Government Oversight
Public Knowledge
Reporters Committee for Freedom of The Press
Reporters Without Borders
TechFreedom
Wikimedia Foundation
World Press Freedom Committee

2022-02-01T10:16:33+00:00

One of the many great features that CloudFlare provides is protection from Distributed Denial of Service (DDoS) attacks. A malicious party who wants to make your website or web service unavailable could try to overwhelm it with requests from compromised machines (or bots) all around the world. With a large enough volume of requests, your server may become overloaded and not be able to provide its services to legitimate clients. This is the typical scenario in a denial of service attack.

The attacking machines use the public domain name service (DNS) to look up the IP address that hosts your domain (www.sample.com) and send their traffic to that machine hoping to shut it down.

Signing up for CloudFlare is like taking your number out of the phone book, and putting in CloudFlare’s number under your name. When someone attempts to look up who hosts your domain, DNS will return an IP address in the CloudFlare network. If an attacker tries to take down your site, their traffic will go to CloudFlare machines around the world instead of directly to your web server. The CloudFlare network acts as a filter to block bad traffic and only send legitimate traffic through to your origin server.

Just as removing your phone number from the phone book won't stop telemarketers from calling it, enabling CloudFlare doesn't stop clever attackers who know your IP address from sending traffic to it directly. Just because your origin server's IP address is no longer advertised over DNS, it's still connected to the internet. If your IP address is not kept secret, attackers can bypass the CloudFlare network and attack your servers directly.

Here are some helpful tips to help keep your origin IP secure to protect against clever attackers who want to bypass CloudFlare’s DDoS protection:

Keep all subdomains on CloudFlare

When you sign up for CloudFlare, CloudFlare automatically adds a 'direct' subdomain. The 'direct' subdomain does not get the benefit of the CloudFlare proxy service by default. For maximum security, you should rename the 'direct' subdomain to something that can't be guessed easily or remove it altogether. Otherwise, an attacker can use the subdomain to look up your origin IP address. If you receive email for the domain signed up with CloudFlare use a separate server for mail; if not the MX record would reveal the IP address of your server.

Wildcard subdomains

CloudFlare powers DNS for wildcard subdomains, but only offers the performance and security proxy service for wildcard subdomains at the Enterprise level. As a result, if you are a Free, Pro or Business customer, wildcard subdomain records can not be proxied through CloudFlare and should be removed for DDoS protection. Otherwise, an attacker could use the wildcard subdomains to look up your origin IP.

Review DNS records

None of the DNS records should contain any mention of the origin IP. Take a close look at any SPF and TXT records to make sure they do not contain any information about the origin.

Don't host mail or other services on the same server as your web server

If your mail server hosted by the same IP as your http server, an attacker could find the IP address from an outgoing email. For example, an attacker could send an email to a non-existent email address on your server causing a bounce; the bounce might contain the IP address of your server in its headers.

Never initiate an outbound connection based on user action

If the attacker can get your web server to connect to an arbitrary address, they will reveal your origin IP. Features like "upload from URL" that allow the user to upload a photo from a given URL should be configured so that the server doing the download is not the website origin server. This is important because if an attacker can choose the URL entered, they can set up a web site specifically to monitor who connects to it, or use a public service that monitors the IPs that contact unique URLs.

Information disclosure vulnerabilities

Make sure that your web server and web application are patched against all known information disclosure vulnerabilities.

Change your origin IP once configured for maximum DDoS protection on CloudFlare

DNS records are public domain and there are many places where historical records are archived. These historical DNS records will contain your original IP from before signing up with CloudFlare. If you are a target, the attacker probably already has your previous DNS record.

Additional security resources

If you are concerned about security, review these two documents that outline advanced security steps for CloudFlare users.

Security is tough. Attackers only need to find one flaw or weakness in order to do a lot of damage. Following these steps will help keep your origin IP address private and help CloudFlare prevent DDoS attacks against your site.

2022-02-01T10:16:33+00:00

We just rolled out an update to CloudFlare's Web Application Firewall (WAF). Previously, CloudFlare's WAF has received criticism from people who have tested it and found that it didn't behave as traditional WAFs are expected to. That contrasted with the real world experience of users who saw our WAF virtually eliminate actual web threats. Seemingly paradoxically, all of the following are correct: the criticisms weren't wrong and CloudFlare's original WAF was working as designed. I'll explain below, but first some history.

History

I started working in the Internet security space in 1998. At the time, I was interested in the emerging problem of email spam. The state of the art technology in 1998 for battling spam was an open source project called SpamAssassin. SpamAssassin was a rules-based email filter engine. At a simplistic level, it had a list of things that were likely to appear in spam messages (e.g., the word "viagra"), each with a score. When a new message arrived, it was run through the engine, each hit incremented the score, and a message was considered "spam" if the score exceeded a certain threshold.

This rules-based approach had at least two major flaws. First, it was very difficult to configure because every organization's needs were different. For instance, while "viagra" may have been an indication of spam in many cases, if you were setting up SpamAssassin for the Pfizer corporation (which manufactures the drug) then "viagra" may actually have been an indication of non-spamminess.

Second, the bad guys had access to the same standard rule sets as the good guys. That meant it was easy for them to craft messages that could bypass the filters. Remember spam messages that spelled "viagra" like "v1@6r@"? It turns out that there are 1,300,925,111,156,286,160,896 different ways you can spell the word "viagra". Since the rules based approach to SpamAssassin was brittle, it was easy for attackers to get around the rules.

Enter Heuristics

In 2002, before he started Y Combinator, Paul Graham wrote an influential essay called "A Plan for Spam." The essay suggested that the rules-based approach for email filtering was headed down the wrong path. Instead, Paul argued anti-spam systems should be based on heuristics. Specifically, he outlined a Bayesian statistics-based approach where spam filters could be self-learning based on a statistical calculation of "normal" adjusted for an individual user's feedback marking messages as "spam" and "not spam."

In 2003, after an overwhelming response to his essay, Paul organized the first MIT Anti-Spam Conference. From that conference, many of the companies that would go on to largely solve the email spam problem (at least from the perspective of end users) would emerge. Paul turned out to be right and whatever email program you're using today it is almost guaranteed that a heuristic engine is making the decision on what ends up in your spam folder.

I attended the MIT Anti-Spam Conference for several years and, in 2005, Paul invited me to give a talk on Project Honey Pot which, in many ways, was the open source project that served as the initial inspiration for CloudFlare. The MIT Anti-Spam Conference was also where I first met John Graham-Cumming, who now works on CloudFlare's team and was the principal architect behind our WAF update. More on that in a second, but first a bit about the state of traditional WAFs today.

Traditional WAFs

A decade after the first MIT Spam Conference, the archetype of the traditional WAF is an open source project known as ModSecurity. Most commercial WAFs are based around the same fundamental design. At a simplistic level, ModSecurity has a list of things that are likely to appear in different types of web-based attacks, each with a score. When a new web request arrives, it is run through the ModSecurity engine, each hit increments a score, and then the request is considered a threat if the score exceeds a certain threshold.

Sound familiar? It should, it's the same rules-based approach that SpamAssassin used. It also suffers from the same challenges. It is difficult to configure on a per-organization basis, partially explaining why the market for traditional WAFs has remained remarkably small. Moreover, bad guys have access to the standard rule sets meaning they can craft attacks that easily bypass them.

CloudFlare's WAF

At CloudFlare, we thought we'd skip to the inevitable end of the story and build a WAF based on heuristics from the beginning. Rather than rely on brittle rules, CloudFlare was designed to look at the totality of traffic across all our customers' sites and then use that data to stop actual attacks. We also tailored the protection on a site-by-site basis. For example, a chunk of SQL posted to a site like Stack Exchange may not be a threat while a chunk of SQL posted to a cooking blog may be. At scale, if enough websites used our service, we knew we could provide an extremely high level of effective protection driven by data and heuristics.

That approach has worked. We have more than a million happy users who report that CloudFlare protects them from a wide range of attacks. However, over the last four years we've also realized there is a place for rules.

Some of this is purely marketing. Heuristic-based approaches are notoriously difficult to test. Sign up a new site for CloudFlare and start posting a laundry list of SQL injection attacks from a connection with browsing behavior across other CloudFlare sites that indicates it is not malicious and our systems will tend to come to the conclusion that this is a site covering SQL injection attacks and let the posts through. That actually isn't wrong, but it isn't very useful when you're trying to run a test to see that we block actual attacks. It also complicates tests for "check-the-box" security audits like PCI.

Beyond mere testing, rules also can be good when applied appropriately. We've seen several instances where a new attack will emerge and we deploy a rule to quickly thwart it. While we've had the ability to do that ourselves, we haven't previously allowed our customers, partners (e.g., hosting providers), or trusted security consultants to do the same.

Everything Old Is New Again

We spent the last 6 months building a traditional, rules-based WAF to augment CloudFlare's existing next generation, heuristics-based WAF. The new WAF is included by default with every Pro and better plan ($20/month for the first site, $5/month for each additional site). In the process, we also took the opportunity to rearchitect how some of our security systems work in order to provide more visibility and flexibility. You'll see that increasingly reflected in our UI over the next few months.

When we set out to add a traditional WAF, our design goal was to build a system that was fully user configurable, accepted the existing ModSecurity rule configuration language, added less than 1ms of latency to requests when processing the full OWASP ruleset or its equivalent, would update worldwide within less than 30 seconds of a user configuration change, provided data and feedback on rules as they were triggered, and would scale to handle the billions of requests CloudFlare processes every day. I'm excited to say we exceeded our goal.

The new rules-based WAF is available now and augments the existing heuristics–based WAF. Over the next few weeks we'll be publishing a series of technical blog posts on what went into building a rules-based WAF that is fast, flexible, and can scale to handle CloudFlare's level of traffic. In the meantime, feel free to try out the WAF and let us know what you think.

2022-02-01T10:16:33+00:00

At CloudFlare, we are always looking for better ways to secure the data we’re entrusted with. This means hardening our system against outside threats such as hackers, but it also means protecting against insider threats. According to a recent Verizon report, insider threats account for around 14% of data breaches in 2013. While we perform background checks and carefully screen team members, we also implement technical barriers to protect the data with which we are entrusted.

One good information security practice is known as the “two-man rule.” It comes from military history, where a nuclear missile couldn’t be launched unless two people agreed and turned their launch keys simultaneously. This requirement was introduced in order to prevent one individual from accidentally (or intentionally) starting World War III.

To prevent the risk of rogue employees misusing sensitive data we built a service in Go to enforce the two-person rule. We call the service Red October after the famous scene from “The Hunt for Red October.” In line with our philosophy on security software, we are open sourcing the technology so you can use it in your own organization (here’s a link to the public Github repo). If you are interested in the nitty-gritty details, read on.

What it is

Red October is a cryptographically-secure implementation of the two-person rule to protect sensitive data. From a technical perspective, Red October is a software-based encryption and decryption server. The server can be used to encrypt a payload in such a way that no one individual can decrypt it. The encryption of the payload is cryptographically tied to the credentials of the authorized users.

Authorized persons can delegate their credentials to the server for a period of time. The server can decrypt any previously-encrypted payloads as long as the appropriate number of people have delegated their credentials to the server.

This architecture allows Red October to act as a convenient decryption service. Other systems, including CloudFlare’s build system, can use it for decryption and users can delegate their credentials to the server via a simple web interface. All communication with Red October is encrypted with TLS, ensuring that passwords are not sent in the clear.

How to use it

Setting up a Red October server is simple; all it requires is a locally-readable path and an SSL key pair. After that, all control is handled remotely through a set of JSON-based APIs.

Red October is backed by a database of accounts stored on disk in a portable password vault. The server never stores the account password there, only a salted hash of the password for each account. For each user, the server creates an RSA key pair and encrypts the private key with a key derived from the password and a randomly generated salt using a secure derivation function.

Any administrator can encrypt any piece of data with the encrypt API. This request takes a list of users and the minimum number of users needed to decrypt it. The server returns a somewhat larger piece of data that contains an encrypted version of this data. The encrypted data can then be stored elsewhere.

This data can later be decrypted with the decrypt API, but only if enough people have delegated their credentials to the server. The delegation API lets a user grant permission to a server to use their credentials for a limited amount of time and a limited number of uses.

Cryptographic Design

Red October was designed from cryptographic first principles, combining trusted and understood algorithms in known ways. CloudFlare is also opening the source of the server to allow others to analyze its design.

Red October is based on combinatorial techniques and trusted cryptographic primitives. We investigated using complicated secret primitives like Shamir's sharing scheme, but we found that a simpler combinatorial approach based on primitives from Go's standard library was preferable to implementing a mathematical algorithm from scratch. Red October uses 128-bit AES, 2048-bit RSA and scrypt as its cryptographic primitives.

Creating an account

Each user is assigned a unique, randomly-generated RSA key pair when creating an account on a Red October server. The private key is encrypted with a password key derived from the user’s password and salt using scrypt. The public key is stored unencrypted in the vault with the encrypted private key.

Encrypting data

When asked to encrypt a piece of data, the server generates a random 128-bit AES key. This key is used to encrypt the data. For each user that is allowed to decrypt the data, a user-specific key encryption key is chosen. For each unique pair of users, the data key is doubly encrypted, once with the key encryption key of each user. The key encryption keys are then encrypted with the public RSA key associated with their account. The encrypted data, the set of doubly-encrypted data keys, and the RSA-encrypted key encryption keys are all bundled together and returned. The encrypted data is never stored on the server.

Delegating credentials to the server

When a user delegates their key to the server, they submit their username and password over TLS using the delegate JSON API. For each account, the password is verified against the salted hash. If the password is correct, a password key is derived from the password and used to decrypt the user’s RSA private key. This key is now “Live” for the length of time and number of decryptions chosen by the user.

Decrypting data

To decrypt a file, the server validates that the requesting user is an administrator and has the correct password. If two users of the list of valid users have delegated their keys, then decryption can occur. First the RSA private key is used to decrypt the key encryption key for these two users, then the key encryption keys are used to decrypt the doubly encrypted data key, which is then used to decrypt the data.

Some other key points:

Cryptographic security. The Red October server does not have the ability to decrypt user keys without their password. This prevents someone with access to the vault from decrypting data.
Password flexibility. Passwords can be changed without changing the encryption of a given file. Key encryption keys ensure that password changes are decoupled from data encryption keys.

Looking ahead

The version of Red October we are releasing to GitHub is in beta. It is licensed under the 3-clause BSD license. We plan to continue to release our improvements to the open source community. Here is the project on GitHub: Red October.

Writing the server in Go allowed us to design the different components of this server in a modular way. Our hope is this modularity will make it easy for anyone to build in support for different authentication methods that are not based on passwords (for example, TLS client certificates, time-based one-time-passwords) and new core cryptographic primitives (for example, elliptic curve cryptography).

CloudFlare is always looking to improve the state of security on the Internet. It is important to us to share our advances with the world and contribute back to the community. See the CloudFlare GitHub page for the list of our open source projects and initiatives.

2022-02-01T10:16:33+00:00

There has been a lot of news lately about nefarious-sounding backdoors being inserted into cryptographic standards and toolkits. One algorithm, a pseudo-random bit generator, Dual_EC_DRBG, was ratified by the National Institute of Standards and Technology (NIST) in 2007 and is attracting a lot of attention for having a potential backdoor. This is the algorithm into which the NSA allegedly inserted a backdoor and then paid RSA to use.

So how is that possible? This is a technical primer that explains what a backdoor is, how easy it can be to create your own, and the dangerous consequences of using a random number generator that was designed to have a backdoor. This is necessarily a long technical discussion, but hopefully by the end it should be clear why Dual_EC_DRBG has such a bad reputation.

Backdoors

The concept of a backdoor has cast a shadow over the security industry for a long time. A backdoor is an intentional flaw in a cryptographic algorithm or implementation that allows an individual to bypass the security mechanisms the system was designed to enforce. A backdoor is a way for someone to get something out of the system that they otherwise would not be able to. If a security system is wall, a backdoor is a secret tunnel underneath it.

Backdoors can be inserted by lazy programmers who want to bypass their own security systems for debugging reasons, or they can be created to intentionally weaken a system used by others. Government agencies have been known to insert backdoors into commonly used software to enable mass surveillance. Backdoors can be built into software, hardware, or even built into the design of an algorithm.

In theory, a well-designed cryptographic system does not include a backdoor. In practice, it is hard to guarantee that a piece of software is backdoor-free. A backdoor was recently found in a widely-deployed version of D-Link router firmware. The backdoor allows anyone with knowledge of a secret user agent string to log in and modify settings on any router running the vulnerable software. The D-Link backdoor took a long time to find because the source code for the router software was not available to security researchers to examine. With open source software, a researcher can look directly at the part of the code that verifies authentication and check for backdoors.

Open source is great tool for understanding how code works but it is not a cure-all for finding backdoors in software. It can be difficult and time-consuming to fully analyze all the code in a complicated codebase. The International Obfuscated C Code Contest shows how code can be made extremely hard to understand. The Underhanded C Contest takes this even further, showing that benign looking code can hide malicious behavior.

The translation step between human programming languages and machine code can also be used to insert a backdoor. The classic article "Reflections on Trusting Trust" introduced this idea back in 1984. The cryptographic community has recently banded together to audit the open source disk encryption software TrueCrypt for backdoors. One of the key steps in this audit is verifying that the machine code distributed online for TrueCrypt matches the source code. This requires re-building the audited source code with a fully open source compiler and making sure the machine code matches. Reproducible binaries help demonstrate that a backdoor was not inserted in the program's machine code by a malicious person or compiler.

Random weakness

In some cases, even this might not be enough. For example, TrueCrypt, like most cryptographic systems, use the system's random number generator to create secret keys. If an attacker can control or predict the random numbers produced by a system, they can often break otherwise secure cryptographic algorithms. Any predictability in a system's random number generator can render it vulnerable to attacks.

Examples of security systems being bypassed using flaws (intentionally created or otherwise) in random number generators are very common. Some recent examples:

A flaw in a random number generator allowed people to hijack Hacker News accounts.
A broken random number generator in Android allowed attackers to hijack thousands of dollars worth of bitcoins.
The version of OpenSSL on the Debian distribution had a random number generator problem that could allow attackers to guess private keys created on these systems

It's absolutely essential to have an unpredictable source of random numbers in secure systems that rely on them. This includes SSL/TLS, the fundamental security layer of the internet where session keys are generated using random numbers. If you design a random number generator that allows you to predict the output, and convince someone to use it, you can break their system. This kind of algorithmic backdoor is what we will create in this blog post.

A random stream that isn't

The digits of pi are quite random looking but they don't make a very good random number generator because they are predictable. Anyone who knows that someone is using the digits of pi as their source of randomness can use that against them. Convincing someone to use a pi-based random number generator is a difficult challenge.

Many pseudo-random number generators start with a number called a seed. The seed is the starting point for the internal state of the algorithm. The algorithm generates a stream of random numbers using some mathematical operation on the internal state. As long as the seed (and the subsequent internal state) are kept secret, the pseudo-random numbers output by the algorithm are unpredictable to any observer. Conversely, anyone who knows the state will be able to predict the output.

Linux uses a pool of numbers as the internal state of /dev/random, its pseudo-random number generator. Every time a program requests random data from the system, Linux returns a cryptographic hash of its internal state using the algorithm SHA-1. This hash function is designed to be one-way, it is easy to compute but very difficult to find the input given an output. It is so difficult, no person has ever published an inversion of a SHA-1 hash without knowing the input beforehand. This keeps the internal state of the random number generator secret.

The random data extracted by the hash function is then mixed back into internal state. Periodically, the hashes of the timestamps of "unpredictable" system events like clicks and key presses are also mixed in.

Here's a diagram of the basic pseudo-random number generator construction:

In this diagram
F = SHA1
and G = SHA1 + mix with XOR

This construction is pretty standard. The internal state is kept secret, data is output via a one-way function, and the internal state is updated by mixing the data back into the state.

At any point, if an attacker can figure out the internal state, they can predict the output. The strategic choices for F and G here are what make this construction safe. You do not lose the randomness in the pool by XOR-ing with something else, entropy always goes up.

If F and G were chosen to be two completely independent one-way functions, it would probably still be safe. Having SHA-1 as F and MD5 (a different hash function) as G would not be too unreasonable of a choice. The key here is in the word independent, but first a sidestep into elliptic curves.

Elliptic Curves and one-way functions

In a previous blog post we gave a gentle introduction to elliptic curve cryptography. We talked about how this class of curves can be used for encryption and digital signature algorithms. We also hinted that elliptic curves could be used for generating random numbers. That is what we we will describe here.

The reason elliptic curves are used in cryptography is the strongly one-way function they enable. As described previously, there is a geometrically intuitive way to define an arithmetic on the points of an elliptic curve.

Any two points on an elliptic curve can be "dotted" ("multiplied") together to get a new point on the curve. Dotting a point with itself any number of times is fast easy to do, but going back to the original point takes a lot of computation. This operation can be used to create a nice and simple one-way function from a point P1:

Given a number n, output another number m:

Dot P1 with itself n times to get another point Q
Output the x-coordinate of Q as m

It's hard to go back from m to n, because that would be enough to solve the elliptic curve discrete logarithm problem, which is thought to be very, very hard to do.

The metaphor used in the previous post was that the one way function in elliptic curves is like playing a peculiar game of billiards. If someone were locked alone in a room they could play a certain number of shots and the ball would end up at a particular location. However, if you entered the room at some point and simply saw the position of the ball it would be very difficult to determine the number of shots the player had taken without playing through the whole game again yourself.

With this billiards analogy, we can think of this random number generator as a new bizarro game of pool. Consider two balls on the infinite elliptic curve billiards table, the yellow ball called P1 and the blue ball called P2.

These two balls have specific points on the curve where they start. This is a two person game where one person is called the generator and the other is the observer. The generator has a secret number "n". The generator takes the ball P1 and performs n shots, and lets the observer see its final location. Then it takes P2 and performs n shots, taking the final location of P2 as a new value for n. Then P1 and P2 are reset to their original location and that's the end of the turn. Each turn the observer sees a new pseudo-random location for P1, and that's the output of the game.

There's a trap door in your one-way functions

In the Linux random number generator example above, SHA-1 is used as the one-way function. Let's consider what happens when we use our elliptic curve one way function instead.

Looking back at the construction for a pseudo-random number generator above, we need to choose two functions to serve as F and G. The elliptic curve one-way function above seems to fit the bill, so let's use the functions defined by two points on the curve, P1 and P2. Each one-way function is hard to reverse, and if P1 and P2 are chosen randomly, they should be independent.

So how do we add a backdoor? The key is to choose P1 and P2 so that to any outside observer they look random and independent, but in reality they have a special relationship that only we know.

Suppose we choose P2 to be P1 dotted with itself s times, where s is secret number. Then P1 and P2 are related but it is hard to prove how since finding s requires solving the elliptic curve discrete logarithm problem.

Given an initial state n, let's look at what the output becomes and what the state gets updated to.

The output is the x-coordinate of:

Q = P1 ◦ P1 ◦ … ◦ P1 (n times)

Then we get that the state S gets updated to:

P2 ◦ P2 ◦ … ◦ P2 (n times)

But P2 is just P1 dotted with itself s times, so the state is really

(P1 ◦ P1 ◦ … ◦ P1 (s times)) ◦ … ◦ (P1 ◦ P1 ◦ … ◦ P1 (s times)) (n times)
P1 ◦ P1 ◦ … ◦ P1 (s ◦ n times)
or re-arranged
(P1 ◦ P1 ◦ … ◦ P1 (n times)) ◦ … ◦ (P1 ◦ P1 ◦ … ◦ P1 (n times)) (s times)

Seeing that P1 dotted with itself n times is the output Q, we can write this as:
Q ◦ Q ◦ … ◦ Q (s times)

And since we know s and the output (and therefore Q), we can calculate the next internal state of the algorithm. The state is revealed and all subsequent bytes can be predicted. In just one round! Since given P1 and P2, finding s requires solving the discrete logarithm problem, you get to be the only one who knows this mathematical backdoor.

This can be described in the terms of the billiards game from the last section. Remember the output of one turn of the game is the location of P1 after n shots and generator's secret number comes from the location of P2 after n shots. Knowing the value s is like knowing how many shots it takes to go from P1 to P2. This lets the observer cheat at the game. If you know where P1 lands after n shots, you can shoot s times from that location to get the location of P2 after n shots. This gives you the generator's secret number and allows you to predict the next turn of the game.

Back to the real world

This toy random number generator may seem very simple and the backdoor might even seem obvious. The amazing fact is that our toy random number generator described above is Dual_EC_DRBG, almost exactly. It was published by the NSA with two "random" looking points P1 and P2. There is no indication of how these values were generated.

The values for the points P1 and P2 could have been chosen randomly or they could have been chosen with a deliberate relationship. If they were chosen deliberately, there is a backdoor. If they truly were chosen randomly, then finding the internal state is as difficult as breaking elliptic curve cryptography. Unfortunately, there is no way to identify if the two points were chosen together or randomly without either solving the elliptic curve discrete logarithm function, or catching the algorithm's author with the secret backdoor value. This is the nature of a one-way trapdoor function.

The authors did not provide any proof of randomness for the two points P1 and P2. This could have easily been done by choosing P1 and P2 as outputs of a hash function, but they did not. This is just one of many flaws in the design of this algorithm.

The evidence is mounting for Dual_EC_DRBG being well-suited for use as a back door. A working proof of concept backdoor was published in late 2013 using OpenSSL, and a patent for using the construction as "key escrow" (another term for backdoor) was filed back in 2006.

Up until recently, Dual_EC_DRBG was the default random number generator for several cryptographic products from RSA (the security division of EMC), even though cryptographers have long been skeptical of the algorithm's design. There are reports of impropriety connecting a $10 million investment by the United States government and RSA's decision to use this obscure and widely maligned algorithm in their widely-distributed products.

Looking Ahead

It is very difficult to implement a secure system. Backdoors can be introduced at the software, hardware or even algorithm level. Algorithms backed by standards are not necessarily safe or free of backdoors. Some lessons to take away from this exercise are:

Even secure cryptographic functions can be weakened if there isn't a good source of randomness
Randomness in deterministic systems like computers is very hard to do correctly;
Adding unpredictable sources of entropy can help increase randomness and, in turn, secure algorithms from these types of attacks

At CloudFlare, we understand this fact and are working on ways to make sure that the randomness in our cryptographic systems is truly random. Steps include extracting entropy from the physical world, monitoring system entropy levels, using a hardware random number generator to mix in extra entropy, and not relying on a single random number generator as the source of all randomness.