Tag Archives: Cloudflare Gateway

Announcing Tenant Control in Cloudflare Gateway

Post Syndicated from Alyssa Wang original https://blog.cloudflare.com/gateway-tenant-control/

Announcing Tenant Control in Cloudflare Gateway

Announcing Tenant Control in Cloudflare Gateway

The tools we use at work are starting to look like the apps we use in our personal lives. We send emails for our jobs using Google Workspace and respond to personal notes in Gmail. We download PDFs from our team’s Dropbox and then upload images to our personal account. This can lead to confusion and mistakes—made worse by remote work when we forget to log off for the day.

Today, we’re excited to announce Tenant Control in Cloudflare Gateway, a new feature that helps keep our work at work. Organizations can deploy Cloudflare Gateway to their corporate devices and apply rules ensuring that employees can only log in to the corporate version of the tools they need. Now, teams can prevent users from logging in to the wrong instance of popular applications. What’s more, they can make sure corporate data stays within corporate accounts.

Controlling the application, alone, isn’t sufficient

Cloudflare Gateway provides security from threats on the Internet by sending all traffic leaving a device to Cloudflare’s network where it can be filtered. Organizations send traffic to Cloudflare by deploying the WARP agent, a WireGuard-based client built on feedback from our popular consumer app.

Announcing Tenant Control in Cloudflare Gateway

Cloudflare Gateway can be deployed in several modes, but most customers start with DNS filtering which only sends DNS queries to Cloudflare. Cloudflare runs the world’s fastest DNS resolver, 1.1.1.1, and on top of that we’ve built a DNS filtering solution where we help prevent users from visiting sites that contain malware or serve phishing attacks.

When organizations are ready to add more security to their deployment, they go beyond DNS filtering by adding HTTP filtering as well. Cloudflare inspects the HTTP traffic leaving the device which provides more granular control than just DNS filtering over destinations and events that happen inside the traffic, like blocking file uploads to certain destinations.

Customers use the HTTP filtering to filter and control SaaS application usage. For example, if your team uses OneDrive, you can block all file uploads to Google Drive to avoid data leaving the tenants you control. Cloudflare provides the classification of what hostnames and URLs constitute an application and make it possible to build rules with just two clicks. However, what happens when you aren’t using two different applications — you’re using two different instances of the same one?

Applying control to the SaaS tenant

Today, you can enable tenant control using Gateway HTTP policies in Cloudflare Gateway. Administrators can begin by adding a new type of rule in Gateway that prompts them to input a specific value provided by the SaaS application. For example, an administrator can gather the tenant ID for their Microsoft 365 deployment.

Once the rule is enabled, Cloudflare Gateway will append a specific header and, if enabled, the specific tenant ID as part of the appended header to your request. Depending on the SaaS application, these will either block all consumer or personal usage or block all logins to accounts that are not part of that tenant ID. The SaaS application is aware of the specific header it relies on to enforce this rule and, when received, responds accordingly.

Traditionally, these headers are injected by corporate VPNs or proxy servers maintained on-premises and accessed by backhauling user traffic. Cloudflare Gateway provides customers with filtering and inspection in our data centers closer to your users and, combined with our ability to accelerate traffic, delivers your users to their destination without the performance consequences of legacy backhaul approaches.

Enforcing Corporate Tenant Access

You can begin configuring these rules today in the Cloudflare for Teams dashboard. To enforce tenant control with Gateway, you can configure an HTTP policy in the Teams Dashboard. For example, you can prevent users from authenticating to GSuite with their personal account and uploading documents to Google Drive account by using the following policy (GSuite uses the “X-GooGApps-Allowed-Domains” header):

Announcing Tenant Control in Cloudflare Gateway

As requests get filtered by Gateway’s firewall, allowed requests are proxied to their respective upstream servers. Before sending them upstream, we preprocess the request and append our own trace headers — these include things that are useful for debugging, like request ID headers. Now you can specify your own custom headers to be added onto these requests, which is what enables customers to enforce tenant control for their organizations.

What’s Next

Controlling data usage in your organization is a multistep process. Today, Cloudflare Gateway gives your teams control of what applications you use, where you can upload or download files, and when to block copy-paste and printing in our isolated browser. We’re excited to introduce tenant control into that portfolio to add another layer of security.

That said, we’re just getting started. We’ll be introducing new scanning features on top of this existing functionality as we continue to build Cloudflare’s data control features. If you want to be the first to know about the next wave of these features, follow this link to sign up today.

6 New Ways to Validate Device Posture

Post Syndicated from Kyle Krum original https://blog.cloudflare.com/6-new-ways-to-validate-device-posture/

6 New Ways to Validate Device Posture

6 New Ways to Validate Device Posture

Cloudflare for Teams gives your organization the ability to build rules that determine who can reach specified resources. When we first launched, those rules primarily relied on identity. This helped our customers replace their private networks with a model that evaluated every request for who was connecting, but this lacked consideration for how they were connecting.

In March, we began to change that. We announced new integrations that give you the ability to create rules that consider the device as well. Starting today, we’re excited to share that you can now build additional rules that consider several different factors about the device, like its OS, patch status, and domain join or disk encryption status. This has become increasingly important over the last year as more and more people began connecting from home. Powered by the Cloudflare WARP agent, your team now has control over more health factors about the devices that connect to your applications.

Zero Trust is more than just identity

With Cloudflare for Teams, administrators can replace their Virtual Private Networks (VPNs), where users on the network were trusted, with an alternative that does not trust any connection by default—also known as a Zero Trust model.

Customers start by connecting the resources they previously hosted on a private network to Cloudflare’s network using Cloudflare Tunnel. Cloudflare Tunnel uses a lightweight connector that creates an outbound-only connection to Cloudflare’s edge, removing the need to poke holes in your existing firewall.

Once connected, administrators can build rules that apply to each and every resource and application, or even a part of an application. Cloudflare’s Zero Trust network evaluates every request and connection against the rules that an administrator created before the user is ever allowed to reach that resource.

For example, an administrator can create a rule that limits who can reach an internal reporting tool to users in a specific Okta group, connecting from an approved country, and only when they log in with a hardkey as their second factor. Cloudflare’s global network enforces those rules close to the user, in over 200 cities around the world, to make a comprehensive rule like the outlined above feel seamless to the end-user.

Today’s launch adds new types of signals your team can use to define these rules. By definition, a Zero Trust model considers every request or connection to be “untrusted.” Only the rules that you create determine what is considered trusted and allowed. Now, we’re excited to let users take this a step further and create rules that not only focus on trusting the user, but also the security posture of the device they are connecting from.

More (and different) factors are better

Building rules based on device posture covers a blind spot for your applications and data. If I’m allowed to reach a particular resource, without any consideration for the device I’m using, then I could log in with my corporate credentials from a personal device running an unpatched or vulnerable version of an operating system. I might do that because it is convenient, but I am creating a much bigger problem for my team if I then download data that could be compromised because of that device.

That posture can also change based on the destination. For example, maybe you are comfortable if a team member uses any device to review a new splash page for your marketing campaign. However, if a user is connecting to an administrative tool that manages customer accounts, you want to make sure that device complies with your security policies for customer data that include factors like disk encryption status. With Cloudflare for Teams, you can apply rules that contain multiple and different factors with that level of per-resource granularity.

Today, we are thrilled to announce six additional posture types on top of the ones you can already set:

  1. Endpoint Protection Partners — Verify that your users are running one of our Endpoint Protection Platform providers (Carbon Black, CrowdStrike, SentinelOne, Tanium)
  2. Serial Number — Allow devices only from your known inventory pool
  3. Cloudflare WARP’s proxy — Determine if your users are connected via our encrypted WARP tunnel (Free, Paid or any Teams account)
  4. Cloudflare’s secure web gateway — Determine if your users are connecting from a device managed by your HTTP FIltering policies
  5. (NEW) Application Check — Verify any program of your choice is running on the device
  6. (NEW) File Check — Ensure a particular file is present on the device (such as an updated signature, OS patch, etc.)
  7. (NEW) Disk Encryption — Ensure all physical disks on the device are encrypted
  8. (NEW) OS Version — Confirm users have upgraded to a specific operating system version
  9. (NEW) Firewall — Check that a firewall is configured on the device
  10. (NEW) Domain Joined — Verify that your Windows devices must be joined to the corporate directory

Device rules should be as simple as identity rules

Cloudflare for Teams device rules can be configured in the same place that you control identity-based rules. Let’s use the Disk Encryption posture check as an example. You may want to create a rule that enforces the Disk Encryption check when your users need to download and store files on their devices locally.

To build that rule, first visit the Cloudflare for Teams dashboard and navigate to the Devices section of the “My Team” page. Then, choose “Disk Encryption” as a new attribute to add.

6 New Ways to Validate Device Posture

You can enter a descriptive name for this attribute. For example, this rule should require Windows disk encryption, while others might require encryption on other platforms.

6 New Ways to Validate Device Posture

To save time, you can also create reusable rules, called Groups, to include multiple types of device posture check for reference in new policies later on.

6 New Ways to Validate Device Posture

Now that you’ve created your group, you can create a Zero Trust Require rule to apply your Disk Encryption checks. To do that, navigate to Access > Applications and create a new application. If you already have your application in place, simply edit your application to add a new rule. In the Assign a group section you will see the group you just created—select it and choose a Require rule type. And finally, save the rule to begin enforcing granular, zero trust device posture checks on every request in your environment.

6 New Ways to Validate Device Posture

What’s next

Get started with exploring all device posture attributes in our developer docs. Note that not all posture types are currently available on operating systems and some operating systems don’t support them.

Is there a posture type we’re missing that you’d love to have? We’d love to hear from you in the Community.

Helping Keep Governments Safe and Secure

Post Syndicated from Sam Rhea original https://blog.cloudflare.com/helping-keep-governments-safe-and-secure/

Helping Keep Governments Safe and Secure

Helping Keep Governments Safe and Secure

Today, we are excited to share that Cloudflare and Accenture Federal Services (AFS) have been selected by the Department of Homeland Security (DHS) to develop a joint solution to help the federal government defend itself against cyberattacks. The solution consists of Cloudflare’s protective DNS resolver which will filter DNS queries from offices and locations of the federal government and stream events directly to Accenture’s analysis platform.

Located within DHS, the Cybersecurity and Infrastructure Security Agency (CISA) operates as “the nation’s risk advisor.”1 CISA works with partners across the public and private sector to improve the security and reliability of critical infrastructure; a mission that spans across the federal government, State, Local, Tribal, and Territorial partnerships and the private sector to provide solutions to emerging and ever-changing threats.

Over the last few years, CISA has repeatedly flagged the cyber risk posed by malicious hostnames, phishing emails with malicious links, and untrustworthy upstream Domain Name System (DNS) resolvers.2 Attackers can compromise devices or accounts, and ultimately data, by tricking a user or system into sending a DNS query for a specific hostname. Once that query is resolved, those devices establish connections that can lead to malware downloads, phishing websites, or data exfiltration.

In May 2021, CISA and the National Security Agency (NSA) proposed that teams deploy protective DNS resolvers to prevent those attacks from becoming incidents. Unlike standard DNS resolvers, protective DNS resolvers check the hostname being resolved to determine if the destination is malicious. If that is the case, or even if the destination is just suspicious, the resolver can stop answering the DNS query and block the connection.

Earlier this year, CISA announced they are not only recommending a protective DNS resolver — they have launched a program to offer a solution to their partners. After a thorough review process, CISA has announced that they have selected Cloudflare and AFS to deliver a joint solution that can be used by departments and agencies of any size within the Federal Civilian Executive Branch.

Helping keep governments safer

Attacks against the critical infrastructure in the United States are continuing to increase. Cloudflare Radar, where we publish insights from our global network, consistently sees the U.S. as one of the most targeted countries for DDoS attacks. Attacks like phishing campaigns compromise credentials to sensitive systems. Ransomware bypasses traditional network perimeters and shuts down target systems.

The sophistication of those attacks also continues to increase. Last year’s SolarWinds Orion compromise represents a new type of supply chain attack where trusted software becomes the backdoor for data breaches. Cloudflare’s analysis of the SolarWinds incident observed compromise patterns that were active over eight months, during which the destinations used grew to nearly 5,000 unique subdomains.

The increase in volume and sophistication has driven a demand for the information and tools to defend against these types of threats at all levels of the US government. Last year, CISA advised over 6,000 state and local officials, as well as federal partners, on mechanisms to protect their critical infrastructure.

At Cloudflare, we have observed a similar pattern. In 2017, Cloudflare launched the Athenian Project to provide state, county, or municipal governments with security for websites that administer elections or report results. In 2020, 229 state and local governments, in 28 states, trusted Cloudflare to help defend their election websites. State and local government websites served by Cloudflare’s Athenian Project increased by 48% last year.

As these attacks continue to evolve, one thing many have in common is their use of a DNS query to a malicious hostname. From SolarWinds to last month’s spearphishing attack against the U.S. Agency for International Development, attackers continue to rely on one of the most basic technologies used when connecting to the Internet.

Delivering a protective DNS resolver

User activity on the Internet typically starts with a DNS query to a DNS resolver. When users visit a website in their browser, open a link in an email, or use a mobile application, their device first sends a DNS query to convert the domain name of the website or server into the Internet Protocol (IP) address of the host serving that site. Once their device has the IP address, they can establish a connection.

Helping Keep Governments Safe and Secure
Figure 1. Complete DNS lookup and web page query

Attacks on the Internet can also start the same way. Devices that download malware begin making DNS queries to establish connections and leak information. Users that visit an imposter website input their credentials and become part of a phishing attack.

These attacks are successful because DNS resolvers, by default, trust all destinations. If a user sends a DNS query for any hostname, the resolver returns the IP address without determining if that destination is suspicious.

Some hostnames are known to security researchers, including hostnames used in previous attacks or ones that use typos of popular hostnames. Other attacks start from unknown or new threats. Detecting those requires monitoring DNS query behavior, detecting patterns to new hostnames, or blocking newly seen and registered domains altogether.

Protective DNS resolvers apply a Zero Trust model to DNS queries. Instead of trusting any destination, protective resolvers check the hostname of every query and IP address of every response against a list of known malicious destinations. If the hostname or IP address is in that list, the resolver will not return the result to the user and the connection will fail.

Building a solution with Accenture Federal Services

The solution being delivered to CISA, Cloudflare Gateway, builds on Cloudflare’s network to deliver a protective DNS resolver that does not compromise performance. It starts by sending all DNS queries from enrolled devices and offices to Cloudflare’s network. While more of the HTTP Internet continues to be encrypted, the default protocol for sending DNS queries on most devices is still unencrypted. Cloudflare Gateway’s protective DNS resolver supports encrypted options like DNS over HTTPS (DoH) and DNS over TLS (DoT).

Next, blocking DNS queries to malicious hostnames starts with knowing what hostnames are potentially malicious. Cloudflare’s network provides our protective DNS resolver with unique visibility into threats on the Internet. Every day, Cloudflare’s network handles over 800 billion DNS queries. Our infrastructure responds to 25 million HTTP requests per second. We deploy that network in more than 200 cities in over 100 countries around the world, giving our team the ability to see attack patterns around the world.

We convert that data into the insights that power our security products. For example, we analyze the billions of DNS queries we handle to detect anomalous behavior that would indicate a hostname is being used to leak data through a DNS tunneling attack. For the CISA solution, Cloudflare’s datasets are further enriched by applying additional cybersecurity research along with Accenture’s Cyber Threat Intelligence (ACTI) feed to provide signals to detect new and changing threats on the internet. This dataset is further analyzed by data scientists using advanced business intelligence tools powered by artificial intelligence and machine learning.

Working towards a FedRAMP future

Our Public Sector team is focused on partnering with Federal, State and Local Governments to provide a safe and secure digital experience. We are excited to help CISA deliver an innovative, modern, and cost-efficient solution to the entire civilian federal government.

We will continue this path following our recent announcement that we are currently “In Process” in the Federal Risk and Authorization Management Program (FedRAMP) Marketplace. The government’s rigorous security assessment will allow other federal agencies to adopt Cloudflare’s Zero Trust Security solutions in the future.

What’s next?

