IP99

Posted on Oct 21

One Ban Is One Building: CGNAT, Shared Egress, and Ban-Scope Decisions

#api #devops #networking #security

Hard-banning a single public IP feels precise. On many networks it is not. Carrier-grade NAT (CGNAT), mobile egress, and enterprise gateway exits often put dozens to tens of thousands of people behind one address. When you block that address, you are not blocking "the attacker" — you are blocking everyone who happens to share the same egress today.

That is the core idea: an address is not a person. IP99 by ThreatHunter documents this as share tier on its Pulse professional API, and the same docs tell you how to approximate ban-scope decisions from free /v1/ip fields when you do not have Pulse yet.

What CGNAT and shared egress look like in practice

On a classic home broadband line, one household may share a public IP via a home router NAT. That is already multi-user, but the blast radius of a ban is usually one apartment.

CGNAT and carrier pools go further. Mobile operators (usage_type: MOB) and many enterprise / campus gateways (usage_type: GTW) put large numbers of subscribers or employees behind a small set of public addresses. One abusive session on that egress, plus a permanent IP denylist, can look like:

an entire office floor losing access after lunch,
a dorm building locked out during exam week,
or a mobile user who "keeps getting banned" every time the carrier rotates them onto a polluted pool.

The failure mode is not "your blocklist is wrong about risk." It is that the unit of enforcement (one IP) is larger than the unit of identity (one person or one device).

Share tier T0–T3 (Pulse professional context)

IP99's Pulse professional endpoint returns share_tier so you can size the blast radius before you hard-ban. From the official API docs:

Tier	Rough shared users	Typical network	Suggested handling
T0	~1–10	Dedicated / datacenter egress	Hard ban is low collateral
T1	~1–20	Home broadband NAT	Ban possible; may hit one household
T2	~50–2,000	Enterprise line, campus egress	Be careful — one ban can be a building
T3	~1,000–100,000+	Mobile cellular CGNAT	Do not hard-ban the IP; prefer challenge, rate-limit, or down-rank

Share tier also feeds scoring: the more people share an address, the harder old evidence decays, so a T3 score tends to be more conservative than a T0 score on comparable evidence.

Honest boundary: free GET /v1/ip does not return share_tier. That field is Pulse professional only (GET /pulse/v1/ip/{ip}). Do not write pipelines that expect share_tier on the anonymous free call.

What the free API does give you today

You can still make safer ban-scope decisions with free fields. No key required:

curl https://ip99.com/v1/ip/8.8.8.8
curl https://ip99.com/v1/ip

Live shapes re-fetched 2026-10-21 (Asia/Shanghai):

{
  "ip": "8.8.8.8",
  "computed_at": "2026-10-21T13:15:59Z",
  "evidence_state": "none",
  "geo": {
    "city": "Mountain View",
    "country": "US",
    "region": "California"
  },
  "network": { "asn": 15169, "usage_type": "IDC" },
  "risk": { "score": 0, "level": "none", "signals": ["hosting"] }
}

{
  "ip": "140.248.50.7",
  "computed_at": "2026-10-21T13:16:00Z",
  "evidence_state": "none",
  "geo": {
    "city": "Ashburn",
    "country": "US",
    "region": "Virginia"
  },
  "network": { "asn": 54113, "usage_type": "IDC" },
  "risk": { "score": 0, "level": "none", "signals": ["hosting"] }
}

(The second call is this publisher's box egress — datacenter/IDC, so the full address is shown. Mask the last octet for residential or mobile exits in your own posts and tickets.)

Fields that matter for shared-egress triage:

network.usage_type: MOB (mobile), GTW (enterprise / gateway), DYN (residential broadband), IDC (datacenter), and others. Treat MOB / GTW as likely shared even without share_tier.
risk.signals: proxy-class hits such as proxy, vpn, dialup_pool, hijacked_proxy, plus network attributes like hosting / mobile. Do not ban on hosting or mobile alone — 8.8.8.8 carries hosting with score 0.
evidence_state: active (fresh evidence scoring), stale (seen before, aged out to 0), none (never seen — a blind spot, not "clean").
risk.score: 0–100 measuring freshness and strength of verifiable evidence, not "probability this is an attacker."

Anonymous free quota is 500 lookups/day per public IP (X-Daily-Limit / X-Daily-Remaining); signed-in free is 5,000/day. Docs: ip99.com/api.

A practical free-tier playbook

When Pulse is not available, approximate ban scope from usage type + evidence state:

Read evidence_state first. Score 0 with none means "no current evidence," not "safe to permanently allowlist." Score 0 with stale means you saw something earlier — treat it as a weak historical hint.
Classify the network. If usage_type is MOB or GTW, assume high share (T2/T3-like). Prefer CAPTCHA, step-up auth, rate limits, or feature down-rank over a permanent IP ban.
On DYN, still be careful. Home NAT is often T1-ish: a hard ban can lock out a whole household, including the victim of a hijacked_proxy (the docs note the handset owner is often a victim — do not auto-ban accounts on that signal alone).
On IDC with active proxy-class signals, hard bans are lower collateral when evidence is fresh — but still prefer time-bounded blocks. Evidence expires; permanent denylists do not.
Never treat hosting / mobile as proxy verdicts. They describe network placement, not abuse.

Official disposition guidance (generic, not a contract): scores 30–69 → verify rather than ban; 70–100 → decide by business cost and share context; on mobile CGNAT-class egress, skip the IP hard-ban entirely.

Why this matters more than another blocklist

Abuse tooling often sells "IP reputation" as a permanent label. Shared egress breaks that model twice:

Identity mismatch — one address, many people.
Time mismatch — the abusive session leaves; the address stays in your denylist for days or weeks while real users inherit it.

IP99's product stance is that every answer is a judgement that expires, not a permanent label. Free /v1/ip already exposes the fields you need to act on that idea: usage type for likely share, evidence state for trustworthiness, signals for what was observed, and a score that tracks how fresh that evidence is.

When you later need explicit share_tier T0–T3 and per-evidence freshness rows, that is what Pulse professional adds — same score, more context for ban-scope decisions.

Try it

# Any public IP
curl https://ip99.com/v1/ip/8.8.8.8

# Your own egress
curl https://ip99.com/v1/ip

# Quota / plan headers
curl -sI https://ip99.com/v1/ip/8.8.8.8 | grep -iE 'x-daily|x-plan'

Start at ip99.com or the English API reference at ip99.com/api. Before the next hard IP ban, ask one question: are you blocking a person — or a building?

DEV Community