IP Range / CIDR: Data Point Intelligence Guide

Individual IPs rotate hourly. The block they come from does not. CIDR is the level at which infrastructure ownership actually holds still.

Understanding the IP Range / CIDR as an intelligence artifact

A CIDR block expresses a contiguous range of addresses as a base address and prefix length, such as 198.51.100.0/24, where the prefix length gives the number of fixed leading bits. Classless Inter-Domain Routing replaced fixed class boundaries and made allocation and routing arbitrarily granular. A CIDR block is the unit in which Regional Internet Registries allocate address space, in which operators announce routes via BGP, and in which firewalls and access controls are written. It represents administrative ownership of address space.

Analytically, distinguish the allocated block recorded at the RIR from the announced prefix visible in BGP, which may be longer or shorter. Sub-allocations to customers appear as more specific prefixes with their own registry records. IPv6 changes the arithmetic entirely: a single customer commonly receives a /48 or /56, so per-address reasoning collapses and analysis must move to prefix granularity.

Why it matters

Working at block level converts a scatter of unrelated-looking IPs into a coherent picture of an actor estate. If callbacks land on five addresses inside one /24 registered to a shell company, that is far stronger evidence of dedicated infrastructure than five isolated hits. Blocks also drive practical defence: allow and deny lists, geofencing and rate limits are all expressed in CIDR, and knowing the true boundary prevents both overblocking a hosting provider and underblocking a dedicated malicious range.

What analysts actually look for

These are the concrete, observable signals that carry weight in this area of work:

The registered holder, allocation date and country of the block, plus whether it is a direct RIR allocation or a downstream sub-allocation.
Density of malicious indicators inside the block, where a high proportion across a small range indicates dedicated rather than incidental abuse.
Reverse DNS naming consistency across the range, which reveals provider, region and whether addresses are sold as residential or datacentre.
Shared TLS certificates or identical service banners across many addresses, indicating a single tenant operating the whole range.
Recently transferred or leased blocks, common in address brokerage and a frequent precursor to spam and bulletproof hosting use.
Announcement specificity, where a more specific prefix carved out of a larger allocation often marks a distinct downstream customer.
Unrouted or dark portions of a block, useful for spotting hijacked space announced by an unrelated AS.
Neighbour behaviour, where scanning or spam from adjacent addresses raises the prior on the address under investigation.

Where the data comes from

Authoritative and openly available collection points. Always confirm licensing and terms before operational or commercial use:

RIR RDAP and WHOIS (RIPE, ARIN, APNIC, LACNIC, AFRINIC) — Authoritative allocation records, holder organisation, sub-allocations, status and abuse contacts per block.
RIPEstat — Announced prefixes, routing history, visibility and geolocation aggregates for any range.
BGPView or bgp.tools — Prefix to ASN mapping, more-specific announcements and organisational context for the announcing network.
Censys and Shodan CIDR search — Service, banner and certificate inventory across an entire range in a single query.
Spamhaus and abuse feeds with CIDR aggregation — Block-level reputation showing whether abuse is isolated or systemic across the range.
RIR transfer and inter-RIR statistics files — Records of address space transfers and delegated allocation dates for provenance analysis.
IPinfo or MaxMind ASN and hosting datasets — Bulk classification of ranges as datacentre, residential, mobile or hosting for triage at scale.

A working method

A repeatable sequence beats ad-hoc searching. This is a practical starting workflow:

Find the true boundary — Query the RIR for the covering allocation and compare it with the BGP-announced prefix, since the two frequently differ in length.
Identify the holder — Record the registered organisation, allocation date, country and abuse contact, then check for sub-allocation records naming a downstream customer.
Sweep the range passively — Query scan repositories across the whole block for open services, certificates and banners rather than probing addresses yourself.
Measure abuse density — Count distinct malicious indicators within the block over a defined window and normalise by block size to judge dedication versus incident.
Find the tenant fingerprint — Look for a certificate, banner, panel or reverse DNS pattern repeated across addresses, which marks a single operator controlling the range.
Check provenance — Review transfer records and announcement history for recent acquisition, leasing or hijack indicators that change how the block should be treated.
Decide the control granularity — Choose the narrowest CIDR that captures the threat, documenting the collateral impact assessment before recommending any block-level action.

How this connects across the intelligence taxonomy