We are looking forward to working with Accenture Federal Services to deliver this protective DNS resolver solution to CISA. This contract award demonstrates CISA’s belief in the importance of having protective DNS capabilities as part of a layered defense. We applaud CISA for taking this step and allowing us to partner with the US Government to deliver this solution.

Like CISA, we believe that teams large and small should have the tools they need to protect their critical systems. Your team can also get started using Cloudflare to secure your organization today. Cloudflare Gateway, part of Cloudflare for Teams, is available to organizations of any size.

1https://www.cisa.gov/about-cisa
2See, for example, https://www.cisa.gov/sites/default/files/publications/Addressing_DNS_Resolution_on_Federal_Networks_Memo.pdf; https://media.defense.gov/2021/Mar/03/2002593055/-1/-1/0/CSI_Selecting-Protective-DNS_UOO11765221.PDF

Announcing WARP for Linux and Proxy Mode

Post Syndicated from Kyle Krum original https://blog.cloudflare.com/announcing-warp-for-linux-and-proxy-mode/

Announcing WARP for Linux and Proxy Mode

Announcing WARP for Linux and Proxy Mode

Last October we released WARP for Desktop, bringing a safer and faster way to use the Internet to billions of devices for free. At the same time, we gave our enterprise customers the ability to use WARP with Cloudflare for Teams. By routing all an enterprise’s traffic from devices anywhere on the planet through WARP, we’ve been able to seamlessly power advanced capabilities such as Secure Web Gateway and Browser Isolation and, in the future, our Data Loss Prevention platforms.

Today, we are excited to announce Cloudflare WARP for Linux and, across all desktop platforms, the ability to use WARP with single applications instead of your entire device.

What is WARP?

WARP was built on the philosophy that even people who don’t know what “VPN” stands for should be able to still easily get the protection a VPN offers. It was also built for those of us who are unfortunately all too familiar with traditional corporate VPNs, and need an innovative, seamless solution to meet the challenges of an always-connected world.

Enter our own WireGuard implementation called BoringTun.

The WARP application uses BoringTun to encrypt traffic from your device and send it directly to Cloudflare’s edge, ensuring that no one in between is snooping on what you’re doing. If the site you are visiting is already a Cloudflare customer, the content is immediately sent down to your device. With WARP+, we use Argo Smart Routing to use the shortest path through our global network of data centers to reach whomever you are connecting to.

Combined with the power of 1.1.1.1 (the world’s fastest public DNS resolver), WARP keeps your traffic secure, private and fast. Since nearly everything you do on the Internet starts with a DNS request, choosing the fastest DNS server across all your devices will accelerate almost everything you do online.

Bringing WARP to Linux

When we built out the foundations of our desktop client last year, we knew a Linux client was something we would deliver. If you have ever shipped software at this scale, you’ll know that maintaining a client across all major operating systems is a daunting (and error-prone) task. To avoid these pitfalls, we wrote the core of the product in Rust, which allows for 95% of the code to be shared across platforms.

Internally we refer to this common code as the shared Daemon (or Service, for Windows folks), and it allows our engineers to spend less time duplicating code across multiple platforms while ensuring most quality improvements hit everyone at the same time. The really cool thing about this is that millions of existing WARP users have already helped us solidify the code base for Linux!

The other 5% of code is split into two main buckets: UI and quirks of the operating system. For now, we are forgoing a UI on Linux and instead working to support three distributions:

  • Ubuntu
  • Red Hat Enterprise Linux
  • CentOS

We want to add more distribution support in the future, so if your favorite distro isn’t there, don’t despair — the client may in fact already work with other Debian and Redhat based distributions, so please give it a try. If we missed your favorite distribution, we’d love to hear from you in our Community Forums.

So without a UI — what’s the mechanism for controlling WARP? The command line, of course! Keen observers may have noticed an executable that already ships with each client called the warp-cli. This platform-agnostic interface is already the preferred mechanism of interacting with the daemon by some of our engineers and is the main way you’ll interact with WARP on Linux.

Installing Cloudflare WARP for Linux

Seasoned Linux developers can jump straight to https://pkg.cloudflareclient.com/install. After linking our repository, get started with either sudo apt install cloudflare-warp or sudo yum install cloudflare-warp, depending on your distribution.

For more detailed installation instructions head over to our WARP Client documentation.

Using the CLI

Once you’ve installed WARP, you can begin using the CLI with a single command:

warp-cli --help

The CLI will display the output below.

~$ warp-cli --help
WARP 0.2.0
Cloudflare
CLI to the WARP service daemon
 
USAGE:
    warp-cli [FLAGS] [SUBCOMMAND]
 
FLAGS:
        --accept-tos    Accept the Terms of Service agreement
    -h, --help          Prints help information
    -l                  Stay connected to the daemon and listen for status changes and DNS logs (if enabled)
    -V, --version       Prints version information
 
SUBCOMMANDS:
    register                    Registers with the WARP API, will replace any existing registration (must be run
                                before first connection)
    teams-enroll                Enroll with Cloudflare for Teams
    delete                      Deletes current registration
    rotate-keys                 Generates a new key-pair, keeping the current registration
    status                      Asks the daemon to send the current status
    warp-stats                  Retrieves the stats for the current WARP connection
    settings                    Retrieves the current application settings
    connect                     Asks the daemon to start a connection, connection progress should be monitored with
                                -l
    disconnect                  Asks the daemon to stop a connection
    enable-always-on            Enables always on mode for the daemon (i.e. reconnect automatically whenever
                                possible)
    disable-always-on           Disables always on mode
    disable-wifi                Pauses service on WiFi networks
    enable-wifi                 Re-enables service on WiFi networks
    disable-ethernet            Pauses service on ethernet networks
    enable-ethernet             Re-enables service on ethernet networks
    add-trusted-ssid            Adds a trusted WiFi network, for which the daemon will be disabled
    del-trusted-ssid            Removes a trusted WiFi network
    allow-private-ips           Exclude private IP ranges from tunnel
    enable-dns-log              Enables DNS logging, use with the -l option
    disable-dns-log             Disables DNS logging
    account                     Retrieves the account associated with the current registration
    devices                     Retrieves the list of devices associated with the current registration
    network                     Retrieves the current network information as collected by the daemon
    set-mode                    
    set-families-mode           
    set-license                 Attaches the current registration to a different account using a license key
    set-gateway                 Forces the app to use the specified Gateway ID for DNS queries
    clear-gateway               Clear the Gateway ID
    set-custom-endpoint         Forces the client to connect to the specified IP:PORT endpoint
    clear-custom-endpoint       Remove the custom endpoint setting
    add-excluded-route          Adds an excluded IP
    remove-excluded-route       Removes an excluded IP
    get-excluded-routes         Get the list of excluded routes
    add-fallback-domain         Adds a fallback domain
    remove-fallback-domain      Removes a fallback domain
    get-fallback-domains        Get the list of fallback domains
    restore-fallback-domains    Restore the fallback domains
    get-device-posture          Get the current device posture
    override                    Temporarily override MDM policies that require the client to stay enabled
    set-proxy-port              Set the listening port for WARP proxy (127.0.0.1:{port})
    help                        Prints this message or the help of the given subcommand(s)

You can begin connecting to Cloudflare’s network with just two commands. The first command, register, will prompt you to authenticate. The second command, connect, will enable the client, creating a WireGuard tunnel from your device to Cloudflare’s network.

~$ warp-cli register
Success
~$ warp-cli connect
Success

Once you’ve connected the client, the best way to verify it is working is to run our trace command:

~$ curl https://www.cloudflare.com/cdn-cgi/trace/

And look for the following output:

warp=on

Want to switch from encrypting all traffic in WARP to just using our 1.1.1.1 DNS resolver? Use the warp-cli set-mode command:

~$ warp-cli help set-mode
warp-cli-set-mode 
 
USAGE:
    warp-cli set-mode [mode]
 
FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information
 
ARGS:
    <mode>     [possible values: warp, doh, warp+doh, dot, warp+dot, proxy]
~$ warp-cli set-mode doh
Success

Protecting yourself against malware with 1.1.1.1 for Families is just as easy, and it can be used with either WARP enabled or in straight DNS mode:

~$ warp-cli set-families-mode --help
warp-cli-set-families-mode 
 
USAGE:
    warp-cli set-families-mode [mode]
 
FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information
 
ARGS:
    <mode>     [possible values: off, malware, full]
~$ warp-cli set-families-mode malware
Success

A note on Cloudflare for Teams support

Cloudflare for Teams support is on the way, and just like our other clients, it will ship in the same package. Stay tuned for an in-app update or reach out to your Account Executive to be notified when a beta is available.

We need feedback

If you encounter an error, send us feedback with the sudo warp-diag feedback command:

~$ sudo warp-diag feedback

For all other functionality check out warp-cli --help or see our documentation here.

WARP as a Local Proxy

When WARP launched in 2019, one of our primary goals was ease of use. You turn WARP on and all traffic from your device is encrypted to our edge. Through all releases of the client, we’ve kept that as a focus. One big switch to turn on and you are protected.

However, as we’ve grown, so have the requirements for our client. Earlier this year we released split tunnel and local domain fallback as a way for our Cloudflare for Teams customers to exclude certain routes from WARP. Our consumer customers may have noticed this stealthily added in the last release as well. We’ve heard from customers who want to deploy WARP in one additional mode: Single Applications. Today we are also announcing the ability for our customers to run WARP in a local proxy mode in all desktop clients.

When WARP is configured as a local proxy, only the applications that you configure to use the proxy (HTTPS or SOCKS5) will have their traffic sent through WARP. This allows you to pick and choose which traffic is encrypted (for instance, your web browser or a specific app), and everything else will be left open over the Internet.

Because this feature restricts WARP to just applications configured to use the local proxy, leaving all other traffic unencrypted over the Internet by default, we’ve hidden it in the advanced menu. To turn it on:

1. Navigate to Preferences -> Advanced and click the Configure Proxy button.

2. On the dialog that opens, check the box and configure the port you want to listen on.

Announcing WARP for Linux and Proxy Mode

3. This will enable a new mode you can select from:

Announcing WARP for Linux and Proxy Mode

To configure your application to use the proxy, you want to specify 127.0.0.1 for the address and the value you specified for a port (40000 by default). For example, if you are using Firefox, the configuration would look like this:

Announcing WARP for Linux and Proxy Mode

Download today

You can start using these capabilities right now by visiting https://one.one.one.one. We’re super excited to hear your feedback.

Network-based policies in Cloudflare Gateway

Post Syndicated from Pete Zimmerman original https://blog.cloudflare.com/network-based-policies-in-cloudflare-gateway/

Network-based policies in Cloudflare Gateway

Over the past year, Cloudflare Gateway has grown from a DNS filtering solution to a Secure Web Gateway. That growth has allowed customers to protect their organizations with fine-grained identity-based HTTP policies and malware protection wherever their users are. But what about other Internet-bound, non-HTTP traffic that users generate every day — like SSH?

Today we’re excited to announce the ability for administrators to configure network-based policies in Cloudflare Gateway. Like DNS and HTTP policy enforcement, organizations can use network selectors like IP address and port to control access to any network origin.

Because Cloudflare for Teams integrates with your identity provider, it also gives you the ability to create identity-based network policies. This means you can now control access to non-HTTP resources on a per-user basis regardless of where they are or what device they’re accessing that resource from.

A major goal for Cloudflare One is to expand the number of on-ramps to Cloudflare — just send your traffic to our edge however you wish and we’ll make sure it gets to the destination as quickly and securely as possible. We released Magic WAN and Magic Firewall to let administrators replace MPLS connections, define routing decisions, and apply packet-based filtering rules on network traffic from entire sites. When coupled with Magic WAN, Gateway allows customers to define network-based rules that apply to traffic between whole sites, data centers, and that which is Internet-bound.

Solving Zero Trust networking problems

Until today, administrators could only create policies that filtered traffic at the DNS and HTTP layers. However, we know that organizations need to control the network-level traffic leaving their endpoints. We kept hearing two categories of problems from our users and we’re excited that today’s announcement addresses both.

First, organizations want to replace their legacy network firewall appliances. Those appliances are complex to manage, expensive to maintain, and force users to backhaul traffic. Security teams deploy those appliances in part to control the ports and IPs devices can use to send traffic. That level of security helps prevent devices from sending traffic over non-standard ports or to known malicious IPs, but customers had to deal with the downsides of on-premise security boxes.

Second, moving to a Zero Trust model for named resources is not enough. Cloudflare Access provides your team with Zero Trust controls over specific applications, including non-HTTP applications, but we know that customers who are migrating to this model want to bring that level of Zero Trust control to all of their network traffic.

How it works

Cloudflare Gateway, part of Cloudflare One, helps organizations replace legacy firewalls and upgrade to Zero Trust networking by starting with the endpoint itself. Wherever your users do their work, they can connect to a private network running on Cloudflare or the public Internet without backhauling traffic.

First, administrators deploy the Cloudflare WARP agent on user devices, whether those devices are MacOS, Windows, iOS, Android and (soon) Linux. The WARP agent can operate in two modes:

  • DNS filtering: WARP becomes a DNS-over-HTTPS (DoH) client and sends all DNS queries to a nearby Cloudflare data center where Cloudflare Gateway can filter those queries for threats like websites that host malware or phishing campaigns.
  • Proxy mode: WARP creates a WireGuard tunnel from the device to Cloudflare’s edge and sends all network traffic through the tunnel. Cloudflare Gateway can then inspect HTTP traffic and apply policies like URL-based rules and virus scanning.

Today’s announcement relies on the second mode. The WARP agent will send all TCP traffic leaving the device to Cloudflare, along with the identity of the user on the device and the organization in which the device is enrolled. The Cloudflare Gateway service will take the identity and then review the TCP traffic against four criteria:

  • Source IP or network
  • Source Port
  • Destination IP or network
  • Destination Port

Before allowing the packets to proceed to their destination, Cloudflare Gateway checks the organization’s rules to determine if they should be blocked. Rules can apply to all of an organization’s traffic or just specific users and directory groups. If the traffic is allowed, Cloudflare Gateway still logs the identity and criteria above.

Cloudflare Gateway accomplishes this without slowing down your team. The Gateway service runs in every Cloudflare data center in over 200 cities around the world, giving your team members an on-ramp to the Internet that does not backhaul or hairpin traffic. We enforce rules using Cloudflare’s Rust-based Wirefilter execution engine, taking what we’ve learned from applying IP-based rules in our reverse proxy firewall at scale and giving your team the performance benefits.

Building a Zero Trust networking rule

SSH is a versatile protocol that allows users to connect to remote machines and even tunnel traffic from a local machine to a remote machine before reaching the intended destination. That’s great but it also leaves organizations with a gaping hole in their security posture. At first, an administrator could configure a rule that blocks all outbound SSH traffic across the organization.

Network-based policies in Cloudflare Gateway

As soon as you save that policy, the phone rings and it’s an engineer asking why they can’t use a lot of their development tools. Right, engineers use SSH a lot so we should use the engineering IdP group to allow just our engineers to use SSH.

Network-based policies in Cloudflare Gateway

You take advantage of rule precedence and place that rule above the existing rule that affects all users to allow engineers to SSH outbound but not any other users in the organization.

Network-based policies in Cloudflare Gateway

It doesn’t matter which corporate device engineers are using or where they are located, they will be allowed to use SSH and all other users will be blocked.

One more thing

Last month, we announced the ability for customers to create private networks on Cloudflare. Using Cloudflare Tunnel, organizations can connect environments they control using private IP space and route traffic between sites; better, WARP users can connect to those private networks wherever they’re located. No need for centralized VPN concentrators and complicated configurations–connect your environment to Cloudflare and configure routing.

Network-based policies in Cloudflare Gateway

Today’s announcement gives administrators the ability to configure network access policies to control traffic within those private networks. What if the engineer above wasn’t trying to SSH to an Internet-accessible resource but to something an organization deliberately wants to keep within an internal private network (e.g., a development server)? Again, not everyone in the organization should have access to that either. Now administrators can configure identity-based rules that apply to private networks built on Cloudflare.

What’s next?

We’re laser-focused on our Cloudflare One goal to secure organizations regardless of how their traffic gets to Cloudflare. Applying network policies to both WARP users and routing between private networks is part of that vision.

We’re excited to release these building blocks to Zero Trust Network Access policies to protect an organization’s users and data. We can’t wait to dig deeper into helping organizations secure applications that use private hostnames and IPs like they can today with their publicly facing applications.

