Most perimeter teams still treat Autonomous System Numbers as either a blunt deny switch or a curiosity for the threat intel slide deck. ASN context earns its keep when it shapes graduated controls: who gets challenged, who gets rate-capped, and which paths stay reachable only from networks you have already vetted for your business.
That stance matters more in 2026 than it did when bulk blocklists of “bad ASNs” felt sufficient. Extortion crews stage inside ordinary cloud numbers, APT groups such as Mirage Kitten rotate through regional hosting providers while targeting aviation and FinTech across the Middle East and Africa, and ransomware operators that weaponize Active Directory GPO (PAYLOAD) still need outbound paths that look like routine SaaS egress. Machine-speed defense only helps if your ASN policy can change as fast as those exits do.
Where ASN filtering usually goes sideways
Security teams collapse three different problems into one ASN label. First, they confuse provider ownership with attacker ownership: a single cloud ASN may hold millions of customers, including your vendors and your attackers. Second, they apply the same ASN score to public web traffic and to privileged paths such as VPN, RDP jump hosts, hypervisor consoles, and identity admin portals. Third, they update ASN deny lists on a weekly cadence while campaign infrastructure moves in hours.
The practical failure mode looks familiar. An analyst blocks a bulletproof hoster’s ASN after a wave of probes, then opens an emergency exception when a partner’s CDN or a regional ISP share space nearby. Meanwhile, credential stuffing and ransomware staging continue from hyperscaler ranges that never land on a “known bad ASN” list. FBI-tracked identity theft markets and large breach dumps feed that pressure: attackers buy access and fire from rented compute that inherits a clean provider ASN on day one.
What ASN context actually gives you
An ASN is a routing and operational unit. It tells you who announces the prefix, how traffic is expected to enter the Internet, and which abuse desk you can escalate to. It does not tell you that every host behind that number is hostile. Used correctly, ASN data answers operational questions:
- Is this source network a consumer ISP, a mobile carrier, a hyperscaler, a hosting reseller, a university, or a corporate enterprise?
- Does this ASN routinely appear in scanner and malware telemetry for our sector, or is this a first-time neighbor of a known campaign?
- Should traffic from this ASN ever touch management planes, or only customer-facing application ports?
- If we throttle or challenge this ASN, which business workflows break first?
Those questions map cleanly to controls. Consumer and mobile ASNs rarely need direct RDP to your jump hosts. Hosting and VPS ASNs deserve stricter budgets on authentication endpoints. Enterprise partner ASNs can sit on an allow-for-admin list after verification. Hyperscaler ASNs need path-aware policy because your own CI runners, SaaS webhooks, and attacker bots share the same numbers.
A working model: classify, score, then bind policy to path
Build ASN filtering as a three-layer system rather than a single firewall object.
1. Maintain a living ASN inventory for your edge
Pull origin ASNs for every connection that hits high-value listeners: VPN concentrators, SSO/admin URLs, SSH bastions, mail gateways, and API ingress. Store ASN, organization name, country of registration, prefix length, and first/last seen. Enrich daily from RIR and commercial ASN databases, and reconcile against your own allowlists for partners and managed service providers.
Keep a short “business-critical ASN” set you review quarterly: cloud regions you actually use, MSP monitoring networks, payment processors, and key B2B partners. Everything else starts untrusted for privileged paths even when it is allowed for public content.
2. Score ASNs for your environment, not for the Internet
Create an internal score from signals you already own:
- Volume and uniqueness of source prefixes probing unused ports or honeypots
- Auth failure density on VPN and SSO from that ASN over rolling 24-hour and 7-day windows
- Overlap with your abuse-feed matches and malware sandbox egress in the last 30 days
- Whether the ASN is a shared hosting platform versus a single-tenant enterprise network
- Abuse-desk responsiveness from prior tickets
Weight shared cloud ASNs differently from niche VPS providers. A spike from a major cloud ASN often means one rented tenant, so prefer prefix- or account-adjacent containment over ASN-wide deny. A spike from a small hosting ASN with repeated scanner behavior can justify broader throttling at the edge.
3. Bind ASN policy to traffic class
Use four default postures:
- Public applications: allow widely, apply bot and rate controls keyed by ASN plus path, and escalate only high-score ASNs to challenge or temporary deny.
- Authentication surfaces: cap concurrent attempts per ASN, force step-up or CAPTCHA for high-risk ASN classes, and alert when a new ASN appears in successful admin logins.
- Management and remote admin: default deny except explicitly approved ASNs and, where possible, require client VPN or ZTNA so the Internet-facing ASN of the operator is no longer the trust root.
- Outbound from servers: restrict egress ASNs for application tiers so ransomware staging and data exfiltration cannot freely reach arbitrary VPS networks.
This is the difference between “ASN filtering” as folklore and ASN filtering as policy engineering. The same Mirage Kitten-style malware set that pivots through regional hosting becomes noisier when admin paths refuse those ASNs outright and application paths only slow them down.
Playbook for the first 30 days
Week 1 — Measure before you deny. Export 14 days of edge and auth logs with source IP, ASN, destination port or URL class, and outcome. Rank ASNs by failed auth, port scans, and successful privileged access. You will usually find a handful of hosting ASNs dominating noise and a smaller set of unexpected ASNs touching admin success events.
Week 2 — Split policy objects. Create firewall or WAF groups for hyperscaler, hosting/VPS, consumer ISP, mobile, education, and approved-partner ASNs. Attach different rate limits and geo-plus-ASN rules. Keep partner ASNs in a change-controlled object with owners and expiry dates.
Week 3 — Protect privileged paths first. Move VPN, RDP gateways, hypervisor consoles, and identity admin portals onto an approved-ASN or ZTNA-only posture. PAYLOAD-style GPO abuse still needs an initial foothold; shrinking which networks can even reach those surfaces cuts the early probe window that precedes encryption.
Week 4 — Automate refresh and exceptions. Sync ASN membership from routing data so your groups track renumbering and transfers. Build an exception workflow that records business owner, ticket, and review date. Feed SOC detections when a previously unseen ASN succeeds on auth or when a high-score ASN suddenly appears on a scrubbed “clean” customer journey.
Implementation details that survive production
Prefer prefix lists derived from current ASN announcements over static IP dumps you freeze for months. Validate announcements with looking-glass or IRR data when a high-impact deny is on the table. For dual-stack estates, score IPv4 and IPv6 ASN exposure separately; attackers often keep IPv6 paths quieter while your playbooks still focus on IPv4.
On reverse proxies and API gateways, key rate limits as ASN + route + credential identity rather than ASN alone. That stops password spray from rotating across many cloud IPs inside one provider while still allowing legitimate burst traffic from a single enterprise ASN.
When an ASN match coincides with an abuse-feed hit, treat the ASN as campaign scope, not as automatic proof of compromise. Expand to neighboring prefixes, passive DNS for co-hosted names, and certificate transparency where relevant, then decide whether to throttle the ASN class or contain a narrower set of prefixes.
Takeaways you can hand to the SOC and network team
- Use ASN as a traffic-class and path-policy signal, especially for admin and auth surfaces.
- Score ASNs from your own telemetry; shared cloud numbers need finer controls than niche hosting ASNs.
- Keep a reviewed allow set for business-critical networks and expire every exception.
- Refresh ASN membership from live routing data so transfers and renumbering do not leave holes.
- Pair ASN controls with identity and host timelines so a perimeter drop never substitutes for hunting sessions that already succeeded.
ASN-based threat filtering works when it encodes how your organization actually uses the Internet: which networks may administer you, which may only browse you, and which deserve continuous friction. That is how perimeter policy stays current while attackers rent ordinary cloud space and campaign news keeps accelerating.
