The Lead

The Spamhaus ASN-DROP list — the network-layer cousin of Spamhaus's famous IP blocklists — currently names 399 Autonomous System Numbers as hijacked or leased by professional spam and cyber-crime operations, a count that jumps around week to week as operators rotate infrastructure and as Spamhaus's takedown team pulls ASNs off the list when the underlying abuse stops. That's 399 out of roughly 100,000 ASNs visible on the global routing table — less than half a percent — and yet those 399 networks account for a meaningful share of what your application firewall sees when it gets scraped, credential-stuffed, or fraud-tested.

That ratio is the whole case for ASN-based blocking. Abuse concentrates at the network level in ways that IP-level and country-level rules can't efficiently capture. But the flip side is that ASN rules are a much blunter instrument than they look, and the wrong ASN block will quietly lock out tens of thousands of legitimate customers while you're watching the dashboard celebrate a drop in bot traffic.

TL;DR

• An ASN is the identifier for an Autonomous System — a network operator that announces routes on the public internet via BGP. There are roughly 100,000 active ASNs worldwide.
• Block hosting ASNs liberally for consumer-facing traffic (OVH, Hetzner, DigitalOcean, Vultr) — residential users don't originate checkout requests from a VM.
• Mixed ASNs (Cox, Orange, many APAC carriers) sell both residential broadband and cloud hosting. Blocking wholesale hurts real customers; rely on per-IP hosting/residential flags instead.
• Pair ASN rules with Spamhaus ASN-DROP as a baseline, layer your own observed-abuse data on top, and prefer step-up challenges over hard blocks when user impact is ambiguous.

What an ASN Actually Is

An Autonomous System Number is the identifier that uniquely names an operator of IP networks on the public internet. Every ISP, hosting company, cloud provider, corporate network, and university that announces its own routes — rather than relying entirely on an upstream provider to do so — holds at least one ASN, assigned by one of the five Regional Internet Registries (RIPE NCC in Europe and the Middle East, ARIN in North America, APNIC in Asia-Pacific, LACNIC in Latin America, and AFRINIC in Africa). The ASN is how routing decisions get made at internet scale: when traffic needs to reach an IP in, say, 185.220.101.0/24, routers around the world look at BGP-4 to learn that AS208294 (or whoever currently announces that prefix) is the origin, and they stitch together a path to that AS through their own peering and transit relationships.

The protocol that makes all this work is defined in RFC 4271, "A Border Gateway Protocol 4 (BGP-4)." BGP-4 is the exterior routing protocol of the internet. Operators "announce" prefixes — sets of IP addresses — into BGP, and those announcements propagate across the default-free zone, where every major transit network maintains a full view of which AS originates which prefix. The RFC formalizes the message types, the attribute set, and the loop-prevention logic that prevents BGP announcements from spiraling.

Two practical properties matter for blocking policy. First, BGP is an eventually-consistent broadcast system, so changes in AS origin take seconds to minutes to propagate globally. Second, an ASN is per-organization, not per-site — a single AS can announce prefixes from multiple geographic regions and serve wildly different kinds of customers. AS14061 (DigitalOcean) announces IP space in a dozen countries. AS22773 (Cox Communications) serves both residential broadband and business colocation. Any rule written against "ASN 14061" applies to all of that uniformly, which is both the superpower and the hazard of ASN blocking.

Originally, ASNs were 16-bit (0–65,535). The registries started running low in the late 2000s and standardized 32-bit ASN space (RFC 6793). Most new allocations are now 32-bit. You'll encounter both formats; when in doubt, treat them as opaque identifiers.

Three Types of ASN You'll Encounter

Not all ASNs are created equal for blocking purposes. The first instinct — "block the ASN if it's associated with abuse" — needs to be tempered by understanding what kind of operator you're actually looking at. There are three rough buckets, and they demand very different policy stances.

Pure Eyeball ISPs