We’re just getting started–follow this link so you can too.

Integrating Cloudflare Gateway and Access

Post Syndicated from Kenny Johnson original https://blog.cloudflare.com/integrating-cloudflare-gateway-and-access/

Integrating Cloudflare Gateway and Access

We’re excited to announce that you can now set up your Access policies to require that all user traffic to your application is filtered by Cloudflare Gateway. This ensures that all of the traffic to your self-hosted and SaaS applications is secured and centrally logged. You can also use this integration to build rules that determine which users can connect to certain parts of your SaaS applications, even if the application does not support those rules on its own.

Stop threats from returning to your applications and data

We built Cloudflare Access as an internal project to replace our own VPN. Unlike a traditional private network, Access follows a Zero Trust model. Cloudflare’s edge checks every request to protected resources for identity and other signals like device posture (i.e., information about a user’s machine, like Operating system version, if antivirus is running, etc.).

By deploying Cloudflare Access, our security and IT teams could build granular rules for each application and log every request and event. Cloudflare’s network accelerated how users connected. We launched Access as a product for our customers in 2018 to share those improvements with teams of any size.

Integrating Cloudflare Gateway and Access

Over the last two years, we added new types of rules that check for hardware security keys, location, and other signals. However, we were still left with some challenges:

  • What happened to devices before they connected to applications behind Access? Were they bringing something malicious with them?
  • Could we make sure these devices were not leaking data elsewhere when they reached data behind Access?
  • Had the credentials used for a Cloudflare Access login been phished elsewhere?
Integrating Cloudflare Gateway and Access

We built Cloudflare Gateway to solve those problems. Cloudflare Gateway sends all traffic from a device to Cloudflare’s network, where it can be filtered for threats, file upload/download, and content categories.

Administrators deploy a lightweight agent on user devices that proxies all Internet-bound traffic through Cloudflare’s network. As that traffic arrives in one of our data centers in 200 cities around the world, Cloudflare’s edge inspects the traffic. Gateway can then take actions like prevent users from connecting to destinations that contain malware or block the upload of files to unapproved locations.

With today’s launch, you can now build Access rules that restrict connections to devices that are running Cloudflare Gateway. You can configure Cloudflare Gateway to run in always-on mode and ensure that the devices connecting to your applications are secured as they navigate the rest of the Internet.

Log every connection to every application

In addition to filtering, Cloudflare Gateway also logs every request and connection made from a device. With Gateway running, your organization can audit how employees use SaaS applications like Salesforce, Office 365, and Workday.

Integrating Cloudflare Gateway and Access

However, we’ve talked to several customers who share a concern over log integrity — “what stops a user from bypassing Gateway’s logging by connecting to a SaaS application from a different device?” Users could type in their password and use their second factor authentication token on a different device — that way, the organization would lose visibility into that corporate traffic.

Today’s release gives your team the ability to ensure every connection to your SaaS applications uses Cloudflare Gateway. Your team can integrate Cloudflare Access, and its ruleset, into the login flow of your SaaS applications. Cloudflare Access checks for additional factors when your users log in with your SSO provider. By adding a rule to require Cloudflare Gateway be used, you can prevent users from ever logging into a SaaS application without connecting through Gateway.

Build data control rules in SaaS applications

One other challenge we had internally at Cloudflare is that we lacked the ability to add user-based controls in some of the SaaS applications we use. For example, a team member connecting to a data visualization application had access to dashboards created by other teams, that they shouldn’t have access to.

We can use Cloudflare Gateway to solve that problem. Gateway provides the ability to restrict certain URLs to groups of users; this allows us  to add rules that only let specific team members reach records that live at known URLs.

Integrating Cloudflare Gateway and Access

However, if someone is not using Gateway, we lose that level of policy control. The integration with Cloudflare Access ensures that those rules are always enforced. If users are not running Gateway, they cannot login to the application.

What’s next?

You can begin using this feature in your Cloudflare for Teams account today with the Teams Standard or Teams enterprise plan. Documentation is available here to help you get started.

Want to try out Cloudflare for Teams? You can sign up for Teams today on our free plan and test Gateway’s DNS filtering and Access for up to 50 users at no cost.

Configure identity-based policies in Cloudflare Gateway

Post Syndicated from Pete Zimmerman original https://blog.cloudflare.com/configure-identity-based-policies-in-cloudflare-gateway/

Configure identity-based policies in Cloudflare Gateway

Configure identity-based policies in Cloudflare Gateway

During Zero Trust Week in October, we released HTTP filtering in Cloudflare Gateway, which expands protection beyond DNS threats to those at the HTTP layer as well. With this feature, Cloudflare WARP proxies all Internet traffic from an enrolled device to a data center in our network. Once there, Cloudflare Gateway enforces organization-wide rules to prevent data loss and protect team members.

However, rules are not one-size-fits-all. Corporate policies can vary between groups or even single users. For example, we heard from customers who want to stop users from uploading files to cloud storage services except for a specific department that works with partners. Beyond filtering, security teams asked for the ability to audit logs on a user-specific basis. If a user account was compromised, they needed to know what happened during that incident.

We’re excited to announce the ability for administrators to create policies based on a user’s identity and correlate that identity to activity in the Gateway HTTP logs. Your team can reuse the same identity provider integration configured in Cloudflare Access and start building policies tailored to your organization today.

Fine-grained rule enforcement

Until today, organizations could protect their users’ Internet-bound traffic by configuring DNS and HTTP policies that applied to every user. While that makes it simple to configure policies to enforce content restrictions and mitigate security threats, any IT administrator knows that for every policy there’s an exception to that policy.

Configure identity-based policies in Cloudflare Gateway

For example, a corporate content policy might restrict users from accessing social media —  which is not ideal for a marketing team that needs to manage digital marketing campaigns. Administrators can now configure a rule in Gateway to ensure a marketing team can always reach social media from their corporate devices.

Configure identity-based policies in Cloudflare Gateway

To meet corporate policy requirements for the rest of the organization, the administrator can then build a second rule to block all social media. They can drag-and-drop that rule below the marketing team’s rule, giving it a lower precedence so that anyone not in marketing will instead be evaluated against this policy.

Configure identity-based policies in Cloudflare Gateway

Identity integration and filtering options

Cloudflare Gateway leverages the integration between your chosen identity provider (IdP) and Cloudflare Access to add identity to rules and logs. Customers can integrate one or more providers at the same time, including corporate providers like Okta and Azure AD, as well as public providers like GitHub and LinkedIn.

Configure identity-based policies in Cloudflare Gateway

When users first launch the WARP client, they will be prompted to authenticate with one of the providers configured. Once logged in, Cloudflare Gateway can send their traffic through your organization’s policies and attribute each connection to the user’s identity.

Depending on what your IdP supports, you can create rules based on the following attributes:

Attribute Example
User Name John Doe
User Email [email protected]
User Group Name* Marketing Team
User Group Email* [email protected]
User Group ID 1234

*Note: some IdPs use group email in place of a group name

Cloudflare Gateway gives teams the ability to create fine-grained rules that meet the real needs of IT administrators. But policy enforcement is only one side of the equation — protecting users and preventing corporate data loss requires visibility into Internet traffic across an organization, for auditing compliance or security incident investigations.

User-level visibility in activity logs

In addition to the ability to create identity-based rules, IT administrators can use the Gateway activity logs to filter the HTTP traffic logs for specific users and device IDs. This is critical for reasons with varying degrees of seriousness: on one end an administrator can identify users who are attempting to bypass content security policies, and on the other end, that administrator can identify users or devices that may be compromised.

Configure identity-based policies in Cloudflare Gateway

Securing your team from Internet threats requires IT or security administrators to keep pace with evolving attackers and, just as importantly, maintain full visibility on what’s happening to your users and data. Cloudflare Gateway now allows you to do both, so your team can get back to what matters.

One more thing

At the end of Zero Trust Week, we announced our Cloudflare Isolated Browser to protect organizations from Internet threats unknown to threat intelligence (i.e., zero-day attacks). By integrating with Gateway, organizations can use the Remote Browser to provide higher levels of security to individual users who might be targets of spear phishing campaigns.

For example, consider an employee in the finance department who interfaces with systems handling procurements or fund disbursement. A security team might consider preventing this employee from accessing the public Internet with their native browser and forcing that traffic into an isolated remote browser. Any traffic destined to internal systems would use the native browser. To create this policy, an administrator could create the following rules:

Configure identity-based policies in Cloudflare Gateway

While other Gateway rules protect you from known threats, the isolate rule can help guard against everything else. Your team can build rules that isolate traffic based on identity or content without requiring the user to switch between browsers or client applications.

Cloudflare Browser Isolation is available in private beta today; you can sign up to join the wait list here.

What’s next?

We’re excited to bring customers with us on our journey to providing a full Secure Web Gateway with features such as network-level rules, in-line anti-virus scanning, and data loss prevention. This feature is available to any Gateway Standard or Teams customer at no additional cost. We plan to extend these capabilities from individual remote users to branch offices and data centers.

Our goal is dead-simple integration and configuration of products that secure your users and data, so you can focus on bringing your own products into the world — we’re thrilled to help you do that. Follow this link to get started.

A quirk in the SUNBURST DGA algorithm

Post Syndicated from Nick Blazier original https://blog.cloudflare.com/a-quirk-in-the-sunburst-dga-algorithm/

A quirk in the SUNBURST DGA algorithm

A quirk in the SUNBURST DGA algorithm

On Wednesday, December 16, the RedDrip Team from QiAnXin Technology released their discoveries (tweet, github) regarding the random subdomains associated with the SUNBURST malware which was present in the SolarWinds Orion compromise. In studying queries performed by the malware, Cloudflare has uncovered additional details about how the Domain Generation Algorithm (DGA) encodes data and exfiltrates the compromised hostname to the command and control servers.

Background

The RedDrip team discovered that the DNS queries are created by combining the previously reverse-engineered unique guid (based on hashing of hostname and MAC address) with a payload that is a custom base 32 encoding of the hostname. The article they published includes screenshots of decompiled or reimplemented C# functions that are included in the compromised DLL. This background primer summarizes their work so far (which is published in Chinese).

RedDrip discovered that the DGA subdomain portion of the query is split into three parts:

<encoded_guid> + <byte> + <encoded_hostname>

An example malicious domain is:

7cbtailjomqle1pjvr2d32i2voe60ce2.appsync-api.us-east-1.avsvmcloud.com

Where the domain is split into the three parts as

Encoded guid (15 chars) byte Encoded hostname
7cbtailjomqle1p j vr2d32i2voe60ce2

The work from the RedDrip Team focused on the encoded hostname portion of the string, we have made additional insights related to the encoded hostname and encoded guid portions.

At a high level the encoded hostnames take one of two encoding schemes. If all of the characters in the hostname are contained in the set of domain name-safe characters "0123456789abcdefghijklmnopqrstuvwxyz-_." then the OrionImprovementBusinessLayer.CryptoHelper.Base64Decode algorithm, explained in the article, is used. If there are characters outside of that set in the hostname, then the OrionImprovementBusinessLayer.CryptoHelper.Base64Encode is used instead and ‘00’ is prepended to the encoding. This allows us to simply check if the first two characters of the encoded hostname are ‘00’ and know how the hostname is encoded.

These function names within the compromised DLL are meant to resemble the names of legitimate functions, but in fact perform the message encoding for the malware. The DLL function Base64Decode is meant to resemble the legitimate function name base64decode, but its purpose is actually to perform the encoding of the query (which is a variant of base32 encoding).

The RedDrip Team has posted Python code for encoding and decoding the queries, including identifying random characters inserted into the queries at regular character intervals.

One potential issue we encountered with their implementation is the inclusion of a check clause looking for a ‘0’ character in the encoded hostname (line 138 of the decoding script). This line causes the decoding algorithm to ignore any encoded hostnames that do not contain a ‘0’. We believe this was included because ‘0’ is the encoded value of a ‘0’, ‘.’, ‘-’ or ‘_’. Since fully qualified hostnames are comprised of multiple parts separated by ‘.’s, e.g. ‘example.com’, it makes sense to be expecting a ‘.’ in the unencoded hostname and therefore only consider encoded hostnames containing a ‘0’. However, this causes the decoder to ignore many of the recorded DGA domains.

As we explain below, we believe that long domains are split across multiple queries where the second half is much shorter and unlikely to include a ‘.’. For example ‘www2.example.c’ takes up one message, meaning that in order to transmit the entire domain ‘www2.example.c’ a second message containing just ‘om’ would also need to be sent. This second message does not contain a ‘.’ so its encoded form does not contain a ‘0’ and it is ignored in the RedDrip team’s implementation.

The quirk: hostnames are split across multiple queries

A list of observed queries performed by the malware was published publicly on GitHub. Applying the decoding script to this set of queries, we see some queries appear to be truncated, such as grupobazar.loca, but also some decoded hostnames are curiously short or incomplete, such as “com”, “.com”, or a single letter, such as “m”, or “l”.

When the hostname does not fit into the available payload section of the encoded query, it is split up across multiple queries. Queries are matched up by matching the GUID section after applying a byte-by-byte exclusive-or (xor).

Analysis of first 15 characters

Noticing that long domains are split across multiple requests led us to believe that the first 16 characters encoded information to associate multipart messages. This would allow the receiver on the other end to correctly re-assemble the messages and get the entire domain. The RedDrip team identified the first 15 bytes as a GUID, we focused on those bytes and will refer to them subsequently as the header.

We found the following queries that we believed to be matches without knowing yet the correct pairings between message 1 and message 2 (payload has been altered):

Part 1 – Both decode to “www2.example.c”
r1q6arhpujcf6jb6qqqb0trmuhd1r0ee.appsync-api.us-west-2.avsvmcloud.com
r8stkst71ebqgj66qqqb0trmuhd1r0ee.appsync-api.us-west-2.avsvmcloud.com

Part 2 – Both decode to “om”
0oni12r13ficnkqb2h.appsync-api.us-west-2.avsvmcloud.com
ulfmcf44qd58t9e82h.appsync-api.us-west-2.avsvmcloud.com

This gives us a final combined payload of www2.example.com

This example gave us two sets of messages where we were confident the second part was associated with the first part, and allowed us to find the following relationship where message1 is the header of the first message and message2 is the header of the second:

Base32Decode(message1) XOR KEY = Base32Decode(message2)

The KEY is a single character. That character is xor’d with each byte of the Base32Decoded first header to produce the Base32Decoded second header. We do not currently know how to infer what character is used as the key, but we can still match messages together without that information. Since A XOR B = C where we know A and C but not B, we can instead use A XOR C = B. This means that in order to pair messages together we simply need to look for messages where XOR’ing them together results in a repeating character (the key).

Base32Decode(message1) XOR Base32Decode(message2) = KEY

Looking at the examples above this becomes

Message 1 Message 2
Header r1q6arhpujcf6jb 0oni12r13ficnkq
Base32Decode (binary) 101101000100110110111111011
010010000000011001010111111
01111000101001110100000101
110110010010000011010010000
001000110110110100111100100
00100011111111000000000100

We’ve truncated the results slightly, but below shows the two binary representations and the third line shows the result of the XOR.

101101000100110110111111011010010000000011001010111111011110001010011101
110110010010000011010010000001000110110110100111100100001000111111110000
011011010110110101101101011011010110110101101101011011010110110101101101

We can see the XOR result is the repeating sequence ‘01101101’meaning the original key was 0x6D or ‘m’.

We provide the following python code as an implementation for matching paired messages (Note: the decoding functions are those provided by the RedDrip team):

# string1 is the first 15 characters of the first message
# string2 is the first 15 characters of the second message
def is_match(string1, string2):
    encoded1 = Base32Decode(string1)
    encoded2 = Base32Decode(string2)
    xor_result = [chr(ord(a) ^ ord(b)) for a,b in zip(encoded1, encoded2)]
    match_char = xor_result[0]
    for character in xor_result[0:9]:
        if character != match_char:
            return False, None
    return True, "0x{:02X}".format(ord(match_char))

The following are additional headers which based on the payload content Cloudflare is confident are pairs (the payload has been redacted because it contains hostname information that is not yet publicly available):

Example 1:

vrffaikp47gnsd4a
aob0ceh5l8cr6mco