Intelligence work does not respect neat boundaries. The mission domain you are working, the disciplines you practise, and the data points you pivot on are one connected system. These are the direct relationships for this entry — every link is also a tag, so you can follow any thread across the whole library.

Pivots to these data points

Domain Name — Human-readable address that maps to IP infrastructure via DNS.
IP Address — Internet Protocol address identifying a device or server on a network.
URL — Uniform Resource Locator pointing to a web resource.
ASN — Autonomous System Number identifying a network operator on the internet.
Subdomain — A host under a parent domain — often reveals staging, admin, and forgotten infrastructure.
MAC Address — Hardware address of a network interface; the OUI prefix identifies the manufacturer.

Inside the platform: where IP Range / CIDR lives

The Quantus platform is 204 pages behind a 147-item sidebar organised into six working groups: Command (24 items), Dashboards (15), Threat Theaters (14), Intelligence Domains (15), Investigate (34), and Administration (45). This entry is not a page in isolation — it is a thread running through several of them.

The modules that matter most here:

ioc-type.php?t=ip — IP Range / CIDR profile
datapoint.php?dp=dp_cidr — Data point hub
search.php — Advanced search, filter and pivot
correlate.php — Correlation graph
cases.php — Case management

Each dashboard is local-first: it renders from the platform’s own database rather than depending on a live third-party call, so it still works when an upstream API is unreachable or rate-limited. Heavy aggregates are cached with a hard query time cap and degrade to the last good value instead of hanging the page.

Automation, playbooks and AI skills

Analysis that only happens when someone remembers to run it is not a capability. The platform ships a 30-step automation pipeline (cron.php) that collects, ingests, resolves, enriches, correlates and scores on a schedule — 25 seeders, 11 resolvers and 7 enrichment runners, all idempotent and cursor-based so a run can be interrupted and resumed without duplicating or losing work.

AI skills that apply

The 16 one-click operations in ai-skills.php are deterministic jobs, not free-text generation. The ones that matter here:

Enrichment Runner
Enrichment → Local
Correlate Infrastructure
Resolve Everything
Threat Hunt
Summarise (Copilot)
Generate Report

Alerting closes the loop: rules in alerts.php fire on new indicators matching a saved query, so a first sighting in this area raises a notification rather than waiting to be noticed at the next review.

Feeds, data sources and the API

The collection layer runs a feed registry of free, machine-readable sources — bulk blocklists and trackers (Maltrail, IPsum, FireHOL, the full abuse.ch corpora, phishing databases, Emerging Threats, Spamhaus, DigitalSide, ThreatView), authoritative government feeds (CISA KEV, OFAC, UN and EU sanctions lists), and reference datasets (RIR allocations, ip-to-ASN and geolocation tables, MITRE ATT&CK, EPSS). collect.php pulls them server-side on a schedule; feeds.php and source-catalog.php show what is registered, what it covers and when it last ran.

Anything the platform holds is reachable programmatically. The REST API in api.php exposes 11 endpoints — status, stats, search, lookup, recent, export, bulk_check, top_threats, by_category, categories, check — and export.php streams 18 formats in bounded chunks, so a million-row export neither exhausts memory nor times out:

STIX 2.1, MISP, OpenIOC 1.1, CEF (ArcSight), LEEF 2.0 (QRadar), Zeek/Bro intel, Snort/Suricata rules, Palo Alto EDL, BIND RPZ, hosts blackhole, iptables, CSV, JSON, NDJSON/JSONL, XML.

That covers the CTI standards (STIX 2.1, MISP, OpenIOC), SIEM ingestion (CEF, LEEF, Zeek), detection engines (Snort/Suricata), and direct enforcement (Palo Alto EDL, BIND RPZ, hosts, iptables) — so intelligence developed here can be actioned in the tools you already run, without a manual reformatting step. A TAXII 2.1 server and a MISP/RSS feed are also served for pull-based sharing.

Use cases

Three ways this entry earns its keep in day-to-day work:

Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Find the true boundary is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
Building the picture. A single indicator is rarely the story. Sweep the range passively turns one artifact into a network — shared infrastructure, repeated selectors, the same operator behind different names — via the correlation graph and the cross-entity link engine.
Producing something actionable. Analysis that ends in a document nobody can use is wasted. Decide the control granularity feeds the case file, the detection rule, the block list or the referral — with sourcing attached so the recipient can verify it.

Case management (cases.php), watchlists, saved searches and scheduled reports mean the work persists between sessions and survives an analyst leaving the team.