Operators like Comcast (AS7922), BT (AS2856), Deutsche Telekom (AS3320), and Verizon (AS701) primarily sell residential internet service. Their IPs are assigned to home broadband, cable, DSL, and mobile customers — the "eyeballs" that internet peering agreements exchange traffic to serve. Blocking a pure eyeball ISP wholesale is almost always wrong. Even if you see a concentrated attack from one of them, the underlying customer base is overwhelmingly legitimate, and a wholesale block will hit orders of magnitude more real users than attackers. For eyeball ISP abuse, rely on per-IP signals (risk score, recent telemetry, behavioral patterns) rather than the ASN itself.

Pure Hosting Providers

OVH (AS16276), Hetzner (AS24940), Vultr (AS20473), Hostinger (AS47583), Linode/Akamai (AS63949), DigitalOcean (AS14061), and similar networks primarily rent compute to developers and businesses. Residential users do not originate web traffic from these ASNs. When you see a login attempt, a product-page scrape, or a checkout from one of these networks, it's almost certainly a bot, a headless browser, a scraper proxy, or a cloud-hosted VPN. For consumer-facing applications, blocking traffic from pure hosting ASNs is the single highest-leverage policy you can ship — the collateral damage is near-zero. The main exception is B2B SaaS, where customers may legitimately connect through cloud-hosted corporate VPNs or CI systems.

Mixed ASNs

This is the tricky middle. Cox Communications (AS22773) sells home cable but also runs a hosting product. Orange (AS3215) is both a French ISP and a cloud operator. Many large APAC carriers (China Telecom, Reliance Jio, Singtel) bundle residential, business, and data-center IP space under one AS. The raw "is this a hosting provider?" question doesn't have a clean yes/no answer at the ASN level; it has to be answered per-IP. This is why Predax exposes classification.is_hosting and classification.is_datacenter as separate per-IP boolean flags rather than as a single ASN-level attribute — the underlying datasets have to distinguish the /24 inside AS22773 that's serving home cable from the /24 that's serving business colo.

How to Look Up an IP's ASN in 30 Seconds

You'll want this every time you investigate a suspicious login or a scrape pattern. Four methods, in increasing order of programmability:

whois from your terminal

Every RIR exposes WHOIS, and most systems include a whois client. Run whois 185.220.101.1 and you'll get back the registration record, including the originating ASN and the registered organization name. For IPs registered with RIPE, the RIPE NCC whois service is authoritative; for North American IPs, ARIN's whois is the source. Traditional WHOIS is free, cache-friendly, and human-readable, but its rate limits are conservative and the response format isn't machine-parseable without effort.

Team Cymru DNS lookup

Team Cymru's IP-to-ASN mapping service turns BGP data into a free DNS-based lookup, refreshed every four hours from their peering with 50+ BGP speakers. The query format reverses the IP's octets and queries under origin.asn.cymru.com:

$ dig +short 1.101.220.185.origin.asn.cymru.com TXT
"208294 | 185.220.101.0/24 | DE | ripencc | 2016-02-25"

The response is pipe-delimited: origin ASN, BGP prefix, country, registry, allocation date. For IPv6 use origin6.asn.cymru.com with nibble-reversed addressing. This is the cheapest programmable lookup that scales — it's a DNS query, so you can do a few thousand a second before anyone notices.

RIPE Stat web UI

RIPE Stat is RIPE's public analytics portal for BGP and RIR data. Plug in any IP and get the current origin ASN, historical announcements, geolocation, and associated IX presence. Great for one-off investigation, too slow for bulk use.

Predax API

A single call to /api/v1/check/ip returns network.asn, network.as_name, the hosting / datacenter classification flags, and a composite risk score:

$ curl -X POST https://predax.io/api/v1/check/ip \\
    -H "X-API-Key: prdx_..." \\
    -H "Content-Type: application/json" \\
    -d '{"ip": "185.220.101.1"}'
{
  "ip": "185.220.101.1",
  "version": 4,
  "classification": {
    "risk_score": 95,
    "risk_level": "high",
    "is_hosting": true,
    "is_datacenter": true,
    "is_tor": true,
    "flags": ["tor", "datacenter"]
  },
  "network": {
    "asn": 208294,
    "as_name": "MIVOCLOUD SRL"
  },
  "location": {
    "country_code": "DE"
  }
}

The classification.risk_score, classification.is_hosting / classification.is_datacenter split, and derived Tor/VPN/proxy signals are the value-add over raw BGP data — they answer the decision question, not just the identity question. See the API reference for the full schema.