xorkey: 0x4E

Example 2:

vrffaikp47gnsd4a
aob0ceh5l8cr6mco

xorkey: 0x54

Example 3:

vvu7884g0o86pr4a
6gpt7s654cfn4h6h

xorkey: 0x2B

We hypothesize that the xorkey can be derived from the header bytes and/or padding byte of the two messages, though we have not yet determined the relationship.

Trend data on the SolarWinds Orion compromise

Post Syndicated from Malavika Balachandran Tadeusz original https://blog.cloudflare.com/solarwinds-orion-compromise-trend-data/

Trend data on the SolarWinds Orion compromise

Trend data on the SolarWinds Orion compromise

On Sunday, December 13, FireEye released a report on a sophisticated supply chain attack leveraging SolarWinds’ Orion IT monitoring software. The malware was distributed as part of regular updates to Orion and had a valid digital signature.

One of the notable features of the malware is the way it hides its network traffic using a multi-staged approach. First, the malware determines its command and control (C2) server using a domain generation algorithm (DGA) to construct and resolve a subdomain of avsvmcloud[.]com.

These algorithmically generated strings are added as a subdomain of one of the following domain names to create a new fully-qualified domain name to resolve:

.appsync-api[.]eu-west-1[.]avsvmcloud[.]com
.appsync-api[.]us-west-2[.]avsvmcloud[.]com
.appsync-api[.]us-east-1[.]avsvmcloud[.]com
.appsync-api[.]us-east-2[.]avsvmcloud[.]com

An example of such a domain name might look like: hig4gcdkgjkrt24v6isue7ax09nksd[.]appsync-api[.]eu-west-1[.]avsvmcloud[.]com

The DNS query response to a subdomain of one of the above will return a CNAME record that points to another C2 domain, which is used for data exfiltration. The following subdomains were identified as the C2 domains used for data exfiltration:

freescanonline[.]com
deftsecurity[.]com
thedoccloud[.]com
websitetheme[.]com
highdatabase[.]com
incomeupdate[.]com
databasegalore[.]com
panhardware[.]com
zupertech[.]com
virtualdataserver[.]com
digitalcollege[.]org

Malware activity seen on Cloudflare’s public DNS resolver 1.1.1.1

Using the published details about the network observables of the malware, we analyzed DNS query traffic to the identified malicious hostnames. Because 1.1.1.1 has a strong, audited privacy policy, we are unable to identify the source IP of users connecting to the malicious hostname — we can only see aggregated trends.

We first noticed a spike in DNS traffic through Cloudflare’s 1.1.1.1 resolver to avsvmcloud[.]com starting in April 2020:

Trend data on the SolarWinds Orion compromise

Reviewing the subdomain data, a specific pattern of DGA domains emerged as early as April. These subdomains followed a format, (e.g. {dga-string}[.]appsync-api[.]{region}[.]avsvmcloud[.]com). As time went on, the attackers added more unique subdomains. The graph below depicts the unique newly observed subdomains of avsvmcloud[.]com on a weekly basis.

Trend data on the SolarWinds Orion compromise

As illustrated in the graphs, we noticed a major rise in activity over the summer, with total subdomains observed reaching steady state in September.

Trend data on the SolarWinds Orion compromise

While the growth of unique names slowed down starting in October, the geographic distribution continued to change during the entire course of the attack. During the first few weeks of the attack, queries originated almost entirely from clients in North America and Europe. In May, the source of queries began to spread across the globe. By July, the queries began to cluster again, this time in South America, before returning to originate primarily from North America in November.

Trend data on the SolarWinds Orion compromise

Protecting our customers from malicious activity

Cloudflare’s 1.1.1.1 resolver has strict privacy protections, so we can only see trends of this attack. We cannot notify users that they might be compromised, because we intentionally do not know who those users are. For customers of Cloudflare Gateway, however, we can help them block these types of threats, and identify cases where they might be compromised.

Cloudflare Gateway consists of features that secure how users and devices connect to the Internet. Gateway’s DNS filtering feature is built on the same technology that powers 1.1.1.1, and adds security filtering and logging.

Following the FireEye report, Cloudflare blocked access to the C2 domains used in this attack for customers using the “Malware” category in Gateway, as well as for customers using 1.1.1.1 for Families (1.1.1.2/3).

Our response team is working with customers to search logs for queries related to the malicious domains. Gateway customers can also download logs of their DNS query traffic and investigate on their own.

Introducing Cloudflare One Intel

Post Syndicated from Malavika Balachandran Tadeusz original https://blog.cloudflare.com/cloudflare-one-intel/

Introducing Cloudflare One Intel

Introducing Cloudflare One Intel

Earlier this week, we announced Cloudflare One, a single platform for networking and security management. Cloudflare One extends the speed, reliability, and security we’ve brought to Internet properties and applications over the last decade to make the Internet the new enterprise WAN.

Underpinning Cloudflare One is Cloudflare’s global network – today, our network spans more than 200 cities worldwide and is within milliseconds of nearly everyone connected to the Internet. Our network handles, on average, 18 million HTTP requests and 6 million DNS requests per second. With 1 billion unique IP addresses connecting to the Cloudflare network each day, we have one of the broadest views on Internet activity worldwide.

We see a large diversity of Internet traffic across our entire product suite. Every day, we block 72 billion cyberthreats. This visibility provides us with a unique position to understand and mitigate Internet threats, and enables us to see new threats and malware before anyone else.

At the beginning of this month, as part of our 10th Birthday Week, we launched Cloudflare Radar, which shares high-level trends with the general public based on our network’s aggregate data. The same data that powers that view of the Internet also gives us the ability to create new insights to keep your team safer.

Today, we are excited to announce the next phase of network and threat intelligence at Cloudflare: the launch of Cloudflare One Intel. Cloudflare One Intel streamlines network and security operations by converting the data we can gather on our network into actionable insights.

The challenge with the traditional security operations

Most enterprises use a large array of point solutions to ensure that the corporate network remains fast, available and secure. Security teams typically aggregate logs from these point solutions into their SIEM and create custom alerts for incident detection.

Once an incident has been detected, security teams will quickly respond with remediating actions to prevent data loss, such as removing a compromised device’s access controls or adding a malicious hostname or URL to a block list.

Along with incident remediation, security teams will conduct an investigation of the incident to uncover more details about the attacker. Pivoting across historical DNS records, SSL certificate fingerprints, malware samples, and other indicators of compromise, security researchers will try to uncover more details about an attacker. Linked indicators then get fed back onto block lists in point solutions to prevent subsequent attacks.

However, there are several challenges with traditional incident detection and response. Security operations teams are often overwhelmed by the plethora of logs and alerts. With threat intelligence, SIEMs, and control planes all in different platforms, incident detection, remediation and forensics can be slow, arduous, and expensive.

Improving Incident Response with Cloudflare One

We want to make network and security operations as streamlined as possible. Cloudflare One Intel helps network and security teams detect and respond to incidents more efficiently. That means bringing together insights from your network activity, global Internet intelligence, and automated remediation in a single platform.

As part of the mission to help security teams detect and block emerging security threats more efficiently we are releasing two features within Cloudflare Gateway: DNS tunneling detection and domain insights.

What is DNS Tunneling?

DNS tunneling is the misuse of the Domain Name System (DNS) protocol to encode another protocol’s data into a series of DNS queries and response messages. DNS tunneling is often used to circumvent a corporate firewall. For example, DNS tunneling might be used to visit a website that is blocked on the corporate firewall, distribute malware from a command & control server, or exfiltrate sensitive data.

DNS tunneling isn’t only used for malicious activities. One of the most common uses of DNS tunneling is by antivirus software, which will often use DNS tunneling to look up file signatures.

Blocking DNS tunneling using Cloudflare Gateway

Starting today, customers using Cloudflare Gateway can block hostnames associated with DNS tunneling using the “DNS Tunneling” filter in Gateway’s DNS filtering policies. This feature is available to all Gateway users at no additional cost.

You can begin using the filter by navigating to the Policies section of the Gateway product and selecting the “Security Threats” tab. Once you check the “DNS Tunneling” box, Gateway will automatically block any requests made by your organization’s users to domains on this list. Should you want to manually override any specific domains, you can use the “Domain Override” feature to remove the block policy on a specific domain.

Introducing Cloudflare One Intel

We previously included known malicious DNS tunnels in our “Anonymizer” category within Gateway’s security threat categories. We are now pulling that into its own category so that customers can have more granular visibility into threats on their network. Further, we are expanding the filter beyond known malicious DNS tunnels to include newly emerging threats, so that customers can block these threats as soon as we see them on our network.

How we use machine learning to detect DNS tunneling

Using machine learning, Cloudflare detects anomalous DNS request patterns and flags these requests as suspected DNS tunneling. Our model analyzes requests and detects anomalous behavior at a frequency of every five minutes.

Once a set of requests is flagged, we add the associated hostname to our “DNS Tunneling” category. We do not add hostnames of commonly allowed DNS tunnels to this list, such as those used by antivirus software.

Our model not only blocks hostnames associated with DNS tunneling seen on your network, but across the entire Cloudflare network. Processing over 500 billion DNS queries each day, we have unique insight into global DNS traffic patterns.

Adding transparency to security

Cloudflare’s unique insight into global Internet traffic is what powers the intelligence behind Cloudflare One. DNS tunneling detection is one example of how we use aggregated data from our network to improve Internet security for everyone. But, until now, that has been opaque to users.

Security teams investigating the threats that impact their organization need more transparency. Cloudflare One Intel consolidates the information we have about the potentially harmful sites and properties that can target your organization.

Starting today, with a single click, administrators reviewing logs in Cloudflare Gateway can get a comprehensive breakdown of any site being allowed or blocked.

In this expanded view, you can now click the “View Domain Insights” button, which will take you to the Cloudflare Radar Domain Insights page for the requested hostname. This feature is available to all Gateway users at no additional cost.

Introducing Cloudflare One Intel
Introducing Cloudflare One Intel

What’s Next

These new features are just the beginning of Cloudflare One Intel. Over the coming weeks and months, we’ll be rolling out more features across the Cloudflare One platform that will make our Internet intelligence more accessible and actionable. Stay tuned for premium features available in Cloudflare Radar for Cloudflare Gateway customers.

Get started now

Cloudflare Radar is available to everyone for free – you can check it out here and start exploring our Internet intelligence.

To protect your team from threats on the Internet that utilize DNS tunnelling, sign up for a Cloudflare Gateway account and use the Security filter setting to block DNS tunnelling attempts. DNS-based security and content filtering is available for free across every Gateway plan.

Introducing WARP for Desktop and Cloudflare for Teams

Post Syndicated from Kyle Krum original https://blog.cloudflare.com/warp-for-desktop/

Introducing WARP for Desktop and Cloudflare for Teams

Introducing WARP for Desktop and Cloudflare for Teams

Cloudflare launched ten years ago to keep web-facing properties safe from attack and fast for visitors. Cloudflare customers owned Internet properties that they placed on our network. Visitors to those sites and applications enjoyed a faster experience, but that speed was not consistent for accessing Internet properties outside the Cloudflare network.

Over the last few years, we began building products that could help deliver a faster and safer Internet to everyone, not just visitors to sites on our network. We started with the first step to visiting any website, a DNS query, and released the world’s fastest public DNS resolver, 1.1.1.1. Any Internet user could improve the speed to connect to any website simply by changing their resolver.

While making the Internet faster for users, we also focused on making it more private. We built 1.1.1.1 to accelerate the last mile of connections, from user to our edge or other destinations on the Internet. Unlike other providers, we did not build it to sell ads.

Last year we went one step further to make the entire connection from a device both faster and safer when we launched Cloudflare WARP. With the push of a button, users could connect their mobile device to the entire Internet using a WireGuard tunnel through a Cloudflare data center near to them. Traffic to sites behind Cloudflare became even faster and a user’s experience with the rest of the Internet became more secure and private.

We brought that experience to desktops in beta earlier this year, and are excited to announce the general availability of Cloudflare WARP for desktop users today. The entire Internet can now be more secure and private regardless of how you connect.

Bringing the power of WARP to security teams everywhere

WARP made the Internet faster and more private for individual users everywhere. But as businesses embraced remote work models at scale, security teams struggled to extend the security controls they had enabled in the office to their remote workers. Today, we’re bringing everything our users have come to expect from WARP to security teams. The release also enables new functionality in our Cloudflare Gateway product.

Customers can use the Cloudflare WARP application to connect corporate desktops to Cloudflare Gateway for advanced web filtering. The Gateway features rely on the same performance and security benefits of the underlying WARP technology, now with security filtering available to the connection.

The result is a simple way for enterprises to protect their users wherever they are without requiring the backhaul of network traffic to a centralized security boundary. Instead, organizations can configure the WARP client application to securely and privately send remote users’ traffic through a Cloudflare data center near them. Gateway administrators apply policies to outbound Internet traffic proxied through the client, allowing organizations to protect users from threats on the Internet, and stop corporate data from leaving their organization.

Privacy, Security and Speed for Everyone

WARP was built on the philosophy that even people who don’t know what “VPN” stands for should be able to still easily get the protection a VPN offers. For those of us unfortunately very familiar with traditional corporate VPNs, something better was needed. Enter our own WireGuard implementation called BoringTun.

The WARP application uses BoringTun to encrypt all the traffic from your device and send it directly to Cloudflare’s edge, ensuring that no one in between is snooping on what you’re doing. If the site you are visiting is already a Cloudflare customer, the content is immediately sent down to your device. With WARP+ we use Argo Smart Routing to to devise the shortest path through our global network of data centers to reach whomever you are talking to.

Introducing WARP for Desktop and Cloudflare for Teams

Combined with the power of 1.1.1.1 (the world’s fastest public DNS resolver), WARP keeps your traffic secure, private and fast. Since nearly everything you do on the Internet starts with a DNS request, choosing the fastest DNS server across all your devices will accelerate almost everything you do online. Speed isn’t everything though, and while the connection between your application and a website may be encrypted, DNS lookups for that website were not. This allowed anyone, even your Internet Service Provider, to potentially snoop (and sell) on where you are going on the Internet.

Cloudflare will never snoop or sell your personal data. And if you use DNS-over-HTTPS or DNS-over-TLS to our 1.1.1.1 resolver, your DNS request will be sent over a secure channel. This means that if you use the 1.1.1.1 resolver then in addition to our privacy guarantees an eavesdropper can’t see your DNS requests. Don’t take our word for it though, earlier this year we published the results of a third-party privacy examination, something we’ll keep doing and wish others would do as well.

For Gateway customers, we are committed to privacy and trust and will never sell your personal data to third parties. While your administrator will have the ability to audit your organization’s traffic, create rules around how long data is retained, or create specific policies about where they can go, Cloudflare will never sell your personal data or use your personal data to retarget you with advertisements. Privacy and control of your organization’s data is in your hands.

Now integrated with Cloudflare Gateway

Traditionally, companies have used VPN solutions to gate access to corporate resources and keep devices secure with their filtering rules. These connections quickly became a point of failure (and intrusion vector) as organizations needed to manage and scale up VPN servers as traffic through their on premise servers grew. End users didn’t like it either. VPN servers were usually overwhelmed at peak times, the client was bulky and they were rarely made with performance in mind. And once a bad actor got in, they had access to everything.

Introducing WARP for Desktop and Cloudflare for Teams
Traditional VPN architecture‌‌

In January 2020, we launched Cloudflare for Teams as a replacement to this model. Cloudflare for Teams is built around two core products. Cloudflare Access is a Zero Trust solution allowing organizations to connect internal (and now, SaaS) applications to Cloudflare’s edge and build security rules to enforce safe access to them. No longer were VPNs a single entry point to your organization; users could work from anywhere and still get access. Cloudflare Gateway’s first features focused on protecting users from threats on the Internet with a DNS resolver and policy engine built for enterprises.