How each sector uses IP Range / CIDR

The same entry is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The underlying artifacts are shared — the constraints, outputs and thresholds are not.

🎖 Military and defence

Working at prefix level is how defence networks express access control, geofencing and cyber terrain. A block is the granularity at which allow and deny policy is written on boundary devices, at which coalition partner space is permitted, and at which adversary hosting is characterised for J2 reporting. Prefix level analysis also supports resilience assessment, since a partner nation's critical services often sit inside a handful of blocks with single provider dependency. Constraints are operational and legal: block level controls affect every user in the range, proportionality reasoning must be documented where civilian networks are involved, and announced prefixes differ from allocated blocks in ways that make lazy blocking both over broad and ineffective.

🕵 National intelligence

National intelligence uses prefix level analysis to map organisational and national address holdings, identify address brokerage and leasing that obscures ownership, and detect hijacked space announced by unrelated networks. Blocks are the durable unit: individual addresses rotate, but the allocation and its holder persist for years, which makes prefix level tracking the right granularity for long running actor infrastructure. Registry and routing sources are open, supporting releasable reporting. Handling considerations arise mainly for residential and mobile ranges, where prefix level datasets can incidentally aggregate information about identifiable subscribers, triggering minimisation before any dissemination beyond the analytical team.

👮 Law enforcement

For law enforcement the block establishes which organisation holds the address space and therefore which legal person receives a preservation or production request. Sub allocation records naming a downstream customer frequently redirect process from a large hosting company to the actual reseller or end customer, saving weeks. Evidentially, capture registry records with query timestamps, since allocation data changes. Prefix level abuse density supports arguments that a provider was on notice of systemic criminal use, relevant to complicity and continuing liability theories. Recently transferred or leased blocks warrant scrutiny because address brokerage is a recurring feature of bulletproof hosting cases.

🔍 Private investigation and corporate security

Corporate security uses prefix analysis for access control design, fraud detection and third party risk. Knowing that a supplier's traffic originates from a leased block registered to a broker rather than the supplier itself is a genuine due diligence finding. Prefix level classification into datacentre, residential and mobile also underpins fraud rules distinguishing plausible customer traffic from automation. A private actor may use published registry and routing data freely but may not scan third party ranges, may not purchase unlawfully obtained subscriber data associated with residential blocks, and should document proportionality before recommending controls that would affect a client's customers.

📰 Journalism and OSINT media

Journalists use blocks to make ownership claims precise and verifiable: this range is registered to this company, was transferred on this date, and is announced by this network. Address brokerage and leasing stories are well supported by registry transfer records, which are published and citable. Verification requires distinguishing the allocated block from the announced prefix and stating which you are describing. Do not publish material implying that everyone using a residential block is associated with observed activity, since blocks contain uninvolved households. Give the registered holder and the announcing operator a genuine right of reply.

🌍 NGO, humanitarian and human rights

Human rights organisations use prefix level data to document national filtering, throttling and shutdowns, and to identify which networks and blocks were affected. Because measurement is aggregate rather than individual, it is comparatively safe to collect and publish without exposing people in country. Do no harm still applies: naming a specific small block used by a partner organisation can identify them, so aggregate to operator or country level in publications. Preserve raw registry and routing evidence under Berkeley Protocol practice for later accountability use, and avoid retaining any dataset that maps residential prefixes to identifiable households.

🎓 University and research

Researchers use prefixes as the standard unit for internet measurement, address space utilisation studies, geolocation accuracy evaluation and abuse concentration analysis. Aggregating to prefix rather than address is also the primary privacy control, since it removes the household level granularity that raises ethics concerns. Method must state the source of allocation data, the collector set for announcements, and the date, because both change continuously. Ethics review is normally straightforward for prefix aggregated work but becomes substantive if individual addresses in residential space are retained. Publish derived aggregates and analysis code, and cite registry delegation files by their dated version.

Playbook: working IP Range / CIDR end to end

A repeatable sequence, from the moment the requirement lands to the moment a product is delivered and the case is closed out. Each phase states what you are trying to establish, not merely what to click — the point is a defensible chain of reasoning, not a checklist.

Phase 1 — Determine what question the block answers

Decide whether you need the allocation boundary for identifying a legal holder, the announced prefix for routing and blocking, or the behavioural boundary for characterising a tenant. These are three different answers and conflating them is the most common error in prefix work. A good output is a stated purpose driving which boundary you will use. Stop when the purpose is written down and the required boundary type is named.