When ASN Blocking Wins Over Country or IP Blocking

ASN rules excel in three specific scenarios where country or per-IP rules fail.

First, rotating-IP abuse. A scraper renting capacity on a hosting ASN can cycle through hundreds of IPs per hour as its VMs spin up and down. IP-level blocklists become obsolete in minutes. A country-level block on whatever country the ASN happens to be registered in hits huge numbers of unrelated users. An ASN-level rule catches every current and future IP in that operator's space, including the ones the scraper hasn't used yet. This is why our proxy-detection API guide recommends ASN-based policy as the durable layer behind proxy feeds — the per-IP data tells you what's happening today; the ASN tells you what to do tomorrow.

Second, residential vs. datacenter distinction at scale. A residential proxy service might rotate through a million IPs on Comcast, Spectrum, and similar eyeball networks. Those can't be blocked at the ASN level without collateral damage. But the bot traffic that *isn't* routed through residential proxies — the 70-80% that comes direct from hosting — is cleanly catchable with ASN rules. We cover this distinction in detail in the proxy-type analysis; the takeaway is that ASN blocking is the right hammer for hosting-originated traffic and the wrong hammer for residential.

Third, IPv6 practicality. A single customer on IPv6 is typically assigned a /64 (18 quintillion addresses) or an entire /56 (4.7 billion addresses) from their ISP. CIDR-level IP blocking scales abysmally in IPv6 — you're either blocking each individual address as it abuses, which lets the attacker walk across the prefix for free, or you're blocking wider than you want. ASN-level rules don't care about IP version and apply uniformly. If your application takes IPv6 traffic (which it should), ASN rules are the only workable long-term policy for prefix-cycling attackers.

A concrete example: suppose you run a consumer e-commerce site and you observe a credential-stuffing campaign originating from IPs announced by DigitalOcean (AS14061). Blocking DigitalOcean IPs at the WAF costs you approximately zero legitimate purchases — real customers don't buy shoes from a cloud VM. Blocking the equivalent number of IPs by writing per-IP rules would take weeks and still leave gaps. Blocking "United States" would nuke most of your customer base. The ASN rule is the correct tool for this specific job.

You can pair this with country blocking and AI scraper detection for a layered policy — country rules for compliance, ASN rules for abuse prevention, crawler verification to avoid blocking legitimate indexing.

When ASN Blocking Is a Bad Idea

Equally important is knowing where the ASN lever is the wrong tool.

Mixed ASNs are the single most common footgun. During an internal investigation in April we traced a series of false-positive risk-score boosts on IPs belonging to Cox Communications (AS22773). Cox shows is_hosting=true in our dataset because it operates business hosting products, but it's simultaneously one of the largest U.S. residential cable providers — most of its ASN traffic is real home broadband customers streaming Netflix. A rule of "elevate risk if hosting=true" was correctly firing; a rule of "block AS22773" would have been catastrophic. The fix in our case was to treat mixed ISPs like Cox as a special class and cap their risk boost, preserving the signal while preventing the cap from ever triggering an outright block. If you're writing ASN rules of your own, map your blocklist candidates against their residential user populations before flipping any switch.

Mobile-carrier ASNs are similarly dangerous. AS22394 (Verizon Wireless), AS21928 (T-Mobile USA), AS15169 (Google — which carries Google Fi), AS55836 (Reliance Jio) and many others route tens or hundreds of millions of legitimate mobile users. Carrier-grade NAT means a single IP may represent hundreds of real customers. Blocking an entire mobile carrier's ASN is almost never defensible outside of extreme sanctions or compliance scenarios.

You can block yourself. If your own CI runners, monitoring probes, or cloud infrastructure live on a hosting ASN you're about to block, you'll cut off your own health checks and deployment tooling. Before you ship a block on, say, DigitalOcean, confirm your staging environment, uptime monitors, and status pages aren't running there too. A five-minute audit against your cloud provider's console will save a three-hour incident later.

