Authentication on the web has been steadily moving to the application layer using services such as Cloudflare Access to establish and enforce software-controlled, zero trust perimeters. However, there are still several important use cases for restricting access at the network-level by source IP address, autonomous system number (ASN), or country. For example, some businesses are prohibited from doing business with customers in certain countries, while others maintain a blocklist of problematic IPs that have previously attacked them.
Enforcing these network restrictions at centralized chokepoints using appliances—hardware or virtualized—adds unacceptable latency and complexity, but doing so performantly for individual IPs at the Cloudflare edge is easy. Today we’re making it just as easy to manage tens of thousands of IPs across all of your zones by grouping them in data structures known as IP Lists. Lists can be stored with metadata at the Cloudflare edge, replicated within seconds to our data centers in 200+ cities, and used as part of our powerful, expressive Firewall Rules engine to take action on incoming requests.
Creating and using an IP List
Previously, these sort of network-based security controls have been configured using IP Access or Zone Lockdown rules. Both tools have a number of shortcomings that we’ve eliminated with the introduction of IP Lists, including:
IP prefix boundaries
Our legacy IP Access rules allow the use of a limited number of IP prefix lengths: /16 and /24 for IPv4; and /32, /48, and /64 for IPv6. These restrictions typically result in users creating far more rules than needed, e.g., if you want to block a /20 IPv4 network you must create 16 separate /24 entries.
With IP Lists we’ve removed this restriction entirely, allowing users to create Lists with any prefix length: /8 through /32 for IPv4 and /4 through /64 for IPv6. Lists can also contain individual IPv4 addresses. For IPv6, the lower 64 bits can often be changed by the end user, therefore IP Lists do not offer prefixes beyond /64.
Order of evaluation
Perhaps the most limiting factor in the use of IP Access rules today is that they are evaluated before Firewall Rules. You can elect to Block or Challenge the request based on a the source IP address, country or ASN, or you can allow the request to bypass all subsequent L7 mitigations: DDoS, Firewall Rules, Zone Lockdown, User Agent, Browser Integrity Check, Hotlink Protection, IP Reputation (including “Under Attack” Mode), Rate Limiting, and Managed Rules.
IP Lists introduce much more flexibility.
For example, with IP Lists, you can combine a check of a source IP address with a Bot Management score, contents of an HTTP request header, or any other filter criteria that the Firewall Rules engine supports to implement more complex logic.
Below is a rule that blocks requests to /login with a bot score below 30, unless it is coming from the probe servers of Pingdom, an external monitoring solution.
Shared use across zones
Zone Lockdown rules are defined exclusively at the zone level, and cannot be re-used across zones, so if you wanted to allow only a specific set of IPs to the same hundred zones you’d have to recreate the rules and IPs in each zone.
IP Lists are stored at the account level, not zone level, so the same list can be referenced—and updated—in Firewall Rules across multiple zones. We’re also hard at work on letting you create account-wide Firewall Rules, which will streamline your security configuration even further.
Organization, labeling, and bulk uploading
IP Access and Zone Lockdown rules must be created one at a time whereas IP Lists can be uploaded in bulk through the UI using a CSV file (or pasting multiple lines, as shown below), or via the API. Individual items are timestamped, and can be given descriptions along with the group itself.
In the clip below, the contents of Pingdom's IPv4 list are copied to the clipboard and then pasted into the Lists UI. Multiple rows will automatically be created as shown:
Actions available for use in rules
Because IP Lists are used within Firewall Rules, users can take advantage of all the actions available today, as well as those that we add in the future. In the coming months we plan to migrate all of the capabilities under Firewall → Tools into Firewall Rules, including Rate Limiting, which will require the addition of the Custom Response action. This action, which allows users to specify the specific status code, content type, and payload that gets to the eyeball, will then be usable with IP Lists.
Planned Enhancements
We wanted to get IP Lists in your hands as soon as possible, but we’re still working on adding additional capabilities. If you have thoughts on our ideas below, or have other suggestions, please comment at the end of this blog post—we’d love to hear what would make Lists more useful to you!
Multiple Lists and increased quotas for paid plans
As of today (7/22/20) every account can create one (1) IP List with a total of 1,000 entries. In the near future we plan to increase both the number of Lists that can be created as well as the total count of entries.
NOTE: Limits have since been increased. Please refer to the Rules Lists developer documentation for the latest details.
Additional types of custom Lists
Lists are assigned a type during creation and the first type available is the IP List. We plan to add Country and ASN Lists, and are monitoring feedback to see what other types may be useful.
Expiring List entries
We’ve heard a few requests from beta testers who are interested in expiring individual List entries after some specified period of time, e.g., 24 hours from addition to the List. If this is something of interest to you, please let us know along with your use cases.
Managed Lists
In addition to Lists that you create and manage yourself, we plan to curate Lists that you can subscribe to and use in your rules. Our initial ideas revolve around surfacing intelligence gleaned from the 27M properties reverse proxying traffic through the Cloudflare edge, e.g., equipping you with lists of IPs that are known open proxies so requests from these can be treated differently.
In addition to intelligent lists, we’re planning on creating other managed lists for your convenience—but need your help in identifying which those are. Are there lists of IPs you find yourself manually inputting? We’d like to hear about those as candidates for Cloudflare Managed lists. Some examples from beta testers include third-party performance monitoring tools that should never have security enforcements applied to them.
Are you paying for a third-party List today that you’d like to subscribe to and have automatically updated within Cloudflare? Let us know in the comments below.
Get started today and let us know what you think
IP Lists are now available in all Cloudflare accounts. We’re excited to let you start using them, and look forward to your feedback.