April 2018 Summaries

In this tutorial, you learned about the following topics: 1. Introduction to Cloudflare's API and Terraform 2. Installing Terraform and setting up your Cloudflare account 3. Configuring a basic web server using Terraform 4. Using version control with Git for tracking changes in your configuration files 5. Redeploying previous configurations by reverting commits 6. Importing existing state and configuration into Terraform By following this tutorial, you should now have a good understanding of how to use Terraform to manage Cloudflare resources effectively.

In this tutorial, you'll learn how to configure a basic website using Terraform and Cloudflare. You'll start by setting up your domain with Cloudflare, then use Terraform to manage DNS records for the domain. Next, you'll configure some optional HTTPS settings on your zone using Terraform. Finally, you'll add a rate limiting rule to protect your website from brute force login attempts. To follow along with this tutorial, you should have an existing Cloudflare account and domain registered with them. You will also need the Terraform CLI installed on your system. 1. Create a new GitHub repository for your configuration files. 2. Clone the repository to your local machine: ```bash git clone https://github.com/$GITHUB_USER/cf-config.git cd cf-config ``` 3. Initialize Terraform in the new directory: ```bash terraform init ``` 4. Create a `variables.tf` file with the following content: ```hcl variable "domain" { description = "The domain name to configure." } ``` 5. Update your `main.tf` file to include the Cloudflare provider and DNS record creation: ```hcl provider "cloudflare" { email = var.CLOUDFLARE_EMAIL api_key = var.CLOUDFLARE_API_KEY } resource "cloudflare_record" "www" { zone_id = data.cloudflare_zone.example-com.id name = "www" type = "CNAME" value = "upinatoms.com" ttl = 1 } ``` 6. Run `terraform apply` to create the DNS record: ```bash terraform apply --auto-approve ``` 7. Create a new branch and append the zone settings override: ```bash git checkout -b step2-zone-settings cat >> cloudflare.tf <<'EOF' resource "cloudflare_zone_settings_override" "example-com-settings" { name = "${var.domain}" settings { tls_1_3 = "on" always_use_https = "on" ssl = "full" waf = "on" } } EOF ``` 8. Preview and merge the changes: ```bash git add cloudflare.tf git commit -m "Step 2 - Enable TLS 1.3, Always Use HTTPS, SSL Full mode, and WAF." git checkout master && git merge step2-zone-settings && git push ``` 9. Apply the updated zone settings: ```bash terraform apply --auto-approve ``` 10. Create a new branch and append the rate limiting settings: ```bash git checkout -b step4-ratelimit cat >> cloudflare.cf <<'EOF' resource "cloudflare_rate_limit" "login-limit" { zone = "${var.domain}" threshold = 5 period = 60 match { request { url_pattern = "${var.domain}/login" schemes = ["HTTP", "HTTPS"] methods = ["POST"] } response { statuses = [401, 403] origin_traffic = true } } action { mode = "simulate" timeout = 300 response { content_type = "text/plain" body = "You have failed to login 5 times in a 60 second period and will be blocked from attempting to login again for the next 5 minutes." } } disabled = false description = "Block failed login attempts (5 in 1 min) for 5 minutes." } EOF ``` 11. Preview and merge the changes: ```bash git add cloudflare.tf git commit -m "Step 4 - Add rate limiting rule to protect /login." git checkout master && git merge step4-ratelimit && git push ``` 12. Update the rule to ban (not just simulate): ```bash git checkout step4-ratelimit sed -i.bak -e 's/simulate/ban/' cloudflare.tf git diff git add cloudflare.tf git commit -m "Step 4 - Update /login rate limit rule from 'simulate' to 'ban'." git checkout master && git merge step4-ratelimit && git push ``` 13. Confirm the rule works as expected: ```bash for i in {1..6}; do curl -XPOST -d '{"username": "foo", "password": "bar"}' -vso /dev/null https://www.example.com/login 2>&1 | grep "< HTTP"; sleep 1; done ``` That's it for today! Stay tuned next week for part 2 of this post, where we continue the tour through the following resources and techniques: - Load Balancing Resource - Page Rules Resource - Reviewing and Rolling Back Changes - Importing Existing State and Configuration

Cloudflare Systems Engineers, Ross Guarini and Terin Stock, are leading talks on Go and Kubernetes in Copenhagen and London over the next two weeks. They will be joined by Junade Ali for additional talks at Cloudflare's London office. The events include five meetups and a conference talk, focusing on topics such as extending Kubernetes clusters, building Go with Bazel, internationalization in Go, Kubernetes Controllers, and network failure architecture for mobile apps.