Finally, small obscure ASNs often misrepresent themselves. Not every ASN name in WHOIS corresponds to a well-run organization. Some ASNs have been sold, leased, or reassigned informally. A block on "AS-YOURPROVIDERNAME" at month 1 may become a block on an unrelated customer organization at month 12. Refresh your mental model of the block list at least quarterly.

Public ASN Block Lists You Can Use

You don't have to build ASN intelligence from scratch. Several maintained public lists cover the highest-risk networks:

[Spamhaus ASN-DROP](https://www.spamhaus.org/drop/) is the best-known ASN blocklist. It enumerates Autonomous System Numbers that Spamhaus has identified as entirely or primarily used by professional spam or cybercrime operators — not mixed-use networks with some abuse, but networks Spamhaus considers fundamentally unsafe. The list is conservative (roughly 399 ASNs at time of writing), aggressively-maintained, and freely available in JSON and plain-text formats. The counterpart DROP/EDROP lists cover IP-level CIDR blocks. ASN-DROP is the right baseline input for any ASN blocking policy — if an ASN is on ASN-DROP, you can safely default-deny it without doing your own research.

[FireHOL's IP lists project](https://iplists.firehol.org/) aggregates and normalizes dozens of open threat-intelligence feeds. While FireHOL's primary focus is IP-level blocklists rather than ASN-level ones, the feeds it normalizes can be post-processed into ASN distributions — if 80% of the hits in a given feed map to three ASNs, that's a strong signal those ASNs deserve a rule. FireHOL maintains feed provenance and update frequency for every source it aggregates, which is useful when you're sanity-checking an old block.

[CAIDA's Spoofer project](https://spoofer.caida.org/) publishes IP-spoofing measurement data at the AS level. ASNs that do not filter source-address spoofing on outbound traffic are disproportionately the source of reflection-amplification DDoS attacks. The Spoofer data is most useful for edge-network operators and CDN providers deciding which upstream peers to scrutinize, but the underlying AS list is a reasonable candidate pool for aggressive blocking on sensitive endpoints.

Treat these three lists as complementary starting points. Spamhaus ASN-DROP is low-false-positive; use it unconditionally. FireHOL-derived ASN aggregations need contextual review; use them for policy suggestions, not automated bans. CAIDA Spoofer data is specialist; use it when network-hygiene posture matters to your threat model.

Building Your Own ASN Policy

The public lists catch the obvious worst actors. Your own logs catch the patterns that matter specifically to your application. A durable ASN policy blends both.

Start with observed abuse. Pull the top-50 ASNs by block count from the last 30 days of your WAF logs, threat telemetry, or application-level abuse reports. Tag each with its hosting/residential classification (from Predax's is_hosting and is_residential flags, or equivalent data), its Spamhaus ASN-DROP status, and an abuse-ratio score: how many of its IPs in your logs were flagged as abusive divided by how many of its IPs showed up at all. An ASN with a 90% abuse ratio is worth an automatic rule; an ASN with a 5% abuse ratio is not.

A three-tier scoring model works well in practice:

The tiers map cleanly onto action types: Tier 1 is a hard WAF rule, Tier 2 is a friction step at sensitive endpoints, Tier 3 is "do nothing special." Review Tier 1 quarterly — abuse operators move, and the ASN that was Tier 1 a year ago may have cleaned up under new ownership. Review Tier 2 monthly while you're collecting data; over time, some Tier 2 ASNs graduate to Tier 1, others de-escalate.

The key discipline: never move an ASN to Tier 1 on gut feel. If Spamhaus doesn't list it and your own logs don't show overwhelming abuse concentration, leave it on per-IP evaluation. The cost of a wrong hard-block at the ASN level is thousands of legitimate users hitting a 403 page with no recourse. The cost of a wrong step-up is one CAPTCHA. Asymmetry like that should govern the policy.

How Predax Helps

Every call to /api/v1/check/ip returns the fields you need to drive ASN-aware decisions without running your own BGP infrastructure: `asn` (the origin Autonomous System Number), `asn_org` (the registered operator name), `is_hosting`/`is_residential`/`is_cloud` boolean classifications that split mixed-ASN populations correctly at the per-IP level, `country_code` from the underlying geolocation, and the composite `risk_score` (0-100) that blends ASN context with per-IP history, Tor/proxy/VPN status, and community telemetry. The per-IP hosting/residential split is the key to making mixed-ASN policy work — you get the granular signal rather than a coarse ASN-level bucket.

The admin dashboard's Threat Intelligence view includes ASN drill-downs showing the Autonomous Systems with the most flagged hits against your account over configurable windows. If you notice a specific hosting provider consistently topping the list, you have the raw evidence to move it to a Tier 1 auto-block in your own policy — and you can export the drill-down for compliance or post-mortem use.

The WordPress and WooCommerce plugins apply IP-level rules (allowlists, blocklists, CIDR ranges) directly in the plugin UI — ideal for targeting specific ranges without writing server-side code. For ASN-level policy specifically, the API is the cleanest integration point; most customers wire ASN decisions into their CDN or application middleware and use the plugin for IP-level guardrails at the content layer.

None of this replaces a proper edge WAF for DDoS or specialist threat-intelligence feeds for nation-state actors. It gives you the ASN signal correctly, at the per-IP granularity you need to avoid the mixed-ASN trap, in a form you can make decisions on in real time. View pricing for plan tiers including a generous free plan for small-scale production use.

Frequently Asked Questions

Can I block all hosting ASNs safely?

For most consumer-facing web traffic, yes — and you probably should, at least for sensitive endpoints like signup, checkout, and login. Residential customers essentially never originate HTTP traffic from a DigitalOcean or Hetzner IP; when they do, it's a VPN, a corporate proxy, or malware, and any of those is a reasonable basis for a friction step like a CAPTCHA. The safe pattern is not 'hard-block every hosting ASN' but rather 'apply a step-up challenge when the IP is on a hosting ASN and the request is sensitive.' The one real exception is B2B SaaS where your customers legitimately access you through corporate NAT or cloud-hosted VPNs — in that case, allowlist the customer organizations' specific ranges rather than opening the whole ASN class.

How often do ASNs change?

An ASN itself is basically permanent — once assigned by a Regional Internet Registry, it sticks with the organization that got it, and ASNs are rarely transferred. What changes is the set of IP prefixes an ASN announces. Large networks add and retire prefixes constantly as they lease blocks, migrate customers, or spin up new PoPs, so an IP-to-ASN mapping needs to be refreshed at least daily from an authoritative source like Team Cymru's IP-to-ASN service or live BGP feeds. If you cache a mapping for a week, you'll have stale data. If you cache for an hour, you're fine for nearly every policy use case.

What's an ASN vs a CIDR range?

A CIDR range (like 185.220.101.0/24) is a specific block of IP addresses. An ASN (like AS14061) is the network operator that announces one or more CIDR ranges to the internet via BGP. Every routed IP belongs to exactly one origin ASN at any given moment, and that ASN might announce hundreds or thousands of CIDR blocks. Blocking a CIDR is precise but narrow; you block the specific addresses listed. Blocking an ASN is broad; you block every current and future IP that operator announces. For rapidly-rotating abuse traffic, ASN blocking is strictly more durable — you don't have to chase new ranges as the attacker cycles through them.

Does blocking an ASN block legitimate VPN users?

Yes, and this is the main trade-off. Consumer VPN services almost always run on hosting ASNs — NordVPN, ExpressVPN, and similar providers rent capacity from DigitalOcean, OVH, M247, and other commercial hosting networks. If you block those ASNs wholesale, every customer behind those VPNs loses access. For a marketing site or a B2C e-commerce flow where VPN usage correlates strongly with fraud, that may be the right trade-off. For a B2B tool, a mental-health service, or a site whose users have legitimate privacy needs, it probably isn't. The middle path is the same as above: step up to a challenge rather than hard-block, and let the legitimate user solve a CAPTCHA or verify via email.

Related guides

• Residential vs datacenter proxies — the underlying ASN-type distinction this whole technique rests on.
• How to detect VPN users — VPN ASNs are the canonical use case for ASN-level blocking.
• Proxy detection API guide — the per-IP version of the same problem.
• How IP risk scoring works — combining ASN reputation with per-IP signals.
• Bot traffic in 2026 — why ASN blocking is the highest-leverage bot filter.