The strength and power of WARP clients, used today by millions of users around the world, will enable incredible new use cases for security teams:

  • Encrypt all user traffic – Regardless of your users’ location, all traffic from their device is encrypted with WARP and sent privately to the nearest WARP endpoint. This keeps your users and your organizations protected from whomever may be snooping. If you still used a traditional VPN on top of Access to encrypt user traffic, that is no longer needed.
  • WARP+ – Cloudflare offers a premium WARP+ service for customers who want additional speed benefits. That now comes packaged into Teams deployments. Any Teams customer who deploys the Teams client applications will automatically receive the premium speed benefits of WARP+.
  • Gateway for remote workers – Until today, Gateway required that you keep track of all your users’ IP addresses and build policies per location. This made it difficult to enforce policy or provide malware protection when a user took their device to a new location. With the client installed, these policies can be enforced anywhere.
  • L7 Firewall and user based policies – Today’s announcement of Cloudflare Gateway SWG and Secure DNS allows your organization to enforce device authentication to your Teams account, enabling you to build user-specific policies and force all traffic through the firewall.
  • Device and User auditing – Along with user and device policies, administrators will also be able to audit specific user and device traffic. Used in conjunction with logpush, this will allow your organization to do detailed level tracing in case of a breach or audit.
Introducing WARP for Desktop and Cloudflare for Teams

Enroll your organization to use the WARP client with Cloudflare for Teams

We know how hard it can be to deploy another piece of software in your organization, so we’ve worked hard to make deployment easy. To get started, just navigate to our sign-up page and create an account. If you already have an active account, you can bypass this step and head straight to the Cloudflare for Teams dashboard where you’ll be dropped directly into our onboarding flow. After you have signed up and configured your team, setup a Gateway policy and then choose one of the three ways to install the clients to enforce that policy from below:

Self Install
If you are a small organization without an IT department, asking your users to download the client themselves and type in the required settings is the fastest way to get going.

Introducing WARP for Desktop and Cloudflare for Teams
Manually join an organization‌‌

Scripted Install
Our desktop installers support the ability to quickly script the installation. In the case of Windows, this is as easy as this command line:

Cloudflare_WARP_Release-x64.msi /quiet ORGANIZATION="<insert your org>" SERVICE_MODE="warp" ENABLE="true" GATEWAY_UNIQUE_ID="<insert your gateway DoH domain>" SUPPORT_URL=”<mailto or http of your support person>"

Managed Device
Organizations with MDM tools like Intune or JAMF can deploy WARP to their entire fleet of devices from a single operation. Just as you preconfigure all other device settings, WARP can be set so that all end users need to do is login with your team’s identity provider by clicking on the Cloudflare WARP client after it has been deployed.

Introducing WARP for Desktop and Cloudflare for Teams
Microsoft Intune Configuration

For a complete list of the installation options, required fields and step by step instructions for all platforms see the WARP Client documentation.

What’s coming next

There is still more we want to build for both our consumer users of WARP and our Cloudflare for Teams customers. Here’s a sneak peek at some of the ones we are most excited about (and allowed to share):

  • New partner integrations with CrowdStrike and VMware Carbon Black (Tanium available today) will allow you to build even more comprehensive Cloudflare Access policies that check for device health before allowing users to connect to applications
  • Split Tunnel support will allow you or your organization to specify applications, sites or IP addresses that should be excluded from WARP. This will allow content like games, streaming services, or any application you choose to work outside the connection.
  • BYOD device support, especially for mobile clients. Enterprise users that are not on the clock should be able to easily toggle off “office mode,” so corporate policies don’t limit personal use of their personal devices.
  • We are still missing one major operating system from our client portfolio and Linux support is coming.

Download now

We are excited to finally share these applications with our customers. We’d especially like to thank our Cloudflare MVP’s, the 100,000+ beta users on desktop, and the millions of existing users on mobile who have helped grow WARP into what it is today.

You can download the applications right now from https://one.one.one.one

Cloudflare Gateway now protects teams, wherever they are

Post Syndicated from Pete Zimmerman original https://blog.cloudflare.com/gateway-swg/

Cloudflare Gateway now protects teams, wherever they are

Cloudflare Gateway now protects teams, wherever they are

In January 2020, we launched Cloudflare for Teams—a new way to protect organizations and their employees globally, without sacrificing performance. Cloudflare for Teams centers around two core products – Cloudflare Access and Cloudflare Gateway.

In March 2020, Cloudflare launched the first feature of Cloudflare Gateway, a secure DNS filtering solution powered by the world’s fastest DNS resolver. Gateway’s DNS filtering feature kept users safe by blocking DNS queries to potentially harmful destinations associated with threats like malware, phishing, or ransomware. Organizations could change the router settings in their office and, in about five minutes, keep the entire team safe.

Shortly after that launch, entire companies began leaving their offices. Users connected from initially makeshift home offices that have become permanent in the last several months. Protecting users and data has now shifted from a single office-level setting to user and device management in hundreds or thousands of locations.

Security threats on the Internet have also evolved. Phishing campaigns and malware attacks have increased in the last six months. Detecting those types of attacks requires looking deeper than just the DNS query.

Starting today, we’re excited to announce two features in Cloudflare Gateway that solve those new challenges. First, Cloudflare Gateway now integrates with the Cloudflare WARP desktop client. We built WARP around WireGuard, a modern, efficient VPN protocol that is much more efficient and flexible than legacy VPN protocols.

Second, Cloudflare Gateway becomes a Secure Web Gateway and performs L7 filtering to inspect traffic for threats that hide below the surface. Like our DNS filtering and 1.1.1.1 resolver, both features are powered by everything we’ve learned by offering Cloudflare WARP to millions of users globally.

Securing the distributed workforce

Our customers are largely distributed workforces with employees split between corporate offices and their homes. Due to the pandemic, this is their operating environment for the foreseeable future.

The fact that users aren’t located at fixed, known locations (with remote workers allowed by exception) has created challenges for already overworked IT staff:

  1. VPNs are an all-or-nothing approach to providing remote access to internal applications. We address this with Cloudflare Access and our Zero Trust approach to security for internal applications and now SaaS applications as well.
  2. VPNs are slow and expensive. However, backhauling traffic to a centralized security boundary has been the primary approach to enforcing corporate content and security policies to protect roaming users. Cloudflare Gateway was created to tackle this problem for our customers.

Until today, Cloudflare Gateway has provided security for our customers through DNS filtering. While this provides a level of security and content control that’s application-agnostic, it still leaves our customers with a few challenges:

  1. Customers need to register the source IP address of all locations that send DNS queries to Gateway, so their organization’s traffic can be identified for policy enforcement. This is tedious at best, if not intractable for larger organizations with hundreds of locations.
  2. DNS policies are relatively coarse, with enforcement performed with an all-or-nothing approach per domain. Organizations lack the ability to, for example, allow access to a cloud storage provider but block the download of harmful files from known-malicious URLs.
  3. Organizations that register IP addresses frequently use Network Address Translation (NAT) traffic in order to share public IP addresses across many users. This results in a loss of visibility into DNS activity logs at the individual user level. So while IT security admins can see that a malicious domain was blocked, they must leverage additional forensic tools to track down a potentially compromised device.

Starting today, we are taking Cloudflare Gateway beyond a secure DNS filtering solution by pairing the Cloudflare for Teams client with a cloud L7 firewall. Now our customers can toss out another hardware appliance in their centralized security boundary and provide enterprise-level security for their users directly from the Cloudflare edge.

Protecting users and preventing corporate data loss

DNS filtering provides a baseline level of security across entire systems and even networks, since it’s leveraged by all applications for Internet communications. However, application-specific protection offers granular policy enforcement and visibility into whether traffic should be classified as malicious.

Today we’re excited to extend the protection we offer through DNS filtering by adding an L7 firewall that allows our customers to apply security and content policies to HTTP traffic. This provides administrators with a better tool to protect users through granular controls within HTTP sessions, and with visibility into policy enforcement. Just as importantly, it also gives our customers greater control over where their data resides. By building policies, customers can specify whether to allow or block a request based on file type, on whether the request was to upload or download a file, or on whether the destination is an approved cloud storage provider for the organization.

Enterprises protect their users’ Internet traffic wherever they are by connecting to Cloudflare with the Cloudflare for Teams client. This client provides a fast, secure connection to the Cloudflare data center nearest them, and it relies on the same Cloudflare WARP application millions of users connect through globally. Because the client uses the same WARP application under the hood, enterprises can be sure it has been tested at scale to provide security without compromising on performance. Cloudflare WARP optimizes network performance by leveraging WireGuard for the connection to the Cloudflare edge.

The result is a secure, performant connection for enterprise users wherever they are without requiring the backhaul of network traffic to a centralized security boundary. By connecting to Cloudflare Gateway with the Cloudflare for Teams client, enterprise users are protected through filtering policies applied to all outbound Internet traffic–protecting users as they navigate the Internet and preventing the loss of corporate data.

Cloudflare Gateway now supports HTTP traffic filtering based on a variety of criteria including:

Criteria Example
URL, path, and/or query string https://www.myurl.com/path?query
HTTP method GET, POST, etc.
HTTP response code 500
File type and file name myfilename.zip
MIME type application/zip
URL security or content category Malware, phishing, adult themes

To complement DNS filtering policies, IT admins can now create L7 firewall rules to apply granular policies on HTTP traffic.

For example, an admin may want to allow users to navigate to useful parts of Reddit, but block undesirable subreddits.

Cloudflare Gateway now protects teams, wherever they are

Or to prevent data loss, an admin could create a rule that allows users to receive content from popular cloud storage providers but not upload select file types from corporate devices.

Cloudflare Gateway now protects teams, wherever they are

Another admin might want to prevent malicious files from being smuggled in through zip file downloads, so they may decide to configure a rule to block downloads of compressed file types.

Cloudflare Gateway now protects teams, wherever they are

Having used our DNS filtering categories to protect internal users, an admin may want to simply block security threats based on the classification of full URLs. Malware payloads are frequently disseminated from cloud storage and with DNS filtering an admin has to choose whether to allow or deny access to the entire domain for a given storage provider. URL filtering gives admins the ability to filter requests for the exact URLs where malware payloads reside, allowing customers to continue to leverage the usefulness of their chosen storage provider.

Cloudflare Gateway now protects teams, wherever they are

And because all of this is made possible with the Cloudflare for Teams client, distributed workforces with roaming clients receive this protection wherever they are through a secure connection to the Cloudflare data center nearest them.

Cloudflare Gateway now protects teams, wherever they are

We’re excited to protect teams as they browse the Internet by inspecting HTTP traffic, but what about non-HTTP traffic? Later this year, we will extend Cloudflare Gateway by adding support for IP, port, and protocol filtering with a cloud L4 firewall. This will allow administrators to apply rules to all Internet-bound traffic, like rules that allow outbound SSH, or rules that determine whether to send HTTP traffic arriving on a non-standard port to the L7 firewall for HTTP inspection.

At launch, Cloudflare Gateway will allow administrators to create policies that filter DNS and HTTP traffic across all users in an organization. This creates a great baseline for security. However, exceptions are part of reality: a one-size-fits-all approach to content and security policy enforcement rarely matches the specific needs of all users.

To address this, we’re working on supporting rules based on user and group identity by integrating Cloudflare Access with a customer’s existing identity provider. This will let administrators create granular rules that also leverage context around the user, such as:

  • Deny access to social media to all users. But if John Doe is in the marketing group, allow him to access these sites in order to perform his job role.
  • Only allow Jane Doe to connect to specific SaaS applications through Cloudflare Gateway, or a certain device posture.

The need for policy enforcement and logging visibility based on identity arises from the reality that users aren’t tied to fixed, known workplaces. We meet that need by integrating identity and protecting users wherever they are with the Cloudflare for Teams client.

What’s next

People do not start businesses to deal with the minutiae of information technology and security. They have a vision and a product or service they want to get out in the world, and we want to get them back to doing that. We can help eliminate the hard parts around implementing advanced security tools that are usually reserved for larger, more sophisticated organizations, and we want to make them available to teams regardless of size.

The launch of both the Cloudflare for Teams client and L7 firewall lays the foundation for an advanced Secure Web Gateway with integrations including anti-virus scanning, CASB, and remote browser isolation—all performed at the Cloudflare edge. We’re excited to share this glimpse of the future our team has built—and we’re just getting started.

Get started now

All of these new capabilities are ready for you to use today. The L7 firewall is available in Gateway standalone, Teams Standard, and Teams Enterprise plans. You can get started by signing up for a Gateway account and following the onboarding directions.

Zero Trust For Everyone

Post Syndicated from Abe Carryl original https://blog.cloudflare.com/teams-plans/

Zero Trust For Everyone

We launched Cloudflare for Teams to make Zero Trust security accessible for all organizations, regardless of size, scale, or resources. Starting today, we are excited to take another step on this journey by announcing our new Teams plans, and more specifically, our Cloudflare for Teams Free plan, which protects up to 50 users at no cost. To get started, sign up today.

If you’re interested in how and why we’re doing this, keep scrolling.

Our Approach to Zero Trust

Cloudflare Access is one-half of Cloudflare for Teams – a Zero Trust solution that secures inbound connections to your protected applications. Cloudflare Access works like a bouncer, checking identity at the door to all of your applications.

The other half of Cloudflare for Teams is Cloudflare Gateway which, as our clever name implies, is a Secure Web Gateway protecting all of your users’ outbound connections to the Internet. To continue with this analogy, Cloudflare Gateway is your organization’s bodyguard, securing your users as they navigate the Internet.

Together, these two solutions provide a powerful, single dashboard to protect your users, networks, and applications from malicious actors.

Zero Trust For Everyone

A Mission-Driven Solution

At Cloudflare, our mission is to help build a better Internet. That means a better Internet for everyone, regardless of size, scale, or resources. With Cloudflare for Teams, our part in this mission is to keep your team members secure from unknown threats and your applications safe from attack, so that your team can focus on your business.

Earlier this year, shortly after we launched Cloudflare for Teams, organizations suddenly had to change the way they worked. Users left offices, and the security provided by those offices, to work from home. This accelerated the pace of IT transformation from years to days, or even hours.

To alleviate that burden, we provided Cloudflare for Teams for everyone at no cost, and with no restrictions until September 1, 2020. We also offered free one-on-one onboarding to make adoption seamless, and used those sessions to improve the product for our current users as well.

Moving forward, users will continue to work from home, and applications will continue to move away from managed data centers. While our initial free program is no longer available, our team wanted to find a new way to continue helping organizations of any size adjust to this new security model that seems to be here to stay.

The New Free Plan

Today, we are launching the Cloudflare for Teams Free plan, which brings the features of enterprise Zero Trust products and Secure Web Gateways to small teams as well.

Cloudflare for Teams Free offers robust Zero Trust security features for both internal and SaaS applications, and supports integration with a myriad of social and enterprise identity providers like AzureAD or Github. Our Free plan also includes DNS content and security filtering for multiple network locations, complete with 24 hour log retention. By offering Cloudflare for Teams Free, our goal is to empower you to take your first step on a journey to Zero Trust with us.

Zero Trust For Everyone

What You Can Do with Teams Free

With up to 50 seats of Access and Gateway, we’ve seen that the possibilities are endless. In fact, here are some of our favorite ways users are already getting the most out of Cloudflare for Teams Free today.

  • Collaborate on your startup. Build your product without worrying about security. Use Access to protect your development environment.
  • Secure your home Wi-Fi network. Point your home Wi-Fi router’s traffic to Gateway, and set up simple filtering rules to block malware and phishing attacks.
  • Protect the backend of your personal website. Lock down your WordPress admin panel pages, and invite collaborators to work on your blog by using Access’ one-time-pin feature.
  • Safeguard a guest Wi-Fi network. Shield a retail location with Gateway by enforcing your Acceptable Use Policy on your network.

Standalone and Standard

In addition to our new Cloudflare for Teams Free plan, we’re also making it easier to continue your Zero Trust journey by offering enhanced features in our standalone Cloudflare Access or Cloudflare Gateway plans.

With standalone Access, you can easily scale up or down with as many users as you need at any time for $3 per user.

Similarly, with Gateway standalone, you can safely and securely deploy DNS or HTTP security controls from 1 up to 20 different locations for $5 per user without compromising on reliability or performance.

Last but not least, we’re excited to finally give users a way to bundle with Teams Standard, which brings together everything from Access and Gateway under one simple plan at $7 per user.

Getting Started

To get started, just navigate to our sign-up page and create an account. If you already have an active account, you can head straight to the Cloudflare for Teams dashboard, where you’ll be dropped directly into our self-guided onboarding flow. From here, you’re just three steps away from deploying Access or Gateway but, in our opinion, you can’t go wrong kicking off with either.