Phase 2 — Resolve the covering allocation

Query the responsible registry for the covering network object, recording the holder organisation, allocation or assignment date, country, status and abuse contact. Note whether the object is a direct allocation, a sub allocation or an end user assignment. A good output states the registered holder and the exact boundary of their allocation. Stop when the registry object is captured verbatim with a query timestamp.

Phase 3 — Resolve the announced prefix

Check public routing data for what is actually announced covering the address, including any more specific announcements, and record the origin AS and the collectors that observed it. Announced prefixes are frequently longer or shorter than allocations, and more specifics usually mark a distinct customer. A good output is the announced prefix set with origins and observation dates. Stop when you can state clearly where allocation and announcement differ.

Phase 4 — Check provenance and transfers

Review registry transfer statistics and delegation files for recent transfer, lease or reallocation of the block, and note whether the holder is a broker, a shell entity or an operating network. Recently transferred space is disproportionately represented in spam and bulletproof hosting. A good output is a provenance timeline for the block with dated transfer events. Stop when the acquisition history over the relevant period is established.

Phase 5 — Classify the range

Determine whether the block is datacentre, residential broadband, mobile, business access, carrier grade NAT, VPN or anonymiser space, using hosting classification datasets, reverse DNS conventions and registry status. This governs every inference and every control decision that follows. A good output is a stated classification with evidence and an explicit confidence level. Stop when the class is established or recorded as mixed, which is common for large blocks.

Phase 6 — Sweep passively for tenancy fingerprints

Query scan repositories across the whole block for certificates, banners, panel software and reverse DNS conventions, looking for artifacts repeated across many addresses. A single certificate common name across forty hosts identifies one tenant controlling the range. A good output is a fingerprint table showing how many addresses share each artifact. Stop when the dominant tenancy pattern is characterised.

Phase 7 — Measure abuse density

Count distinct malicious indicators inside the block over a defined window, normalise by usable address count, and compare against similar sized blocks in the same classification. Report both the raw count and the density with the window stated. A good output is a density figure with sources and a comparison baseline. Stop when you can distinguish dedicated abuse from incidental abuse with numbers rather than impression.

Phase 8 — Detect dark and hijacked space

Identify portions of the allocation that are not announced, then check whether any of that space is announced elsewhere by an unrelated AS, which indicates hijack or squatting. Compare against route objects and routing authorisations where available. A good output is a map of announced, unannounced and anomalously announced sub ranges. Stop when any anomalous announcement is documented with collector evidence and dates.

Phase 9 — Assess neighbour behaviour

Look at adjacent blocks from the same holder and the same announcing AS, since operators frequently distribute one tenant across several ranges. Consistent fingerprints across adjacent allocations extend the estate picture considerably. A good output is an extended estate boundary with the evidence linking each block. Stop when adjacent ranges are either linked with evidence or excluded.

Phase 10 — Choose the control granularity

If a control is warranted, select the narrowest prefix that captures the threat and estimate the legitimate traffic and user population inside it. Prefer host or behavioural controls where the block is shared. Document the proportionality assessment before implementation. A good output is a control recommendation with a written collateral impact estimate. Stop when the estimate exists; without it the decision is not defensible.

Phase 11 — Direct legal or abuse process correctly

Use the allocation holder and any sub allocation record to identify the right recipient for preservation, production or abuse notification, and check whether the announcing AS differs from the registered holder, which changes who actually operates the space. A good output is a named recipient with jurisdiction and contact route. Stop when the recipient is identified and the request is served or the abuse report is lodged.

Phase 12 — Monitor and review

Set alerts on transfer events, changes in announced specificity, new origin ASNs for the block and shifts in abuse density. Prefixes are stable enough that changes are meaningful signals rather than noise. A good output is a monitoring rule set plus a dated case record preserving registry and routing evidence. Stop when monitoring is live and retention for any subscriber adjacent data is scheduled.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

Source register: what to collect from, and how

Sources are listed with their access model so you can plan around cost and licensing before you build a dependency on them. Open means no account required; registration means a free account or API key; licensed means paid or institutional access. Always confirm current terms — licensing changes, and a source that was free for research may not be free for commercial or evidential use.