A BGP leak occurred on April 24, 2018, where an attacker attempted (and possibly succeeded) to steal cryptocurrencies using the leaked IP space. The Internet is composed of routes, and authorities are in charge of distributing IP addresses to avoid duplication. A BGP leak occurs when someone not allowed by the owner of the space announces IPs. This can be due to a configuration mistake or malicious intent. In this case, eNet Inc (AS10297) announced more specifics of Amazon routes from 11:05 to 13:03 UTC today. The BGP hijack affected AWS DNS and was against myetherwallet.com. The attacker stole Ethereum by using the login information they obtained through a phishing website hosted on Russian providers. Solutions for securing BGP include adding terms to RIR databases, setting up RPKI/ROA records, using DNSSEC, enabling HSTS, and utilizing DANE.

Cloudflare has expanded its Access service to support two more Identity Providers: Centrify and OneLogin. This addition allows users of these providers to integrate them with Cloudflare Access, enabling team members to securely access internal tools using their existing accounts. Furthermore, a generic connector for any OIDC-based identity provider has been introduced, allowing integration with popular providers such as Ping Identity and Forgerock. Instructions are provided for configuring OneLogin, Centrify, and custom OIDC providers in the Cloudflare dashboard.

Cloudflare, a company aiming to build a better internet, has taken steps towards sustainability by purchasing regional renewable energy certificates (RECs) to match 100% of the electricity used in their North American data centers and U.S. offices. This initiative reduces their carbon footprint by 5,561 tons of CO2, equivalent to growing 144,132 trees seedlings for 10 years or taking 1,191 cars off the road for a year. The purchase of RECs helps track renewable energy generation and supports its development while lowering carbon footprints. This is part of Cloudflare's broader sustainability effort that includes working with data centers specializing in lowering their PUE (Power Usage Effectiveness), waste diversion, and energy efficiency measures already in place in their offices worldwide. The company plans to increase its renewable energy commitment to match the energy used globally in their data centers and offices.

Cloudflare's security analyst team has successfully protected users against a major vulnerability in Drupal CMS, known as Drupalgeddon 2. The company implemented a Web Application Firewall (WAF) rule that identified and blocked malicious requests exploiting the critical remote code execution Drupal exploit. Since adding protection with WAF rule ID D0003 on April 13th, more than 500,000 potential attacks have been blocked. The most common attack attempts involve injecting a renderable array in POST requests to exploit the 'mail' field. Cloudflare continues to block over 56,000 potential attacks per day.

This post chronicles the author's experience working at Cloudflare after one year. It begins with their on-boarding process, which involved moving to San Francisco for four weeks of training and learning two languages - English and Cloudflarian. The author then details their first customer experiences in London, noting how they gained confidence over time and improved their English skills. Finally, the post discusses the author's day-to-day life at Cloudflare, highlighting personal development opportunities and the company's growth during their tenure.

The blog post discusses the problem of retaining real client source IP addresses when building an application level proxy, particularly in generic TCP tunnels. It presents three general solutions to this issue and introduces "mmproxy", a PROXY protocol gateway that listens for remote connections coming from an application level load balancer like Cloudflare Spectrum. Mmproxy spoofs the client IP address, making it indistinguishable from a real connection directly connecting to the application. The post also provides instructions on how to set up and run mmproxy.

The Qualcomm Centriq CPU is a powerful processor that provides good performance and power efficiency. However, years of Intel leadership in the server and desktop space mean that a lot of software is better optimized for Intel processors. Writing optimizations for ARMv8 is not difficult, and we will be adjusting our software as needed, and publishing our efforts as we go. The updated code can be found on our Github page.

Cloudflare introduces Spectrum, a security solution for its Enterprise customers that extends DDoS protection and acceleration to all TCP ports and protocols. The core functionality of Spectrum is its ability to block large-scale DDoS attacks. It also supports TLS termination at the edge, improving performance by reducing the distance traveled during the TLS handshake. Additionally, it integrates with Cloudflare's IP Firewall for managing access rules. Currently, Spectrum is available only for applications on the Enterprise plan, but there are plans to make it accessible to non-Enterprise customers in the future.

Cloudflare has introduced Spectrum, a new feature that brings DDoS protection, load balancing, and content acceleration to any TCP-based protocol. The development of Spectrum faced technical challenges due to Linux's limitations in accepting connections on any valid TCP port from 1 to 65535. To overcome these issues, Cloudflare employed the "AnyIP" trick, which allows assigning whole IP prefixes (subnets) to the loopback interface, and utilized TPROXY iptables module for socket dispatch. These solutions enabled Spectrum to operate smoothly on the vanilla kernel without requiring any custom kernel patches.

