How to Block an Entire ISP or Hosting Provider by ASN (2026)

Blocking an ASN removes every address range a single network operator announces to the internet — sometimes a dozen prefixes, sometimes several thousand. It is the right instrument when abuse concentrates inside one hosting company, and a serious mistake when that same number also serves ordinary broadband customers.

The appeal is obvious. An attacker rotating through fifty addresses inside one provider defeats address-by-address blocking, but every one of those addresses sits under the same autonomous system number. Block the number and the rotation stops mattering. Roughly 80,000 autonomous systems are visible in the global routing table as of early 2026, and only a handful will ever be relevant to you.

This guide covers finding the number behind an address, deciding whether that particular network is safe to block, pulling every prefix it announces, applying the result without destroying your firewall's performance, and the one configuration mistake that silently replaces your rules with an error page.

Author: Robert Harrison OSINT & Network Utility Expert

The failure I have cleaned up most often is not an over-broad block. It is a cron job that quietly poisoned its own ruleset. Somebody pipes a prefix list into a firewall file every night, the upstream returns a 502 one evening, and the HTML error page lands in the ruleset instead of the prefixes. No alert fires. The ASN block simply stops existing, and nobody notices for weeks.

My honest position is that ASN blocking is the sharpest tool in this whole category and the easiest to point at your own foot. Before I write a rule I ask one question: does this network sell to consumers as well as to servers? If the answer is yes, or even probably, a prefix list is the wrong response and something narrower belongs there instead.

What Does Blocking an ASN Actually Do?

An ASN block removes every prefix that one operator announces, at whatever layer you apply it. An autonomous system number — a unique identifier for a network under one administrative control, used by BGP to describe routing paths — is not itself something a firewall understands. You translate the number into the list of address ranges it announces, then block those. The number is a lookup key, not a filter.

Those numbers are allocated by IANA to the regional registries and onward to network operators, which is why one belongs to exactly one organisation at a time.

That translation step is what makes an ASN block different from every other scope. A CIDR range is fixed the moment you write it. A prefix list derived from an autonomous system changes whenever that operator adjusts its BGP announcements, which they do without telling anyone.

Scale explains why the third row needs its own handling. The global BGP table carried over a million IPv4 prefixes and roughly 250,000 IPv6 prefixes in 2026, spread across those 80,000 or so active systems. A single large operator can announce several thousand prefixes on its own.

Before any of that matters, you need the number itself, and there is more than one way to get it wrong.

How Do You Find the ASN Behind an Address?

Query the routing data rather than guessing from the organisation name. A WHOIS lookup returns the registered holder of an address block, which is often a customer of the network actually announcing it. What you want is the origin AS — the operator putting that prefix into BGP. Those two answers differ more often than people expect, particularly with resellers and bulletproof hosting.

Expect large numbers, too. Modern allocations use the 32-bit space introduced by RFC 6793, so values run well above the old 65,535 ceiling.

Routing registries answer the reverse question too. Given a number, they return every route registered against it, which is the list you will eventually feed your firewall.

Two accuracy notes worth carrying. Registry data can be stale where operators have not maintained their records, so live BGP observation gives a truer picture. And a list derived purely from announcements covers only the space that operator originates — traffic routed through a partner network will not appear. If you are working backwards from a website rather than a log line, our guide on tracing a site to the server behind it covers the first step.

With a number in hand, the important decision arrives — and it is not a technical one.

Which ASNs Are Safe to Block and Which Are Not?

Judge the ASN by who buys from it. A pure hosting or bulletproof provider sells to servers, so blocking it removes machines rather than people and the collateral damage is close to zero. A consumer broadband operator sells to households, and blocking one is worse than a country block because it removes a specific population with no warning and no obvious pattern. Mixed networks sit between, and they need narrower treatment.

Row three carries the expensive mistake. Cloud platforms host the scraper and your payment webhooks, your uptime monitors and your own staging environment, all inside the same number. Reputation data helps here rather than instinct — our explainer on how address reputation is actually scored covers what the signals mean before you act on them.

Decision made, the next job is turning one number into a usable list.

How Do You Get Every Range an ASN Announces?

Export the ASN's prefix list, then merge it before it reaches your firewall. Raw exports frequently contain adjacent or overlapping blocks that collapse into fewer entries, and every entry you remove is a rule your firewall never evaluates. Merging is not cosmetic tidying — on a large network it is the difference between a few hundred entries and a few thousand.