Source	Access	What it gives you	How it is used here
RIPE NCC database and RDAP	Open	Authoritative network, route and organisation objects for the European, Middle East and Central Asian service region.	Establishes allocation boundary, holder, assignment date and abuse contact for blocks in the RIPE region.
ARIN Whois and RDAP	Open	North American registry records including network reallocations and reassignments that name downstream customers.	Identifies the true downstream holder of a sub allocated range, which frequently redirects legal process.
APNIC Whois and RDAP	Open	Asia Pacific registry records covering allocation, assignment, maintainer objects and abuse contacts per range.	Holder and jurisdiction identification for Asia Pacific blocks, where reseller layering is common.
LACNIC registry services	Open	Registry records for Latin America and the Caribbean covering allocations, assignments and organisational contacts.	Establishes accountable holder and abuse route for blocks allocated in the LACNIC region.
AFRINIC registry services	Open	Registry records for the African region including allocation, assignment and transfer history for address space.	Holder identification for African blocks, a region with documented address space governance disputes.
NRO delegated statistics and transfer files	Open	Daily published files listing every allocation and assignment by registry with country, date and status, plus inter registry transfer logs.	Bulk provenance analysis showing when a block was allocated or transferred and between which parties.
RIPEstat	Open	Aggregated routing, registry, geolocation, visibility and abuse contact data queryable by prefix with historic views.	Fastest route to announced prefix, origin AS, visibility and abuse contact for any block.
bgp.tools	Open	Prefix and AS relationship data with more specific announcement detail and per collector visibility information.	Distinguishes the allocated block from what is actually announced, including more specifics marking distinct customers.
Censys	Registration	Full internet scan dataset queryable by network range returning host, service and certificate records with historic snapshots.	Passive sweep of an entire range for shared certificates and banners identifying a single tenant.
Shodan	Registration	Scan repository supporting network range queries with banner, product, version and certificate detail per host.	Characterises what the block runs and finds repeated deployment patterns across many addresses.
Spamhaus DROP and EDROP lists	Open	Netblocks assessed as controlled by criminal operations or hijacked, published for direct use in routing and firewall policy.	External corroboration that a block is systemically hostile rather than incidentally hosting abuse.
IPinfo	Registration	Commercial datasets classifying ranges by hosting type, carrier, company and anonymiser status with bulk download options.	Rapid classification of a block as datacentre, residential, mobile or anonymiser for triage and control decisions.
MaxMind GeoIP2 and connection type datasets	Licensed	Prefix level geolocation, autonomous system, connection type and anonymiser classification with documented accuracy statements.	Baseline classification and geolocation aggregation at prefix level with citable accuracy caveats.
Team Cymru bogon reference	Open	Lists of unallocated and reserved address space that should not appear in the global routing table.	Identifies announcements of space that is not legitimately allocated, a strong hijack indicator.
IANA address space registries	Open	Authoritative record of which registry administers each large block and which ranges are reserved for special purposes.	Determines the responsible registry and excludes reserved space before any enrichment work begins.
Rapid7 Open Data scan archives	Registration	Historical internet wide scan datasets covering common services across the routable address space over many years.	Retrospective analysis of what a block was running at a past date when current scan data is insufficient.

Prefer sources that publish a methodology and a revision history. A dataset that changes silently is a liability in any product that has to survive challenge.

Tooling

Tools commonly used against IP Range / CIDR. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

ipcalc and sipcalc — Compute prefix boundaries, host counts, network and broadcast addresses for IPv4 and IPv6. Limitation: purely arithmetic with no registry or routing awareness.
netaddr and ipaddress libraries — Programmatic prefix manipulation, aggregation, supernetting and containment testing. Limitation: correctness depends on the analyst choosing the right boundary.
whois with registry specific query flags — Retrieves allocation objects including sub allocation and route objects from the responsible registry. Limitation: sub allocation records are commonly stale or missing entirely.
Censys and Shodan network range search — Sweep an entire range for services and certificates without sending any traffic yourself. Limitation: snapshot data lagging live state by days to weeks.
pyasn and bulk ASN mapping — Offline or bulk resolution of addresses to prefix and origin AS for large log enrichment. Limitation: requires periodic dataset refresh to stay accurate.
aggregate6 and prefix merge tooling — Collapse long indicator lists into minimal prefix sets for firewall and routing policy. Limitation: aggressive aggregation silently widens the blast radius of a block.
MISP with network range attributes — Stores and correlates prefix level indicators so clustering survives address rotation within a range. Limitation: analysts must record the boundary rationale, which is rarely done.
RIPE Atlas — Distributed measurement network for testing reachability and path behaviour toward a prefix from many vantage points. Limitation: probe coverage is uneven by region.
Firewall and cloud security group policy tooling — Applies prefix level allow and deny rules and reports on rule coverage and hit counts. Limitation: rule sprawl means old block decisions persist unreviewed for years.