In March 2018, Cloudflare launched its fast and privacy-centric DNS resolver service with the IP address 1.1.1.1. However, they found that many Internet Service Providers (ISPs) and Customer Premises Equipment (CPEs) were misusing this IP address for their internal communication or blocking it due to legacy configurations. This resulted in a significant number of users being unable to access the DNS resolver service. To resolve these issues, Cloudflare collaborated with various ISPs and CPE manufacturers to clean up the bad routing globally. They also provided four IPs (two for each IP address family) to provide a path towards the DNS resolver independent of IPv4 or IPv6 reachability. By April 3, their efforts had increased the availability of 1.1.1.1 from around 91% in Europe and North America to 97%, and from 73% globally (excluding Europe and North America) to 85%. They continue to work with ISPs and CPE manufacturers to achieve their goal of making 1.1.1.1 properly routed and available for 100% of Internet users.

This blog post discusses the importance of protecting privacy online by encrypting Domain Name System (DNS) traffic. It explains that while encryption technologies have been longstanding for HTTP connections, only recently have such techniques been standardized for DNS. The author demonstrates how to configure an OpenWRT router to encrypt outbound traffic to Cloudflare's DNS Resolver using DNS-over-HTTPS and DNS-over-TLS. This is particularly useful when protecting the traffic of devices that may not support encrypted DNS protocols, such as TVs or IoT enabled toasters. The post also provides step-by-step instructions on how to replace Dnsmasq with Unbound and odhcpd in order to enable DNS-over-TLS on an OpenWRT router.

On April 6, 2018, Cloudflare launched Argo Tunnel, a service that exposes applications running on local web servers without requiring DNS records or firewall configuration. This makes it possible to use devices like Raspberry Pi as web servers without exposing home networks to the internet. The author demonstrates how to set up and use Argo Tunnel with a Raspberry Pi, including installing Cloudflare's agent, logging in, creating a secure tunnel, serving content from a Rust-based web server, and setting up both the agent and web server to auto-start on boot.

Cloudflare introduces Argo Tunnel, a private connection between your web server and their network. It functions as a virtual P.O. box, allowing traffic to reach your server only through Cloudflare while remaining unroutable for the rest of the internet. This solution replaces GRE tunnels, which are expensive and slow. Argo Tunnel is fast to install and run, offering improved security and performance benefits. It is built on top of Argo, Cloudflare's smart routing system, and is included for free with Argo-enabled accounts. A free version may be offered in the future for testing purposes.

On April 3, 2018, Kamilla Amirova announced that Cloudflare has integrated its services with Google Cloud Platform's Cloud Security Command Center (Cloud SCC). This integration aims to provide a holistic view of threats, malicious server activity, vulnerabilities, and sensitive data access levels across all applications and services. The Cloud SCC solution gathers data from both the Google Cloud Platform and Cloudflare's edge, presenting insights in a unified dashboard. Through API endpoints, Cloudflare data is pushed to the Cloud SCC dashboard, where users can view top threat origins, types of threats, and Web Application Firewall events. The integration offers detailed information on blocked or challenged requests, allowing users to take action by logging into their Cloudflare dashboard or configuring changes through the Cloudflare API. To sign up for this service, submit your details via the provided link.

Cloudflare has launched 1.1.1.1, a new consumer DNS service that promises to be the internet's fastest and most privacy-focused option. The company aims to help build a better internet by addressing issues such as slow and non-privacy respecting DNS services often provided by ISPs. The new service is built on Cloudflare's extensive global network, which outperforms other consumer DNS services available. 1.1.1.1 also offers a commitment to never write the querying IP addresses to disk and wipe all logs within 24 hours. Additionally, KPMG will audit its practices annually and publish a public report confirming compliance with privacy policies.

Cloudflare has released its public DNS resolver, 1.1.1.1, aiming to make the internet faster, more secure and privacy-centric. The service is built on Cloudflare's Global Anycast Network and uses IPv4 addresses 1.1.1.1 and 1.0.0.1. It supports emerging DNS privacy standards such as DNS-over-TLS and DNS-over-HTTPS, ensuring last mile encryption for users' DNS queries. The resolver also implements Query Minimization RFC7816, Aggressive negative answers RFC8198, and uses DNSSEC validation to ensure the accuracy of responses. It does not store client IP addresses or any information that identifies an end user. To use the service, visit https://1.1.1.1/.