What is Cloudflare One?

Post Syndicated from Rustam Lalkaka original https://blog.cloudflare.com/cloudflare-one/

What is Cloudflare One?

Running a secure enterprise network is really difficult. Employees spread all over the world work from home. Applications are run from data centers, hosted in public cloud, and delivered as services. Persistent and motivated attackers exploit any vulnerability.

Enterprises used to build networks that resembled a castle-and-moat. The walls and moat kept attackers out and data in. Team members entered over a drawbridge and tended to stay inside the walls. Trust folks on the inside of the castle to do the right thing, and deploy whatever you need in the relative tranquility of your secure network perimeter.

The Internet, SaaS, and “the cloud” threw a wrench in that plan. Today, more of the workloads in a modern enterprise run outside the castle than inside. So why are enterprises still spending money building more complicated and more ineffective moats?

Today, we’re excited to share Cloudflare One™, our vision to tackle the intractable job of corporate security and networking.

What is Cloudflare One?

Cloudflare One combines networking products that enable employees to do their best work, no matter where they are, with consistent security controls deployed globally.

Starting today, you can begin replacing traffic backhauls to security appliances with Cloudflare WARP and Gateway to filter outbound Internet traffic. For your office networks, we plan to bring next-generation firewall capabilities to Magic Transit with Magic Firewall to let you get rid of your top-of-shelf firewall appliances.

With multiple on-ramps to the Internet through Cloudflare, and the elimination of backhauled traffic, we plan to make it simple and cost-effective to manage that routing compared to MPLS and SD-WAN models. Cloudflare Magic WAN will provide a control plane for how your traffic routes through our network.

You can use Cloudflare One today to replace the other function of your VPN: putting users on a private network for access control. Cloudflare Access delivers Zero Trust controls that can replace private network security models. Later this week, we’ll announce how you can extend Access to any application – including SaaS applications. We’ll also preview our browser isolation technology to keep the endpoints that connect to those applications safe from malware.

Finally, the products in Cloudflare One focus on giving your team the logs and tools to both understand and then remediate issues. As part of our Gateway filtering launch this week we’re including logs that provide visibility into the traffic leaving your organization. We’ll be sharing how those logs get smarter later this week with a new Intrusion Detection System that detects and stops intrusion attempts.

What is Cloudflare One?

Many of those components are available today, some new features are arriving this week, and other pieces will be launching soon. All together, we’re excited to share this vision and for the future of the corporate network.

Problems in enterprise networking and security

The demands placed on a corporate network have changed dramatically. IT has gone from a back-office function to mission critical. In parallel with networks becoming more integral, users spread out from offices to work from home. Applications left the datacenter and are now being run out of multiple clouds or are being delivered by vendors directly over the Internet.

Direct network paths became hairpin turns

Employees sitting inside of an office could connect over a private network to applications running in a datacenter nearby. When team members left the office, they could use a VPN to sneak back onto the network from outside the walls. Branch offices hopped on that same network over expensive MPLS links.

When applications left the data center and users left their offices, organizations responded by trying to force that scattered world into the same castle-and-moat model. Companies purchased more VPN licenses and replaced MPLS links with difficult SD-WAN deployments. Networks became more complex in an attempt to mimic an older model of networking when in reality the Internet had become the new corporate network.

Defense-in-depth splintered

Attackers looking to compromise corporate networks have a multitude of tools at their disposal, and may execute surgical malware strikes, throw a volumetric kitchen sink at your network, or any number of things in between. Traditionally, defense against each class of attack was provided by a separate, specialized piece of hardware running in a datacenter.

Security controls used to be relatively easy when every user and every application sat in the same place. When employees left offices and workloads left data centers, the same security controls struggled to follow. Companies deployed a patchwork of point solutions, attempting to rebuild their topside firewall appliances across hybrid and dynamic environments.

High-visibility required high-effort

The move to a patchwork model sacrificed more than just defense-in-depth — companies lost visibility into what was happening in their networks and applications. We hear from customers that this capture and standardization of logs has become one of their biggest hurdles. They purchased expensive data ingestion, analysis, storage, and analytics tools.

Enterprises now rely on multiple point solutions that one of the biggest hurdles is the capture and standardization of logs. Increasing regulatory and compliance pressures place more emphasis on data retention and analysis. Splintered security solutions become a data management nightmare.

Fixing issues relied on best guesses

Without visibility into this new networking model, security teams had to guess at what could go wrong. Organizations who wanted to adopt an “assume breach” model struggled to determine what kind of breach could even occur, so they threw every possible solution at the problem.

We talk to enterprises who purchase new scanning and filtering services, delivered in virtual appliances, for problems they are unsure they have. These teams attempt to remediate every possible event manually, because they lack visibility, rather than targeting specific events and adapting the security model.

How does Cloudflare One fit?

Over the last several years, we’ve been assembling the components of Cloudflare One. We launched individual products to target some of these problems one-at-a-time. We’re excited to share our vision for how they all fit together in Cloudflare One.

Flexible data planes

Cloudflare launched as a reverse proxy. Customers put their Internet-facing properties on our network and their audience connected to those specific destinations through our network. Cloudflare One represents years of launches that allow our network to process any type of traffic flowing in either the “reverse” or “forward” direction.

In 2019, we launched Cloudflare WARP — a mobile application that kept Internet-bound traffic private with an encrypted connection to our network while also making it faster and more reliable. We’re now packaging that same technology into an enterprise version launching this week to connect roaming employees to Cloudflare Gateway.

Your data centers and offices should have the same advantage. We launched Magic Transit last year to secure your networks from IP-layer attacks. Our initial focus with Magic Transit has been delivering best-in-class DDoS mitigation to on-prem networks. DDoS attacks are a persistent thorn in network operators’ sides, and Magic Transit effectively diffuses their sting without forcing performance compromises. That rock-solid DDoS mitigation is the perfect platform on which to build higher level security functions that apply to the same traffic already flowing across our network.

Earlier this year, we expanded that model when we launched Cloudflare Network Interconnect (CNI) to allow our customers to interconnect branch offices and data centers directly with Cloudflare. As part of Cloudflare One, we’ll apply outbound filtering to that same connection.

Cloudflare One should not just help your team move to the Internet as a corporate network, it should be faster than the Internet. Our network is carrier-agnostic, exceptionally well-connected and peered, and delivers the same set of services globally. In each of these on-ramps, we’re adding smarter routing based on our Argo Smart Routing technology, which has been shown to reduce latency by 30% or more in the real-world. Security + Performance, because they’re better together.

A single, unified control plane

When users connect to the Internet from branch offices and devices, they skip the firewall appliances that used to live in headquarters altogether. To keep pace, enterprises need a way to secure traffic that no longer lives entirely within their own network. Cloudflare One applies standard security controls to all traffic – regardless of how that connection starts or where in the network stack it lives.

Cloudflare Access starts by introducing identity into Cloudflare’s network. Teams apply filters based on identity and context to both inbound and outbound connections. Every login, request, and response proxies through Cloudflare’s network regardless of the location of the server or user. The scale of our network and its distribution can filter and log enterprise traffic without compromising performance.

Cloudflare Gateway keeps connections to the rest of the Internet safe. Gateway inspects traffic leaving devices and networks for threats and data loss events that hide inside of connections at the application layer. Launching soon, Gateway will bring that same level of control lower in the stack to the transport layer.

You should have the same level of control over how your networks send traffic. We’re excited to announce Magic Firewall, a next-generation firewall for all traffic leaving your offices and data centers. With Gateway and Magic Firewall, you can build a rule once and run it everywhere, or tailor rules to specific use cases in a single control plane.

We know some attacks can’t be filtered because they launch before filters can be built to stop them. Cloudflare Browser, our isolated browser technology gives your team a bulletproof pane of glass from threats that can evade known filters. Later this week, we’ll invite customers to sign up to join the beta to browse the Internet on Cloudflare’s edge without the risk of code leaping out of the browser to infect an endpoint.

Finally, the PKI infrastructure that secures your network should be modern and simpler to manage. We heard from customers who described certificate management as one of the core problems of moving to a better model of security. Cloudflare works with, not against, modern encryption standards like TLS 1.3. Cloudflare made it easy to add encryption to your sites on the Internet with one click. We’re going to bring that ease-of-management to the network functions you run on Cloudflare One.

One place to get your logs, one location for all of your security analysis

Cloudflare’s network serves 18 million HTTP requests per second on average. We’ve built logging pipelines that make it possible for some of the largest Internet properties in the world to capture and analyze their logs at scale. Cloudflare One builds on that same capability.

Cloudflare Access and Gateway capture every request, inbound or outbound, without any server-side code changes or advanced client-side configuration. Your team can export those logs to the SIEM provider of your choice with our Cloudflare Logpush service – the same pipeline that exports HTTP request events at scale for public sites. Magic Transit expands that logging capability to entire networks and offices to ensure you never lose visibility from any location.

We’re going beyond just logging events. Available today for your websites, Cloudflare Web Analytics converts logs into insights. We plan to keep expanding that visibility into how your network operates, as well. Just as Cloudflare has replaced the “band-aid boxes” that performed disparate network functions and unified them into a cohesive, adaptable edge, we intend to do the same for the fragmented, hard to use, and expensive security analytics ecosystem. More to come on this soon.Smarter, faster remediation

Data and analytics should surface events that a team can remediate. Log systems that lead to one-click fixes can be powerful tools, but we want to make that remediation automatic.

Launching into a closed preview later this week, Cloudflare Intrusion Detection System (IDS) will proactively scan your network for anomalous events and recommend actions or, better yet, take actions for you to remediate problems. We plan to bring that same proactive scanning and remediation approach to Cloudflare Access and Cloudflare Gateway.

Run your network on our globally scaled network

Over 25 million Internet properties rely on Cloudflare’s network to reach their audiences. More than 10% of all websites connect through our reverse proxy, including 16% of the Fortune 1000. Cloudflare accelerates traffic for huge chunks of the Internet by delivering services from datacenters around the world.

We deliver Cloudflare One from those same data centers. And critically, every datacenter we operate delivers the same set of services, whether that is Cloudflare Access, WARP, Magic Transit, or our WAF. As an example, when your employees connect through Cloudflare WARP to one of our data centers, there is a real chance they never have to leave our network or that data center to reach the site or data they need. As a result, their entire Internet experience becomes extraordinarily fast, no matter where they are in the world.

We expect that performance bonus to become even more meaningful as browsing moves to Cloudflare’s edge with Cloudflare Browser. The isolated browsers running in Cloudflare’s data centers can request content that sits just centimeters away. Even further, as more web properties rely on Cloudflare Workers to power their applications, entire workflows can stay inside of a data center within 100 ms of your employees.

What’s next?

While many of these features are available today, we’re going to be launching several new features over the next several days as part of Cloudflare’s Zero Trust week. Stay tuned for announcements each day this week that add new pieces to the Cloudflare One featureset.

What is Cloudflare One?

Export logs from Cloudflare Gateway with Logpush

Post Syndicated from Sam Rhea original https://blog.cloudflare.com/export-logs-from-cloudflare-gateway-with-logpush/

Export logs from Cloudflare Gateway with Logpush

Like many people, I have spent a lot more time at home in the last several weeks. I use the free version of Cloudflare Gateway, part of Cloudflare for Teams, to secure the Internet-connected devices on my WiFi network. In the last week, Gateway has processed about 114,000 DNS queries from those devices and blocked nearly 100 as potential security risks.

I can search those requests in the Cloudflare for Teams UI. The logs capture the hostname requested, the time of the request, and Gateway’s decision to allow or block. This works fine for one-off investigations into a block, but does not help if I want to analyze the data more thoroughly. The last thing I want to do is click through hundreds or thousands of pages.

That problem is even more difficult for organizations attempting to keep hundreds or thousands of users and their devices secure. Whether they secure roaming devices with DoH or a static IP address, or keep users safe as they return to offices, deployments at that scale need a better option for auditing tens or hundreds of millions of queries each week.

Starting today, you can configure the automatic export of logs from Cloudflare Gateway to third-party storage destinations or security information and event management (SIEM) tools. Once exported, your team can analyze and audit the data as needed. The feature builds on the same robust Cloudflare Logpush Service that powers data export from Cloudflare’s infrastructure products.

Cloudflare Gateway

Cloudflare Gateway is one-half of Cloudflare for Teams, Cloudflare’s platform for securing users, devices, and data. With Cloudflare for Teams, our global network becomes your team’s network, replacing on-premise appliances and security subscriptions with a single solution delivered closer to your users – wherever they work.

Export logs from Cloudflare Gateway with Logpush

As part of that platform, Cloudflare Gateway blocks threats on the public Internet from becoming incidents inside your organization. Gateway’s first release added DNS security filtering and content blocking to the world’s fastest DNS resolver, Cloudflare’s 1.1.1.1.

Deployment takes less than 5 minutes. Teams can secure entire office networks and segment traffic reports by location. For distributed organizations, Gateway can be deployed via MDM on networks that support IPv6 or using a dedicated IPv4 as part of a Cloudflare Enterprise account.

With secure DNS filtering, administrators can click a single button to block known threats, like sources of malware or phishing sites. Policies can be extended to block specific categories, like gambling sites or social media. When users request a filtered site, Gateway stops the DNS query from resolving and prevents the device from connecting to a malicious destination or hostname with blocked material.

Cloudflare Logpush

The average user makes about 5,000 DNS queries each day. For an organization with 1,000 employees, that produces 5M rows of data daily. That data includes regular Internet traffic, but also potential trends like targeted phishing campaigns or the use of cloud storage tools that are not approved by your IT organization.

The Cloudflare for Teams UI presents some summary views of that data, but each organization has different needs for audit, retention, or analysis. The best way to let you investigate the data in any way you need is to give you all of it. However the volume of data and how often you might need to review it means that API calls or CSV downloads are not suitable. A real logging pipeline is required.

Cloudflare Logpush solves that challenge. Cloudflare’s Logpush Service exports the data captured by Cloudflare’s network to storage destinations that you control. Rather than requiring your team to build a system to call Cloudflare APIs and pull data, Logpush routinely exports data with fields that you configure.

Cloudflare’s data team built the Logpush pipeline to make it easy to integrate with popular storage providers. Logpush supports AWS S3, Google Cloud Storage, Sumo Logic, and Microsoft Azure out of the box. Administrators can choose a storage provider, validate they own the destination, and configure exports of logs that will send deltas every five minutes from that point onward.

How it works

When enabled, you can navigate to a new section of the Logs component in the Cloudflare for Teams UI, titled “Logpush”. Once there, you’ll be able to choose which fields you want to export from Cloudflare Gateway and the storage destination.

Export logs from Cloudflare Gateway with Logpush

The Logpush wizard will walk you through validating that you own the destination and configuring how you want folders to be structured. When saved, Logpush will send updated logs every five minutes to that destination. You can configure multiple destinations and monitor for any issues by returning to this section of the Cloudflare for Teams UI.

Export logs from Cloudflare Gateway with Logpush

What’s next?

Cloudflare’s Logpush Service is only available to customers on a contract plan. If you are interested in upgrading, please let us know. All Cloudflare for Teams plans include 30-days of data that can be searched in the UI.

Cloudflare Access, the other half of Cloudflare for Teams, also supports granular log export. You can configure Logpush for Access in the Cloudflare dashboard that houses Infrastructure features like the WAF and CDN. We plan to migrate that configuration to this UI in the near future.

Resolve internal hostnames with Cloudflare for Teams

Post Syndicated from Sam Rhea original https://blog.cloudflare.com/redirect-users-to-new-destinations-with-cloudflare-for-teams/

Resolve internal hostnames with Cloudflare for Teams

Phishing attacks begin like any other visit to a site on the Internet. A user opens a suspicious link from an email, and their DNS resolver looks up the hostname, then connects the user to the origin.

Cloudflare Gateway’s secure DNS blocks threats like this by checking every hostname query against a constantly-evolving list of known threats on the Internet. Instead of sending the user to the malicious host, Gateway stops the site from resolving.. The user sees a “blocked domain” page instead of the malicious site itself.

As teams migrate to SaaS applications and zero-trust solutions, they rely more on the public Internet to do their jobs. Gateway’s security works like a bouncer, keeping users safe as they navigate the Internet. However, some organizations still need to send traffic to internal destinations for testing or as a way to make the migration more seamless.