AI skills and automation in detail

These are deterministic jobs with defined inputs and outputs, not open-ended prompting. Each is idempotent and cursor-based: interrupt one and it resumes where it stopped rather than duplicating work or losing progress.

Enrichment Runner — Walks the indicator set through a chosen provider in time-boxed, cursor-based batches that resume rather than restart.
Enrichment → Local — Materialises enrichment into the local store so dashboards render from your own database instead of a live third-party call.
Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
Resolve Everything — Batch-resolves ASN, country, org and netblock for every IP from local reference datasets — no API calls, so it runs at millions of rows and works offline.
Threat Hunt — Runs saved hypotheses against the corpus and surfaces what matches, with the query preserved as a versioned artifact.
Summarise (Copilot) — Produces a narrative summary beside the underlying records. It explains; it never creates indicators or assigns attribution.
Generate Report — Assembles a sourced product from the current case or query, with provenance attached to each element.

A note on the boundary: the only skill that involves a language model is Summarise (Copilot), and it writes prose about records that already exist. Nothing else on this list involves generation of any kind. No indicator, relationship or attribution in the platform originates from a model. See the full skill list.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

Always state which boundary you are describing. The allocated block, the announced prefix and the behavioural tenancy boundary rarely coincide, and a control written against the wrong one either overreaches or misses entirely.
Normalise abuse counts by usable address count and by classification. Ten malicious hosts in a small block registered to a shell company is a very different finding from ten in a large national provider allocation.
Address brokerage is now a mainstream market, so a registered holder may be a broker with no operational relationship to the tenant. Check transfer records before naming a holder as responsible for content.
For IPv6, abandon address counting entirely. A single residential customer routinely holds a large prefix, so per address metrics are meaningless and analysis must operate at customer prefix granularity.
Unannounced portions of an allocation are worth checking against the global table. Space that appears elsewhere under an unrelated origin is one of the cleaner hijack indicators available from public data.
The strongest evidence that a block is dedicated to one operator is a shared artifact the operator chose: an identical self signed certificate, an unusual panel version, or a consistent reverse DNS naming scheme across the range.
Write down the collateral impact estimate before recommending a block. If you cannot estimate how many legitimate users sit inside the prefix, you are not ready to recommend blocking it.
Registry data ages badly at the sub allocation level. Treat customer assignment records as a lead requiring corroboration from routing, reverse DNS and scan data rather than as current fact.

Measuring whether it is working

Capability claims should be falsifiable. These are the measures that show whether work on IP Range / CIDR is producing anything, and they are worth baselining before you change process or tooling.

Proportion of block level controls with a documented proportionality assessment and collateral impact estimate, sampled from the firewall change record.
False positive rate of prefix based blocking measured as legitimate traffic denied, tracked per rule to trigger review of over broad entries.
Median age of active deny rules, used to force periodic review since stale block decisions accumulate silently for years.
Number of investigations in which prefix level clustering identified additional actor infrastructure beyond the triggering address.
Accuracy of hosting classification for prefixes used in fraud rules, validated against known good customer traffic samples.
Time from a hijack or anomalous announcement appearing in routing data to detection and notification of the legitimate holder.
Share of prefix findings where the accountable holder was confirmed through both registry and routing evidence rather than registry alone.

Beware of measuring volume alone. Indicator counts and report counts rise easily and say little; time-to-attribution, proportion of findings that survive review, and how often a product changed a decision say a great deal.

Common pitfalls

The announced prefix is not the allocated block, so blocking what BGP shows can cover far more or far less than the actor controls.
Cloud provider ranges are shared by millions of tenants, and blocking them will break legitimate services long before it inconveniences an attacker.
Leased address space is common, so the registered holder may be a broker with no knowledge of or control over the tenant.
Registry data goes stale, and sub-allocation records are often years out of date or missing entirely for smaller customers.
IPv6 makes per-address counting meaningless because one customer may hold billions of addresses in a routine allocation.
Geofencing by CIDR is easily defeated by proxies and misses in-country attackers, while reliably blocking legitimate travellers and partners.