Handle IPv4 and IPv6 separately, because they need different rule families and it is easy to export one and quietly forget the other. Pull the full set with an export of every block a network announces in the syntax your firewall speaks, then run the result through an overlap check that merges what it can before you deploy anything.

Volume is exactly where most ASN blocks go wrong, and the fix is a different mechanism rather than a longer file.

How Do You Apply It Without Wrecking Your Firewall?

Use a set, not a rule per prefix, whatever the ASN's size. Classic firewall rules evaluate in sequence, so a few thousand of them means a few thousand comparisons on packets that were always going to pass. A hash set matches in constant time regardless of size, which turns a five-thousand-prefix network into one lookup and one rule. This is the single most important implementation choice in the whole topic.

On newer systems the same idea is built in. nftables carries native sets, so no separate utility is involved, and updates apply atomically rather than rule by rule. Declaring the table in the inet family lets one ruleset cover IPv4 and IPv6 together. Most distributions now ship it by default.

Three rows are worth pausing on. Cloudflare handles this natively because its rule engine exposes the AS number as a field, and anyone it stops sees a specific page: error 1005, access denied, autonomous system number banned — so a customer sending you that screenshot has met a rule of yours. The walkthrough of building expressions in the Cloudflare rule engine covers. Apache cannot: it understands addresses and CIDR only, so the theoretical workaround is pasting thousands of prefixes into a file that gets read on every single request — which is exactly the performance trap described in our guide to server-level rules and what they cost you.

A working set still degrades, and it does so quietly.

Why Does an ASN Block Stop Working?

Because the ASN's underlying announcements move. Operators add prefixes, retire them, and shift address space between numbers as their business changes, so a list exported six months ago describes a network that no longer exists in that shape. Nothing warns you. Traffic simply starts arriving from ranges your set does not contain, and the block appears to have failed when it has only aged.

Automation is therefore mandatory rather than a refinement. A weekly refresh keeps the set honest, and the refresh itself needs one guard most scripts omit.

The Flag That Saves Your Ruleset

When your script fetches a prefix list over HTTP, a failing upstream returns an error page rather than an error. Without the fail-on-error flag, that HTML lands in your rules file, your reload either breaks or silently loads nothing, and your protection disappears without a single alert.

Write to a temporary file, confirm it is not empty, and only then replace the live one. Three extra conditions, and the failure mode from my opening story never happens.

Why Is Allowlisting an ASN More Dangerous Than Blocking One?

Because anyone can rent a machine inside that ASN. Allowlisting a network means every customer of that network inherits your trust, including the attacker who signed up this morning with a stolen card. Blocking too broadly costs you legitimate visitors and you find out quickly. Allowlisting too broadly costs you your defences and you find out much later, if at all.

The pattern repeats across this whole subject. Verifying a crawler against a vendor's entire corporate address space rather than its crawler ranges fails for exactly the same reason. Broad trust is always cheaper to abuse than broad denial.

With the decision and the mechanism settled, deployment is a sequence rather than a command.

How Do You Deploy an ASN Block Safely?

Stage it, log it, then enforce it. An ASN block is the widest rule you can create from a single decision, so the gap between what you intended and what actually happens is correspondingly large. Running it in log-only mode for a day tells you exactly who would have been removed, and that list is almost always longer than the one you pictured when you started.

Step three is the one experienced admins add after being burned. Your own integrations are invisible in a prefix list; they only appear when they stop working, usually at the worst moment.

That is the full path from a suspicious log line to a rule you can defend. Here is the short form.

The Short Version

Block an ASN when abuse concentrates inside one hosting operator and address-by-address blocking cannot keep up with the rotation. Look up the ASN actually announcing the address rather than the organisation registered against the block, because with resellers those two are frequently different companies. Then judge the network by its customers: hosting and cloud are candidates, mobile carriers and consumer broadband are not.

Export every prefix, merge what overlaps, and load the result into a set your firewall matches in one rule. Sets match in constant time; a rule per prefix does not, and a large operator can announce thousands. Apache cannot do this at all, and Cloudflare can do it natively in a single expression.

Then automate the refresh, because an ASN's BGP announcements change without notice and a stale list is a block that quietly stopped working. Guard the fetch with fail-on-error and an empty-file check so a bad upstream never overwrites your rules. And choose the layer deliberately before any of this — our comparison of every place a block can live works through that decision in full.