Starting today, you can use Cloudflare Gateway to direct end user traffic to a different IP than the one they originally requested. Administrators can build rules to override the address that would be returned by a resolver and send traffic to a specified alternative.

Like the security features of Cloudflare Gateway, the redirect function is available in every one of Cloudflare’s data centers in 200 cities around the world, so you can block bad traffic and steer internal traffic without compromising performance.

What is Cloudflare Gateway?

Cloudflare Gateway is one-half of Cloudflare for Teams, Cloudflare’s platform for securing users, devices, and data. With Cloudflare for Teams, our global network becomes your team’s network, replacing on-premise appliances and security subscriptions with a single solution delivered closer to your users – wherever they work.

Resolve internal hostnames with Cloudflare for Teams

As part of that platform, Cloudflare Gateway blocks threats on the public Internet from becoming incidents inside of your organization. Gateway’s first release added  DNS security filtering and content blocking to the world’s fastest DNS resolver, Cloudflare’s 1.1.1.1.

Deployment takes less than 5 minutes. Teams can secure entire office networks and segment traffic reports by location. For distributed organizations, Gateway can be deployed via MDM on networks that support IPv6 or using a dedicated IPv4 as part of a Cloudflare enterprise account.

With secure DNS filtering, administrators can click a single button to block known threats, like sources of malware or phishing sites. Policies can be extended to block specific categories, like gambling sites or social media. When users request a filtered site, Gateway stops the DNS query from resolving and prevents the device from connecting to a malicious destination or hostname with blocked material.

Traffic bound for internal destinations

As users connect to SaaS applications, Cloudflare Gateway can keep those teams secure from threats on the public Internet.

In parallel, teams can move applications that previously lived on a private network to a zero-trust model with Cloudflare Access. Rather than trusting anyone on a private network, Access checks for identity any time someone attempts to reach the application.

Together, Cloudflare for Teams keeps users safe and makes internal applications just as easy to use as SaaS tools. Making it easier to migrate to that model also reduces user friction. Domain overrides can smooth that transition from internal networks to a fully cloud-delivered model.

With Gateway’s domain override feature, administrators can choose certain hostnames that still run on the private network and send traffic to the local IPs with the same resolver that secures Internet-bound traffic. End users can continue to connect to those resources without disruption. Once ready, those tools can be secured with Cloudflare Access to remove the reliance on a private network altogether.

Resolve internal hostnames with Cloudflare for Teams

Cloudflare Gateway can help reduce user confusion and IT overhead with split-horizon setups where some traffic routes to the Internet and other requests need to stay on the same network. Administrators can build policies to route traffic bound for hostnames, even ones that exist publicly, to internal IP addresses that a user can reach if they are on the same local network.

How does it work?

When administrators configure an override policy, Cloudflare Gateway pushes that information to the edge of our network. The rule becomes part of the Gateway enforcement flow for that organization’s account. Explicit override policies are enforced first, before allowed or blocked rules.

When a user makes a request to the original destination, that request arrives at a Gateway IP address where Cloudflare’s network checks the source IP to determine which policies to enforce. Gateway determines that the request has an override rule and returns the preconfigured IP address.

Gateway’s DNS override feature is supported in deployments that use Cloudflare’s IPv4 or IPv6 addresses, as well as DNS over HTTPS.

What’s next?

The domain override feature is available to all Cloudflare for Teams customers today at no additional cost. You can begin building override rules by navigating to the Policies section of the Gateway product and selecting the “Custom” tab. Administrators can configure up to 1,000 custom rules.

To help organizations in their transition to remote work, Cloudflare has made our Teams platform free for any organization through September 1. You can set up an account at dash.teams.cloudflare.com now.

Need help getting started? You can request a dedicated onboarding session at no charge.

Setting up Cloudflare for Teams as a Start-Up Business

Post Syndicated from David Harnett original https://blog.cloudflare.com/setting-up-cloudflare-for-teams-as-a-start-up-business/

Setting up Cloudflare for Teams as a Start-Up Business

Earlier this year, Cloudflare acquired S2 Systems. We were a start-up in Kirkland, Washington and now we are home to Cloudflare’s Seattle-area office.

Our team developed a new approach to remote browser isolation (RBI), a technology that runs your web browser in a cloud data center, stopping threats on the Internet from executing any code on your machine. The closer we can bring that data center to the user, the faster we can make that experience. Since the acquisition, we have been focused on running our RBI platform in every one of Cloudflare’s data centers in 200 cities around the world.

The RBI solution will join a product suite that we call Cloudflare for Teams, which consists of two products: Access and Gateway.

Those two products solve a number of problems that companies have with securing users, devices, and data. As a start-up, we struggled with a few of these challenges in really painful ways:

  • How do we let prospects securely trial our RBI platform?
  • How do we keep our small office secure without an IT staff?
  • How can we connect to the powerful, but physically clunky and heavy development machines, when we are not in that office?

Dogfooding our own products has long been part of Cloudflare’s identity, and our team has had a chance to do the same from a new perspective.

Managing access to our RBI service for early adopter customers and partners

As we built the first version of our product, we worked closely with early adopters to test the product and gather feedback. However, we were not ready to share the product with the entire world yet, so we needed a way to lock down who could reach the prototype and beta versions.

It took us the best part of six months to build, test and modify (multiple times) the system for managing access to the product.

We chose a complicated solution that took almost as much time to build as did features within the product. We deployed a load balancer that also served as a reverse proxy in front of the RBI host and acted as a bouncer for unauthenticated requests. That sat behind an ASP.NET core server. Furthest to the right sat the most difficult component: identity.

Setting up Cloudflare for Teams as a Start-Up Business

We had to manually add identity providers every time a new customer wanted to test out the service. Our CTO frequently burned hours each day adding customers manually, configuring groups, and trying to balance policies that kept different tenants secure.

From six months to 30 minutes

As we learned more about Cloudflare during the due diligence period, we started to hear more about Cloudflare Access. Like the RBI solution, Access applied Cloudflare’s network to a new type of problem: how do teams keep their users and resources secure without also slowing them down?

When members of the Cloudflare team visited our office in Kirkland, none of them needed a VPN to connect. Their self-managed applications just worked, like any other SaaS app.

We then had a chance to try Access ourselves. After the deal closed, we collaborated with the Cloudflare team on an announcement. This started just hours after the acquisition completed, so we did not have a chance to onboard to Cloudflare’s corporate SSO yet. Instead, the team secured new marketing pages and forms behind Cloudflare Access which prompted us to login with our S2 emails. Again, it just worked.

We immediately began rethinking every hour we had spent building our own authentication platform. The next day, we set up a Cloudflare Access account. We secured our trial platform by building a couple of rules in the Access UI to decide who should be able to reach it.

We sent a note out to the team to try it out. They logged in with our SSO credentials and Cloudflare connected them to the application. No client needed on their side, no multi-level authentication platform on ours.

We shut down all of our demo authentication servers. Now, when we have customers who want to trial the RBI technology, we can add their account to the rules in a couple of minutes. They visit a single hostname, login, and can start connecting to a faster, safer browser.

Protecting our people and devices from Internet threats

When we signed a sublease for our first office location, we found the business card of the building’s Comcast representative taped to the door. We called them and after a week the Comcast Business technicians had a simple network running for us.

We wanted to implement a real network security model for our small office. We tried deploying multiple firewalls, with access controls, and added some tools to secure outbound traffic.

We spent way too much time on it. Every configuration change involved the staff trying to troubleshoot problems. The system wound up blocking things that should not be blocked, and missing things that should be blocked. It reached the point where we just turned off most of it.

Another product in the Cloudflare for Teams platform, Cloudflare Gateway, solved this challenge for us. Rather than 30 minutes, this upgrade took about 10.

Cloudflare Gateway secures users from threats on the Internet by stopping traffic from devices or office networks from reaching malicious destinations. The first feature in the product, DNS-based security, adds threat-blocking into the world’s fastest DNS resolver, Cloudflare’s 1.1.1.1 product.

Setting up Cloudflare for Teams as a Start-Up Business

We created a policy to block security threats, changed our router’s DNS settings, and never had to worry about it again. As needed, we could log back into the UI and review reports that told us about the malicious traffic that Gateway caught.

As I’m writing this post, none of us are working in that office. We’re staying home, but we still can use Gateway’s security model. Gateway now integrates with the 1.1.1.1 app for mobile devices; in a couple of clicks, we can protect iOS and Android phones and tablets with the same level of security. Soon, we’ll be releasing desktop versions to make that easy on every device.

Connecting to dev machines while working from home

Back at the office, we still have a small fleet of high-powered Linux machines. These desktops run 16 cores, 32 threads, and 32GB of DDR memory. We use these to build and test Chromium, but dragging these boxes to each developer’s house would have been a huge hassle.

We still had a physical VPN appliance that we had purchased during our start-up days. We had hired vendors to install it onsite and configure some elaborate syncing with our identity providers. The only thing more difficult than setting it up was using it. With everyone suddenly working from home, I don’t think we would have been able to make it work.

So we returned to Cloudflare Access instead. Working with guidance from Cloudflare’s IT and Security teams, we added a new hostname in the Cloudflare account for the Seattle area office. We then installed the Cloudflare daemon, cloudflared, on the machines in the offices. Those daemons created outbound-only tunnels from the machines to the Cloudflare network, available at a dedicated subdomain for each developer.

On the other side of that connection, each engineer on our team installed cloudflared on their machines at home. They need to make one change to their SSH config file, adding two lines that include a ProxyCommand. The setup requires no other modifications, no special SSH clients or commands. Even the developers who rely on tools like Visual Studio Code’s Remote SSH extension could keep their workflow exactly the same.

The only difference is that, instead of a VPN, when developers start a new SSH session, Access prompts them to login with Cloudflare’s SSO. They do so and are connected to their machine through Cloudflare’s network and smart routing technology.

What’s next?

As a start-up, every hour we spent trying to cobble together tools was an hour we lost building our product but we needed to provide secure access to our product so we made the time investment. The only other option would have been to purchase products that were way outside of the price range for a small start-up where the only office perk was bulk Costco trail mix.

Cloudflare for Teams immediately solved the challenges we had, in a fairly comprehensive way. We now can seamlessly grant prospects permissions to try the product, our office network is safer, and our developers can stay productive at home.

It could be easy to think “I wish we had done this sooner,” and to some extent, I do. However, seeing the before-and-after of our systems has made us more excited about what we’re doing as we bring the remote browser technology into Cloudflare’s network.

The RBI platform is going to benefit from the same advantages of that network that make features in Access and Gateway feel like magic. We’re going to apply everything that Cloudflare has learned securing and improving connections and use it to solve a new customer problem.

Interested in skipping the hard parts about our story and getting started with Cloudflare for Teams? You can use all of the features covered in this blog post today, at no cost through September.

A single dashboard for Cloudflare for Teams

Post Syndicated from Sam Rhea original https://blog.cloudflare.com/a-single-dashboard-for-cloudflare-for-teams/

A single dashboard for Cloudflare for Teams

Starting today, Cloudflare Access can now be used in the Cloudflare for Teams dashboard. You can manage security policies for your people and devices in the same place that you build zero-trust rules to protect your applications and resources. Everything is now in one place in a single dashboard.

We are excited to launch a new UI that can be used across the entire Teams platform, but we didn’t build this dashboard just for the sake of a new look-and-feel. While migrating the Access dashboard, we focused on solving one of the largest sources of user confusion in the product.

This post breaks down why the original  UI caused some headaches, how we think about objects in Cloudflare for Teams, and how we set out to fix the way we display that to our users.

Cloudflare Access

Cloudflare Access is one-half of Cloudflare for Teams, a security platform that runs on Cloudflare’s network. Teams protects users, devices and data  without compromising experience or performance. We built Cloudflare Access to solve our own headaches with private networks as we grew from a team concentrated in a single office to a globally distributed organization.

A single dashboard for Cloudflare for Teams

Cloudflare Access replaces corporate VPNs with Cloudflare’s network in a zero-trust model. Instead of placing internal tools on a private network, teams deploy them in any environment, including hybrid or multi-cloud models, and secure them consistently with Cloudflare’s network.

When users connect to those tools, they are prompted to login with their team’s identity provider. Cloudflare Access checks their login against the list of allowed users and, if permitted, allows the request to proceed.

Deploying Access does not require exposing new holes in corporate firewalls. Teams connect their resources through a secure outbound connection, Argo Tunnel, which runs in your infrastructure to connect the applications and machines to Cloudflare. That tunnel makes outbound-only calls to the Cloudflare network and organizations can replace complex firewall rules with just one: disable all inbound connections.

Sites vs. Accounts

When you use Cloudflare, you use the platform at two levels: account and site. You have one Cloudflare account, though you can be a member of multiple accounts. That one account captures details like your billing profile and notification settings.

Your account contains sites, the hostnames or zones that you add to Cloudflare. You configure features that apply to a site, like web application firewall (WAF) and caching rules.

When we launched Access nearly two years ago, you could use the product to add an identity check to a site you added to Cloudflare, either at the hostname, subdomain, or path. To do that, users select the site in their Cloudflare dashboard, toggle to the Access tab, and build a rule specific to that site.

A single dashboard for Cloudflare for Teams

To add rules to a different site, a user steps back up a level. They need to select the new site from the dropdown and load the Access tab for that site. However, two components in the UI remained the same and shared configuration:

  • SSO integration
  • Logs

The SSO integration is where Access pulls information about identity. Users integrate their Okta, AzureAD, GSuite accounts, or other identity providers, in this card. We made a decision that the integration should apply across your entire account; you should not need to reconfigure your SSO connection on every site where you want to add an Access rule.

However, we displayed that information in the site-specific page. Cloudflare has account-level concepts, like billing or account users, but we wanted to keep everything related to Access in a single page so we made this compromise. Logs followed a similar pattern.

This decision caused confusion. For example, we add a log table to the bottom of the tab when users view “site{.}com”. However, that table actually presented logs from both “site{.}com” and any other hostname in the account.

As more features were added, this exception grew out of control. At this point, the majority of features you see when you open the Access tab for one of your sites are account-level features stuffed into the site view. The page below is the Access tab for a site in my account, widgetcorp{.}tech. Highlighted in green are the boxes that apply to the site I have selected. Highlighted in red are the boxes that apply to my Access account.

A single dashboard for Cloudflare for Teams

This user experience is unnecessarily complex . Even worse, though, is that confusion in security products can lead to real incidents. Any time that a user asks “am I building something for my account or this site?” We needed to fix both.

Starting with a new design

A few months ago, Cloudflare launched Cloudflare for Teams, which consists of two complementary products: Access and a new solution, Cloudflare Gateway. If Access is a bouncer standing in front of the door, checking identity, Gateway is a bodyguard, keeping your team safe as you navigate the Internet.

Gateway has no concept of sites, at least not sites that you host yourself. Rather than securing your Internet properties, like Cloudflare’s infrastructure products that rely on the reverse proxy, Gateway secures your team from the Internet, and the threats on it. For the first time, you could use a Cloudflare product without a site on Cloudflare.

Gateway introduced other new concepts which have no relation to a domain name in the traditional Cloudflare sense. You can add your office network and your home WiFi to your Gateway account. You can build rules to block any sites on the Internet. You can now use Gateway on mobile devices and soon desktops as well.

To capture that model, we started on a new UI from scratch, and earlier this year we launched a new dashboard for Gateway, dash.teams.cloudflare.com.

A single dashboard for Cloudflare for Teams

Account settings now have a home of their own

The products in Cloudflare for Teams should live in one place; you shouldn’t need to hop back and forth between different dashboards to manage them. Bringing Access into the Teams dashboard puts everything under one roof.

That also gave us an opportunity to solve the confusion in the current Access UI. Since the Teams dashboard is not constrained by the site-specific model, we could break out the dashboard into components that made sense for how people use the Access product.

A single dashboard for Cloudflare for Teams

The new dashboard untangles the tools in Access that apply to your entire account (the methods that you use to secure your resources) from the features that apply to a single site (the rules you build to protect a resource).

One dashboard for your team

Merging Access into the Cloudflare for Teams dashboard, and solving the problems of the original UI, is just the beginning. We’ll be using that foundation to release new features in both Access and Gateway, including more that apply across both products.