Legal and ethical considerations

Allocation records are published for operational transparency and generally raise limited privacy issues, though small allocations can name individuals. The greater responsibility is proportionality: recommending a block-level control affects every user of that range, so document the evidence and the assessed collateral impact. Retain scan and reputation data with defined lifetimes, since block-level datasets can incidentally aggregate information about identifiable subscribers, particularly in residential and mobile ranges.

Data integrity: no fabrication, no drift, no hallucination

Intelligence that cannot be traced back to a source is not intelligence, it is assertion. Everything in this entry — and everything in the platform behind it — is built on a small number of non-negotiable rules.

Provenance on every record

Every indicator carries the source that supplied it, a first-seen and last-seen timestamp, and a sighting count. Where several feeds report the same artifact, each contribution is recorded separately rather than collapsed, so you can see whether a finding rests on one source or twelve. Source attribution travels with the data into every export, so a recipient can audit a claim without asking you for the working.

Nothing is invented to fill a gap

If the platform has no data for IP Range / CIDR, it says so. Empty is displayed as empty — never padded with plausible-looking placeholder values, sample records or illustrative examples that a reader might mistake for observations. A dashboard with no rows is a true statement about collection coverage, and it is treated as a gap to close, not a blemish to hide.

Scoring is deterministic and reproducible

Threat scores, reputation grades and risk tiers are computed from stated inputs with fixed weights, not estimated. The same inputs always produce the same output, and the formula is visible rather than a black box. Aggregates are cached with an explicit time-to-live so a figure on screen is never silently stale — and when a heavy query exceeds its time budget the platform serves the last known-good value and labels it, rather than inventing a fresh number or hanging.

Where AI is used, and where it is not

Language models summarise and explain. They do not create indicators, assign attribution or manufacture relationships. No IP address, wallet, hash or identity in the platform originates from a model — every one is ingested from a named feed, resolved from a reference dataset, or entered by an analyst with a source recorded. Copilot output is presented as narrative alongside the underlying records, never in place of them, so a reader can always check the summary against the evidence.

Guarding against drift

Enrichment is additive and timestamped rather than overwriting. Reference data — sanctions lists, allocations, taxonomies — is re-synchronised from the authority on a schedule instead of being edited in place, so local copies cannot quietly diverge from the source of truth. Attribution is recorded with a confidence level and the reporting it rests on, and inferred relationships are labelled as inferred. When a source retracts or corrects, the correction propagates rather than leaving a stale assertion behind.

What this means for you

You can put a finding from this platform in front of a regulator, a court, a board or a partner agency and show where each element came from. That is the standard the tooling is built to — because in this work, being confidently wrong is more damaging than being usefully uncertain.

By the numbers

The taxonomy this entry belongs to is not a marketing list — it is the actual structure of the platform: 52 mission domains, 52 intelligence disciplines and 65 data points, each with a live dashboard behind it. Supporting that: 18 indicator types, 14 playbooks, 16 AI skills, 18 export formats and a 30-step automated pipeline.

This particular entry connects directly to 6 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

Should I block the allocated block or the announced prefix?

Neither by default. Determine the behavioural boundary first: which addresses actually exhibit the threat. Then choose the narrowest prefix that contains them, which is often a very small range inside a much larger allocation. Blocking the full allocation punishes every other customer of the holder, and blocking the announced prefix may cover space the actor does not control at all. If the entire allocation belongs to a small entity whose whole business is the abuse, blocking the allocation is defensible, but write down why and estimate who else is affected.

How do I handle IPv6 at prefix level?

Stop counting addresses and start counting prefixes. A residential customer typically receives a large delegated prefix, so a single household can appear as billions of unique addresses, which destroys any per address rate limiting, reputation or counting logic. Aggregate to the subnet level for host identity within a network and to the customer delegation level for subscriber identity, then apply your controls and metrics at that granularity. Check the provider's documented assignment policy where available, since assignment size varies and assuming a fixed size is frequently wrong.

What does a recent block transfer tell me?

That the current holder acquired the space rather than receiving it from a registry allocation, which is now extremely common as IPv4 scarcity has created an active market. On its own it is neutral: legitimate businesses buy address space constantly. It becomes significant when combined with other signals, such as a shell holder, an immediate spike in abuse from the range, announcement by an AS with no relationship to the buyer, or a pattern of the same broker supplying multiple ranges that subsequently host abuse. Always check the transfer date against the abuse onset.

