Block a /32 and an attacker rotates to the next address in the same /24. Block the /24 and they jump to a sibling prefix on the same hoster. Eventually you realise you’re not fighting an IP — you’re fighting a whole autonomous system that someone is using as cheap, disposable infrastructure. The ASN Lookup tool on PortJar lets you see the AS as a unit: who runs it, where it sits, and every prefix it currently announces.
What the tool does
Given an IP address, it returns the AS number that originates the prefix containing that address. Given an AS number, it returns the registered holder, the country of registration, and the full list of IPv4 and IPv6 prefixes that AS is currently announcing — pulled from RIPE Stat, which mirrors the global BGP routing table. That second mode is the one most operators underuse. It’s the difference between knowing “this address belongs to AS-foo” and knowing “AS-foo announces these 47 prefixes, totalling roughly 1.2 million IPv4 addresses, of which the offending /24 is one.”
How to use it
Open portjar.com/tools/asn-lookup. Enter either an IPv4 address, an IPv6 address, or an AS number (with or without the AS prefix — both AS14061 and 14061 work). The response shows the holder, country, and prefix list. For an IP, follow up by entering the returned AS number directly to see its full footprint.
When you’d reach for it
- Deciding whether to escalate a block from an IP to a prefix to an entire AS. When the third address from the same provider hits your fail2ban list this week, ASN Lookup tells you the prefix list. Blocking the AS is a heavy hammer but sometimes the right one — for a hoster that consistently shelters bad traffic and serves no legitimate customers of yours, it’s defensible.
- Verifying what a CDN or cloud provider actually announces. Cloudflare, Fastly, AWS CloudFront, and similar networks publish IP ranges, but the published list is sometimes stale. ASN Lookup against the provider’s AS number gives you the current authoritative prefix list, which is what your firewall should be allowlisting against.
- Understanding why a single customer site has variable latency from different ISPs. Pulling the announced prefixes of the customer’s transit AS and comparing to traceroute output explains routing asymmetry that page-level metrics can’t show.
- Researching a peering or BGP question. When someone asks “does AS X have a path to AS Y?” the prefix list is the first datum: if the prefixes overlap or are adjacent, peering decisions become much more interesting.
- Building a credible incident report. Reports that say “the attack came from AS14061 (DigitalOcean), originating from the /24 range 167.99.x.x” carry weight that “the attack came from 167.99.123.45” does not.
What to make of the output
The holder name is the registered LIR (local internet registry) — usually the company that bought the AS number. The country reflects registration, not the location of the equipment; a Cayman Islands LIR can run servers in Frankfurt. The prefix list reflects current BGP state at the time of the query; for stable networks it changes daily, for highly mobile networks (cloud providers spinning up and down regions) it can shift hourly. Treat IPv4 and IPv6 prefix lists separately — many networks announce a substantial IPv4 footprint but only a token IPv6 one, or vice versa, and confusing the two leads to allowlists that work for half your customers. When the prefix list is empty or very small, the AS may have been deregistered, may not be currently advertising, or may exist only for downstream peering relationships — none of which are reasons to ignore traffic claiming to originate from it.
For teams who need ASN context surfaced inside their daily ops — fed into alerting, abuse-handling, and BGP-aware monitoring — Stack Harbor builds this in as part of environment management.