You will also be able to continue to extend some of the configuration made in Access to Gateway. For example, an integration with a provider like Okta to build zero-trust policies in Access can eventually be reused for adding group-based policies into Gateway. You’ll see the beginning of that in the new UI, as well, with categories like “My Teams” and “Logs” that apply or will apply to both products. As we continue, we’re going to try to avoid making the same mistake of conflating account, site, and now product objects.

A single dashboard for Cloudflare for Teams

What’s next?

The new Access UI is available to all customers today in the Cloudflare for Teams dashboard. You can get started by visiting this link and signing in with your Cloudflare account.

To use the Access UI, you will first need to enable Cloudflare Access and add a site to Cloudflare in the existing dashboard. Instructions are available here. You can also watch a guided tour of the new site.

No new features have been added, though we’re busy working on them. This release focused entirely on improving how users approach the product based on the feedback we have received over 22 months. We’re still listening to new feedback. Run into an issue or notice an area of improvement? Please tell us.

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

Post Syndicated from Jason Farber original https://blog.cloudflare.com/deploying-gateway-using-a-raspberry-pi-dns-over-https-and-pi-hole/

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

Like many who are able, I am working remotely and in this post, I describe some of the ways to deploy Cloudflare Gateway directly from your home. Gateway’s DNS filtering protects networks from malware, phishing, ransomware and other security threats. It’s not only for corporate environments – it can be deployed on your browser or laptop to protect your computer or your home WiFi. Below you will learn how to deploy Gateway, including, but not limited to, DNS over HTTPS (DoH) using a Raspberry Pi, Pi-hole and DNSCrypt.

We recently launched Cloudflare Gateway and shortly thereafter, offered it for free until at least September to any company in need. Cloudflare leadership asked the global Solutions Engineering (SE) team, amongst others, to assist with the incoming onboarding calls. As an SE at Cloudflare, our role is to learn new products, such as Gateway, to educate, and to ensure the success of our prospects and customers. We talk to our customers daily, understand the challenges they face and consult on best practices. We were ready to help!

One way we stay on top of all the services that Cloudflare provides, is by using them ourselves. In this blog, I’ll talk about my experience setting up Cloudflare Gateway.

Gateway sits between your users, device or network and the public Internet. Once you setup Cloudflare Gateway, the service will inspect and manage all Internet-bound DNS queries. In simple terms, you point your recursive DNS to Cloudflare and we enforce policies you create, such as activating SafeSearch, an automated filter for adult and offensive content that’s built into popular search engines like Google, Bing, DuckDuckGo, Yandex and others.

There are various methods and locations DNS filtering can be enabled, whether it’s on your entire laptop, each of your individual browsers and devices or your entire home network. With DNS filtering front of mind, including DoH, I explored each model. The model you choose ultimately depends on your objective.

But first, let’s review what DNS and DNS over HTTPS are.

DNS is the protocol used to resolve hostnames (like www.cloudflare.com) into IP addresses so computers can talk to each other. DNS is an unencrypted clear text protocol, meaning that any eavesdropper or machine between the client and DNS server can see the contents of the DNS request. DNS over HTTPS adds security to DNS and encrypt DNS queries using HTTPS (the protocol we use to encrypt the web).

Let’s get started

Navigate to https://dash.teams.cloudflare.com. If you don’t already have an account, the sign up process only takes a few minutes.

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

Configuring a Gateway location, shown below, is the first step.

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

Conceptually similar to HTTPS traffic, when our edge receives an HTTPS request, we match the incoming SNI header to the correct domain’s configuration (or for plain text HTTP the Host header). And when our edge receives a DNS query, we need a similar mapping to identify the correct configuration. We attempt to match configurations, in this order:

  1. DNS over HTTPS check and lookup based on unique hostname
  2. IPv4 check and lookup based on source IPv4 address
  3. Lookup based on IPv6 destination address

Let’s discuss each option.

DNS over HTTPS

The first attempt to match DNS requests to a location is pointing your traffic to a unique DNS over HTTPS hostname. After you configure your first location, you are given a unique destination IPv6 address and a unique DoH endpoint as shown below. Take note of the hostname as you will need it shortly. I’ll first discuss deploying Gateway in a browser and then to your entire network.

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

DNS over HTTPS is my favorite method for deploying Gateway and securing DNS queries at the same time. Enabling DoH prevents anyone but the DNS server of your choosing from seeing your DNS queries.

Enabling DNS over HTTPS in browsers

By enabling it in a browser, only queries issued in that browser are affected. It’s available in most browsers and there are quite a few tutorials online to show you how to turn it on.

Browser Supports DoH Supports Custom Alternative Providers Supports Custom Servers
Chrome Yes Yes No
Safari No No No
Edge Yes** Yes** No**
Firefox Yes Yes Yes
Opera Yes* Yes* No*
Brave Yes* Yes* No*
Vivaldi Yes* Yes* No*

* Chromium based browser. Same support as Chrome
** Most recent version of Edge is built on Chromium

Chromium based browsers

Using Chrome as an example on behalf of all the Chromium-based browsers, enabling DNS over HTTPS is straightforward, but as you can see in the table above, there is one issue: Chrome does not currently support custom servers. So while it is great that a user can protect their DNS queries, they cannot choose the provider, including Gateway.

Here is how to enable DoH in Chromium based browsers:

Navigate to chrome://flags and toggle the beta flag to enabled.

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

Firefox

Firefox is the exception to the rule because they support both DNS over HTTPS and the ability to define a custom server. Mozilla provides detailed instructions about how to get started.

Once enabled, navigate to Preferences -> General -> Network Security and select ‘Settings’. Scroll to the section ‘Enable DNS over HTTPS’, select ‘Custom’ and input your Gateway DoH address, as shown below:

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

Optionally, you can enable Encrypted SNI (ESNI), which is an IETF draft for encrypting the SNI headers, by toggling the ‘network.security.esni.enabled’ preference in about:config to ‘true’. Read more about how Cloudflare is one of the few providers that supports ESNI by default.

Congratulations, you’ve configured Gateway using DNS over HTTPS! Keep in mind that only queries issued from the configured browser will be secured. Any other device connected to your network such as your mobile devices, gaming platforms, or smart TVs will still use your network’s default DNS server, likely assigned by your ISP.

Configuring Gateway for your entire home or business network

Deploying Gateway at the router level allows you to secure every device on your network without needing to configure each one individually.

Requirements include:

  • Access to your router’s administrative portal
  • A router that supports DHCP forwarding
  • Raspberry Pi with WiFi or Ethernet connectivity

There aren’t any consumer routers on the market that natively support DoH custom servers and likely few that natively support DoH at all. A newer router I purchased, the Netgear R7800, does not support either, but it is one of the most popular routers for flashing dd-wrt or open-wrt, which both support DoH. Unfortunately, neither of these popular firmwares support custom servers.

While it’s rare to find a router that supports DoH out of the box, DoH with custom servers, or has potential to be flashed, it’s common for a router to support DHCP forwarding (dd-wrt and open-wrt both support DHCP forwarding). So, I installed Pi-hole on my Raspberry Pi and used it as my home network’s DNS and DHCP server.

Getting started with Pi-hole and dnscrypt-proxy

If your Raspberry Pi is new and hasn’t been configured yet, follow their guide to get started. (Note: by default, ssh is disabled, so you will need a keyboard and/or mouse to access your box in your terminal.)

Once your Raspberry Pi has been initialized, assign it a static IP address in the same network as your router. I hardcoded my router’s LAN address to 192.168.1.2

Using vim:
sudo vi /etc/dhcpcd.conf

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

Restart the service.
sudo /etc/init.d/dhcpcd restart

Check that your static IP is configured correctly.
ip addr show dev eth0

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

Now that your Raspberry Pi is configured, we need to install Pi-hole: https://github.com/pi-hole/pi-hole/#one-step-automated-install

I chose to use dnscrypt-proxy as the local service that Pi-hole will use to forward all DNS queries. You can find the latest version here.

To install dnscrypt-proxy on your pi-hole, follow these steps:

wget https://github.com/DNSCrypt/dnscrypt-proxy/releases/download/2.0.39/dnscrypt-proxy-linux_arm-2.0.39.tar.gz
tar -xf dnscrypt-proxy-linux_arm-2.0.39.tar.gz
mv linux-arm dnscrypt-proxy
cd dnscrypt-proxy
cp example-dnscrypt-proxy.toml dnscrypt-proxy.toml

Next step is to build a DoH stamp. A stamp is simply an encoded DNS address that encodes your DoH server and other options.

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

As a reminder, you can find Gateway’s unique DoH address in your location configuration.

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

At the very bottom of your dnscrypt-proxy.toml configuration file, uncomment both lines beneath [static].

  • Change  [static.'myserver'] to [static.'gateway']
  • Replace the default stamp with the one generated above

The static section should look similar to this:

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

Also in dnscrypt-proxy.toml configuration file, update the following settings:
server_names = ['gateway']
listen_addresses = ['127.0.0.1:5054']
fallback_resolvers = ['1.1.1.1:53', '1.0.0.1:53']
cache = false

Now we need to install dnscrypt-proxy as a service and configure Pi-hole to point to the listen_addresses defined above.

Install dnscrypt-proxy as a service:
sudo ./dnscrypt-proxy -service install

Start the service:
sudo ./dnscrypt-proxy -service start

You can validate the status of the service by running:
sudo service dnscrypt-proxy status or netstat -an | grep 5054:

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole
Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

Also, confirm the upstream is working by querying localhost on port 5054:
dig www.cloudflare.com  -p 5054 @127.0.0.1

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

You will see a matching request in the Gateway query log (note the timestamps match):

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

Configuring DNS and DHCP in the Pi-hole administrative console

Open your browser and navigate to the Pi-hole’s administrative console. In my case, it’s http://192.168.1.6/admin

Go to Settings -> DNS to modify the upstream DNS provider, which we’ve just configured to be dnscrypt-proxy.

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

Change the upstream server to 127.0.0.1#5054 and hit save. If you want to deploy redundancy, add in a secondary address in Custom 2, such as 1.1.1.1 or Custom 3, such as your IPv6 destination address.

Almost done!

In Settings->DHCP, enable the DHCP server:

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

Hit save.

At this point, your Pi-hole server is running in isolation and we need to deploy it to your network. The simplest way to ensure your Pi-hole is being used exclusively by every device is to use your Pi-hole as both a DNS server and a DHCP server. I’ve found that routers behave oddly if you outsource DNS but not DHCP, so I outsource both.

After I enabled the DHCP server on the Pi-hole, I set the router’s configuration to DHCP forwarding and defined the Pi-hole static address:

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

After applying the routers configuration, I confirmed it was working properly by forgetting the network in my network settings and re-joining. This results in a new IPv4 address (from our new DHCP server) and if all goes well, a new DNS server (the IP of Pi-hole).

Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole
Deploying Gateway using a Raspberry Pi, DNS over HTTPS and Pi-hole

Done!

Now that our entire network is using Gateway, we can configure Gateway Policies to secure our DNS queries!

IPv4 check and lookup based on source IPv4 address

For this method to work properly, Gateway requires that your network has a static IPv4 address. If your IP address does not change, then this is the quickest solution (but still does not prevent third-parties from seeing what domains you are going to). However, if you are configuring Gateway in your home, like I am, and you don’t explicitly pay for this service, then most likely you have a dynamic IP address. These addresses will always change when your router restarts, intentionally or not.

Lookup based on IPv6 destination address

Another option for matching requests in Gateway is to configure your DNS server to point to a unique IPv6 address provided to you by Cloudflare. Any DNS query pointed to this address will be matched properly on our edge.

This might be a good option if you want to use Cloudflare Gateway on your entire laptop by setting your local DNS resolution to this address. However, if your home router or ISP does not support IPv6, DNS resolution won’t work.

Conclusion

In this blog post, we’ve discussed the various ways Gateway can be deployed and how DNS over HTTPS is one of the next big Internet privacy improvements. Deploying Gateway can be done on a per device basis, on your router or even with a Raspberry Pi.

How To Use 1.1.1.1 w/ WARP App And Cloudflare Gateway To Protect Your Phone From Security Threats

Post Syndicated from Irtefa original https://blog.cloudflare.com/how-to-use-1-1-1-1-w-warp-app-and-cloudflare-gateway-to-protect-your-phone-from-security-threats/

How To Use 1.1.1.1 w/ WARP App And Cloudflare Gateway To Protect Your Phone From Security Threats

Cloudflare Gateway protects users and devices from security threats. You can now use Gateway inside the 1.1.1.1 w/ WARP app to secure your phone from malware, phishing and other security threats.

The 1.1.1.1 w/ WARP app has secured millions of mobile Internet connections. When installed, 1.1.1.1 w/ WARP encrypts the traffic leaving your device, giving you a more private browsing experience.

Starting today, you can get even more out of your 1.1.1.1 w/ WARP. By adding Cloudflare Gateway’s secure DNS filtering to the app, you can add a layer of security and block malicious domains flagged as phishing, command and control, or spam. This protection isn’t dependent on what network you’re connected to – it follows you everywhere you go.

You can read more about how Cloudflare Gateway builds on our 1.1.1.1 resolver to secure Internet connections in our announcement. Ready to get started bringing that security to your mobile device? Follow the steps below.

Download the 1.1.1.1 w/ WARP mobile app

If you don’t have the latest version of the 1.1.1.1 w/ WARP app go to the Apple App Store or Google Play Store to download the latest version.

Sign up for Cloudflare Gateway

Sign up for Cloudflare Gateway by visiting the Cloudflare for Teams dashboard. You can use Cloudflare Gateway for free, all you need is a Cloudflare account to get started.

Get the unique ID for your DNS over HTTPS hostname

On your Cloudflare Gateway dashboard go to ‘Locations’.

How To Use 1.1.1.1 w/ WARP App And Cloudflare Gateway To Protect Your Phone From Security Threats

Click on the location listed on the locations page to expand the location item.

How To Use 1.1.1.1 w/ WARP App And Cloudflare Gateway To Protect Your Phone From Security Threats

Copy the unique 10 character subdomain from the DNS over HTTPS endpoint. This unique ID is case sensitive. Either note it down on a paper or keep this window open on your computer because you will need it when you setup Gateway inside your 1.1.1.1 w/ WARP app.

Enabling Cloudflare Gateway for 1.1.1.1 w/ WARP app

After you open the 1.1.1.1 w/ WARP app, click on the menu button on the top right corner:

How To Use 1.1.1.1 w/ WARP App And Cloudflare Gateway To Protect Your Phone From Security Threats

Click on ‘Advanced’ which is located under the ‘Account’ button.

How To Use 1.1.1.1 w/ WARP App And Cloudflare Gateway To Protect Your Phone From Security Threats

Click on ‘Connection options’ which is located at the bottom of the screen right above ‘Diagnostics’.

How To Use 1.1.1.1 w/ WARP App And Cloudflare Gateway To Protect Your Phone From Security Threats

Click on ‘DNS Settings’. This will take you to the screen where you can configure Gateway for your 1.1.1.1 mobile app.

How To Use 1.1.1.1 w/ WARP App And Cloudflare Gateway To Protect Your Phone From Security Threats

When you are on this screen on your phone, you will need to enter the unique subdomain of the location you created for your mobile phone. This is the unique ID I asked you to note down in the previous section.

How To Use 1.1.1.1 w/ WARP App And Cloudflare Gateway To Protect Your Phone From Security Threats

Enter the subdomain inside the field GATEWAY UNIQUE ID.

If 1.1.1.1 DNS, WARP or WARP+ was already enabled, the 1.1.1.1 w/ WARP app should be using Gateway now.

If you are using Android you can read about the setup instructions here.

If you are trying to enable Gateway for your corporate mobile devices using an MDM, you can read the setup instructions here.

Now that you have Gateway setup inside your 1.1.1.1 w/ WARP app, it will enforce security policies that are tied to the location and analytics will show up on your dashboard.

What’s next

We announced last week the 1.1.1.1 w/ WARP beta for Windows and macOS. If you are interested in using Cloudflare Gateway on macOS or Windows you can sign up for the beta here and we will reach out to you as soon as they are available.

Our team will continue to enhance Cloudflare Gateway. If you want to secure corporate devices, data centers or offices from security threats, get started today by visiting the Cloudflare for Teams dashboard.