Why does the registry say one thing and routing another?

Because they describe different facts. The registry records who holds the space administratively; routing records who is announcing it right now and how it is subdivided. Divergence is normal: providers announce aggregates covering many customer allocations, customers announce more specifics out of provider space, and leased space is announced by the lessee. Real problems appear when the announcing AS has no plausible relationship to the holder, when the announcement is not covered by any route object or authorisation, and when the legitimate holder is announcing nothing at all.

Can I geolocate at block level more reliably than per address?

Somewhat, and it is the correct granularity to work at. Geolocation datasets are derived largely from registry country codes, provider published feeds and latency inference, all of which operate on ranges rather than individual addresses. Aggregating to prefix removes the false precision of an address level coordinate. It does not fix the underlying problems: a multinational provider may register a block in one country and deploy it in another, anycast breaks location entirely, and mobile and satellite ranges are frequently wrong. State the dataset and version, and report country rather than city unless corroborated.

How do I detect that a whole range is dedicated to one actor?

Look for artifacts the operator chose rather than artifacts the provider assigned. Identical self signed certificates, the same unusual admin panel and version, matching TLS server fingerprints, a consistent non default reverse DNS naming scheme, and synchronised deployment times across the range all indicate a single tenant. Corroborate with registry sub allocation records naming a customer and with abuse density normalised by size. A shared default hosting banner or a common cloud provider certificate proves nothing, because those belong to the provider, not the tenant.

Are prefix level datasets personal data?

Generally less so than address level data, which is precisely why aggregation to prefix is a recommended privacy control in measurement work. However, residential and mobile ranges can still allow inference about identifiable households when combined with activity data, particularly with small allocations or static assignments. Treat datasets that link residential prefixes to behaviour as carrying real privacy risk, apply retention limits, restrict access, and prefer publishing aggregates at operator or country level. Purely administrative allocation records for corporate blocks raise minimal issues beyond named individual contacts in small operator records.

Standards, frameworks and further reading

Work that references a recognised framework is easier to defend, easier to hand over, and easier for a partner to consume:

RFC 4632, defining Classless Inter-Domain Routing address assignment and aggregation as the current internet allocation architecture.
RFC 3849, RFC 5737 and RFC 6598, reserving documentation, example and shared carrier grade NAT address space that must be excluded from analysis.
Regional Internet Registry address policy manuals, governing allocation, assignment, transfer and registration accuracy across all five registries.
NRO extended delegated statistics format, the published daily record of every allocation and assignment used for provenance analysis.
RFC 6480 and RFC 6811, defining RPKI and origin validation used to test whether a prefix announcement is authorised.
GDPR minimisation and retention principles as applied to residential and mobile prefix datasets that can support inference about households.
ISO/IEC 27001 Annex A network security controls, requiring documented rationale for network segregation and filtering decisions.
MANRS filtering commitments, setting operator expectations for prefix filtering and preventing propagation of unauthorised announcements.

References

Primary sources and authoritative references for this entry. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

Classless Inter-Domain Routing address assignment and aggregation plan — IETF. The specification defining CIDR notation, allocation and route aggregation.
Delegated statistics — Number Resource Organization. Daily published record of address and AS allocations and assignments across all five registries.
RIPE NCC database documentation — RIPE NCC. Reference for network, route and organisation objects and their maintenance obligations.
ARIN Whois and RDAP services — ARIN. Registry of record for North American address allocations, reallocations and reassignments.
DROP and EDROP netblock lists — Spamhaus. Published ranges assessed as criminally controlled or hijacked, intended for direct policy use.
RIPEstat data platform — RIPE NCC. Open interface aggregating registry, routing, visibility and geolocation data by prefix.
IPv4 and IPv6 address space registries — IANA. Authoritative record of registry administration and special purpose address reservations.
Bogon reference and unallocated space guidance — Team Cymru. Reference lists of address space that should never appear in the global routing table.
GeoIP2 accuracy and connection type documentation — MaxMind. Published accuracy statements and classification definitions for prefix level geolocation data.
Mutually Agreed Norms for Routing Security — Internet Society. Operator commitments on prefix filtering and coordination that constrain unauthorised announcements.

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this entry: aggregates indicators to block level, scoring abuse density and ownership so controls are applied at the right granularity. Explore the platform, or browse the rest of the library by following any tag above.