Blocklist: why does the computer say no?

I am sure that many of you are familiar with the catchphrase “The computer says no”, which originates from the stellar British sketch-comedy show “Little Britain”. This phrase has become widely used to criticise organisations that rely on information stored on or generated by a computer to make arbitrary decisions regarding customers’ requests, sometimes in a manner which does not make sense. Today, I am going to write about block lists – the primary technology behind a vast number of computer-based rejections worldwide that deny billions of interactions every day.

Info
The term blacklist originates from the 17th century, when it began to refer to lists of undesirable individuals, enemies, dissenters, or people marked for punishment or exclusion. The opposite of a blacklist is a whitelist, which lists trusted individuals or entities. In the 21st century, these terms are becoming deprecated and replaced with blocklists and allowlists, which I will also use below.

In cybersecurity, block lists are everywhere

In cybersecurity, blocklists are ubiquitous. Think of any essential internet technology that needs protection from threats, and you can be certain that there are solutions out there that implement blocklist-based protection for them, for example:

a) TCP/IP networking (firewalls, IDS/IPS, DDoS controls)
b) Domain Name System (RPZ, DNSBLs, sinkholes)
c) The World Wide Web (WAFs, URL filtering, bot management)
d) E-mail (spam filters, sender reputation)
e) Identity & authentication (breached or weak password blocklists).

A blocklist requires a maintaining authority, such as an author or compiler. This is the person or entity that adds new items to the blocklist and manages the list’s integrity. For a home network or a homelab, this might be an individual, but it could also be a community, governmental organisation or a business. Entries on a blocklist typically serve as indicators of malicious activity, encompassing various elements such as IP addresses, domains, URLs, file hashes, and account IDs, among others.

Blocklist protects

The motivations for compiling a blocklist can vary. Still, in most cases, they aim to protect valuable assets or services from known malicious actors by reducing exposure to known malicious infrastructure or behaviours. While many are compiled and used in a narrow context, such as a single organisation or a business, others are aggregated from community submissions, honeypots, telemetry, and partner feeds from thousands of sources. These can be widely distributed and used by millions.

The latter are usually maintained by either a business or a community, as these types of lists require a significant amount of maintenance effort. There a lot if factors that need to be considered to run an effective list:

a) data provenance and list authenticity management
b) criteria for item inclusion and exclusion
c) time-to-live of items and their expiry process
d) distribution of the list and cadence of list updates
e) quality and observability metrics
f) user support.

The latter is essential, because false positives can be costly, responsible maintainers publish clear criteria, provide appeal/removal processes, support local allowlist overrides, and prefer time-bounded entries with decay.

Some well-known blocklists

Business models and licensing

While many blocklists are free to use and funded by donations, sponsorships, grants, or employer time, some have a business model. Some lists offer a freemium version where public/lagged or summary feeds are free, but real-time, higher-fidelity or historic data requires payment.

Blocklists that are offered as a service have fees by organisation/throughput/number of sensors, higher tiers add SLA, support, integration help or private feeds. Maintainers also license their feeds to security vendors who in turn embed the feed into their services or products, such as firewalls, observability tools etc.

The most controversial business model for a blocklist is selling delisting as a service, offering paid immediate removal; otherwise you wait for expiry. Charging to remove a block can create perceived conflicts of interest and is not the norm among well-regarded operators. Being listed on a major blocklist can significantly degrade an organisation’s ability to reach users or customers on the internet.

Email as an example that everyone can understand

Email is a relatable example; large mailbox providers and platforms (e.g., Microsoft, Google) often incorporate third-party and proprietary reputation systems into their email ingress flow. Listed IP or domain may see their deliverability collapse and their e-mails end up in Spam folders, even if outright blocking isn’t universal. However, in worst-case scenarios, emails from a blocklisted source may be silently dropped, never to be seen again. Likewise, many enterprise security products (e.g., those from Cisco or Fortinet) can consume external reputation feeds, which means businesses may lose contact with their largest partners or customers, risking direct financial loss.

The effect is often worse for shared infrastructure (cloud or hosting) providers such as Zone, where one actor’s behaviour can taint many tenants or customers. This is why we take the reputation of our network resources – IP address space, subnets, and domain names – very seriously. Accordingly, customer actions or inaction that lead to third-party blocklists against our resources constitute a breach of our Acceptable Use Policy (AUP).

We have developed and deployed several observability tools to detect and notify us and our customers of actions on our infrastructure that may cause our customers or resources to be blocklisted. Where feasible, we assist our customers with early detection, root-cause analysis, and appeal processes to expedite delisting. Repeated or intentional abuse may still result in service restrictions or termination under the AUP.

Blocklists are a valuable resource, as they serve as an effective security measure to manage cybersecurity risks. Implementing blocklists should be considered an integral part of any organisation’s cybersecurity toolkit, but they do require careful consideration.