Hide Behind The Edge
by Dani Grant
I work at a company whose job it is to be attacked. As I’m writing this, an automatic mitigation is fighting two ongoing DDoS attacks. Any machine that’s publicly routable on the internet today can be a vector for attack, and that’s a problem.
Today we want to turn the tables and give you a new way of exposing services to the internet without having them be directly, publicly routable. Meet Cloudflare Warp.
Playing Hide and Seek with Bots and Hackers
Cloudflare internally runs about 4,000 containers that make up about 1.5K services and applications. Some of these containers need to network with other local containers, and others need to accept connections over the wire.
Every devops engineer knows that bad things happen to good machines, and so our platform operations team tries to hide servers altogether from the internet. There are several ways to do this:
- Rotate IP addresses
- Deploy proxies
- Create firewall rules
- Configure IP tables
- Limit connections by client certificate
- Cross connect with an upstream provider
- Configure a GRE tunnel
- Authentication mechanisms like OAuth or OIDC
These can be complicated or time consuming, yet none of them are guarantees.
We knew we could make it easier. We started building an internal tool for ourselves — a safer way to expose services running on our own infrastructure (with some service discovery and automation benefits as well…more on that later) and after talking to developers and security engineers that use Cloudflare, we realized there was benefit in opening it up to everyone.
Cloudflare Warp
Cloudflare Warp is a security-conscious tool for exposing web applications without needing to expose the server they run on. With Cloudflare Warp, traffic to your application is run over a private, encrypted, virtual tunnel from the Cloudflare edge and traffic is only able to find and access your server if it routes through Cloudflare.
Only Cloudflare knows how to dial back to the application through the virtual tunnel created between the application and Cloudflare. Traffic can never hit your origin directly because it can never find it, your origin isn’t on the internet, it’s only there if you go through Cloudflare, via Warp. Instead, the client connects to the nearest Cloudflare data center, never directly to the application itself.
To start up Cloudflare Warp, it’s just one command. For example, if I want to run Cloudflare Warp to expose an application running locally on port 4000, I run:
cloudflare-warp --hostname example.com https://localhost:4000Behind the scenes, Cloudflare Warp issues an SSL certificate, installs it on the application server and uses it to generate an encrypted, tunnelled connection back to Cloudflare. (The internal project name for Cloudflare Warp was E.T. because of this ‘phoning home’ behavior). Cloudflare Warp then sets up the corresponding DNS records for the application so that when a visitor next goes to your application, they will be connected through the virtual tunnel back to the application running locally at port 4000.
One Secure Gateway
With this setup, Cloudflare’s edge acts as a network shield in front of your infrastructure. At Cloudflare’s edge you can describe policies (allow 50 connections per second, only to these routes, only from these IP’s and only if they are authenticated) and because traffic through Warp can only reach your servers after it’s traveled through Cloudflare, you can drop unexpected traffic at the edge, only receive clean traffic on your server, and know that it’s been validated by Cloudflare. As you continue to set up applications connected to Cloudflare using Warp, you only have to configure this once with Cloudflare and it can apply holistically across all of your applications, protecting your entire infrastructure.
Did we say service discovery?
One of the side benefits of Cloudflare Warp is that immediately when you spin up the Cloudflare Warp agent, it registers DNS records for your application, making it an effective tool for service discovery.
We also allow you to tag tunnels the way you would label your kubernetes pods with key-value pairs like release:stable and release:canary. Soon you’ll also be able to configure routing based on these labels (send 90% of my traffic to the stable release and 10% to the canary release).
What’s next?
The Cloudflare Warp beta is available today and we’re gradually adding people every day. Ready to get started? You can jump in and read the docs or sign up for access to the beta.
Originally published at blog.cloudflare.com on September 28, 2017.
