ivre: Self-Hosted Network Recon Framework

ivre gives you Shodan-style querying over scan data you own. Here's how it fits an analyst's workflow and how to stand it up in under ten minutes.

ivre: Self-Hosted Network Recon Framework

If your threat model includes data-sharing agreements, API rate limits, or a client NDA that makes pushing scan data to a third-party platform untenable, commercial internet-scanning services stop being options. ivre fills that gap: it wraps Nmap, Masscan, and Zeek output into a queryable database you own, on infrastructure you control, with no per-query billing.

The project lives at https://github.com/ivre/ivre with over 4,000 stars, and the official documentation at https://doc.ivre.rocks is genuinely good — which is not something you can say about most tools in this space.

What ivre Actually Does

ivre (Instrument de veille sur les réseaux extérieurs) is not a scanner. It is a data layer. You bring the scanners; ivre normalises, stores, and indexes their output so you can query across it rather than grepping XML.

The four capabilities that matter in practice:

• Active scan ingestion: ivre parses Nmap and Masscan XML into MongoDB. One command, structured results, queryable by port, banner, OS fingerprint, certificate, or any combination.
• Passive traffic analysis: Via Zeek and p0f, ivre can index DNS resolutions, HTTP headers, and TLS certificate chains observed on a sensor you run — building a private passive-DNS dataset alongside your active scan data.
• EASM foundation: Combine continuous active scans of your own IP ranges with passive observations and you have the skeleton of a self-hosted external attack surface management platform.
• ProjectDiscovery tool integration: ivre can ingest Nuclei and httpx output, letting you correlate vulnerability findings with scan metadata in a single query interface.

The default backend is MongoDB. PostgreSQL is supported for certain sub-databases. The web UI is serviceable for ad-hoc investigation; the CLI is where the real flexibility is.

Where ivre Fits in a Workflow

The data flow is straightforward:

Scanners (Nmap / Masscan / Zeek / p0f)
        ↓
  ivre ingest scripts
        ↓
   MongoDB / PostgreSQL
        ↓
  ivre CLI / Web UI / API
        ↓
  SIEM / Dashboards / Reports

Without ivre, most teams push scan XML into spreadsheets or pay for a platform running its own scanning infrastructure. ivre occupies the middle: you control the scanners, the data, the retention policy, and the query interface.

The use cases where that control actually matters:

1. Internal network cartography — continuous scanning of RFC-1918 or DMZ ranges with a longitudinal record of what is exposed and when it changed.
2. Passive DNS for incident response — Zeek on a mirror port feeds ivre, giving you a local alternative to commercial passive-DNS services for the networks you actually care about.
3. Red team data management — ingest Nmap results from multiple phases of an engagement and query across the full dataset rather than juggling per-phase XML files.
4. Threat intel enrichment — a private dataset of observed IPs, banners, and certificates that supplements public feeds without exfiltrating client data.

ivre vs. the Alternatives

Shodan / Censys / ZoomEye

These services maintain their own global scanning infrastructure and expose results through paid API tiers. They are the right tool for external intelligence on arbitrary IP space you do not control. The trade-offs:

The rule of thumb: commercial services for breadth and discovery of unknown infrastructure; ivre for depth, longitudinal tracking, and any scenario where data sovereignty is non-negotiable.

GreyNoise

GreyNoise classifies internet background noise — identifying mass-scanner IPs and separating them from targeted traffic in your logs. ivre’s passive capabilities can complement this, but ivre makes no attempt to classify global scanner activity across millions of sensors. If GreyNoise’s context enrichment is the requirement, ivre does not replace it. If you want to run your own sensor and index passive observations for a specific network segment, ivre is the better fit.

OpenVAS / Nuclei

Vulnerability scanners, not recon frameworks. ivre can consume Nuclei output as part of a broader picture but does not duplicate detection logic. Treat them as complementary.

Spiderfoot / Maltego

These excel at OSINT pivoting across public sources. ivre is oriented toward network-level data you collect yourself. Many analysts run both for investigations that blend public OSINT with private scan data.

Quick-Start: Up in Under Ten Minutes

The following is based on the official ivre installation documentation at https://doc.ivre.rocks/en/latest/install/. Requirements: Docker and Docker Compose on Linux or macOS.

Step 1 — Pull the Docker Compose environment

git clone https://github.com/ivre/ivre.git
cd ivre/docker
docker compose up -d

The docker/ directory ships compose definitions for MongoDB, the ivre web front-end, and the tools container. First pull takes two to three minutes on a typical connection.

Step 2 — Initialise the databases

docker compose exec ivre ivre ipinfo --init
docker compose exec ivre ivre scancli --init
docker compose exec ivre ivre view --init

ipinfo stores IP metadata. scancli (the nmap sub-database) stores active scan results. view is the aggregated layer the web UI queries. Each is a separate collection; init them separately.

Step 3 — Scan and ingest

Scan a host you are authorised to test:

nmap -sV -oX /tmp/test_scan.xml 127.0.0.1

Feed the XML into ivre:

docker compose exec ivre ivre scan2db -r /tmp/test_scan.xml

The -r flag marks the file as a completed Nmap result and inserts it into the scan database.

Step 4 — Query from the CLI

docker compose exec ivre ivre scancli --count
docker compose exec ivre ivre scancli --json

The first returns host count. The second dumps all records as JSON — pipe it into jq for anything non-trivial.

Step 5 — Open the web UI

Navigate to http://localhost:80. The UI gives you a filterable view of all ingested scan data: port/service breakdowns, OS fingerprints, certificate details. It is adequate for quick review; for anything systematic, the CLI is faster.

On a standard laptop with a warm Docker cache, steps 1–5 take about seven minutes.

Passive DNS in Five More Minutes

This is where ivre separates itself from pure active-scan tools. In the Docker environment:

docker compose exec ivre ivre passiverecon2db --init

Feed a Zeek log or a PCAP converted to Zeek logs into passiverecon2db and you start building a historical record of observed DNS resolutions, HTTP headers, and TLS certificate chains from your own sensor — queryable alongside your active scan data. The Zeek log formats ivre consumes are documented at https://docs.zeek.org.

The combination of active and passive data in a single query interface is genuinely useful for incident response: you can ask whether a given IP appeared in passive DNS observations before or after it showed up in a scan, without pivoting between tools.

Operational Considerations

Storage: MongoDB grows fast when indexing full Nmap XML across large scan ranges. Use --no-screenshots in production to block binary data ingestion. Monitor collection sizes.

Authentication: The default Docker Compose setup exposes the web UI without authentication. Before binding to anything other than loopback, read the authentication and reverse-proxy section of the official docs.

Performance at scale: For Class B ranges or larger, the ivre documentation covers Masscan integration with rate-limiting parameters and recommends dedicated storage for MongoDB. Do not skip this for production deployments.

Legality: ivre does not scan anything on its own. Nmap, Masscan, and Zeek do. Scanning infrastructure you do not own without authorisation is illegal in most jurisdictions. The framework is neutral; your targeting decisions are not.

Assessment

ivre will not replace Shodan or Censys for external coverage of arbitrary IP space — those services scan the whole internet continuously and you are not going to replicate that. What ivre does well is depth, control, and longitudinal tracking on infrastructure you actually care about. The multi-sub-database architecture has a learning curve, and you need familiarity with Nmap, Zeek, and MongoDB to get full value from it. The Docker-based setup handles the initial barrier; the ProjectDiscovery output formats documentation and Nmap XML output reference are worth reading before wiring up a production pipeline.

Start with the Docker quick-start against your own lab range. The passive DNS init and a single PCAP replay will tell you within an hour whether the framework fits your workflow.