IVRE: Self-Hosted Network Reconnaissance and Intelligence Database Framework

Network scans produce disposable data. You scan, review, note a few things, and move on. Next scan, you start over.

IVRE changes that. It stores scan data, letting you query it. You can ask which hosts appeared or disappeared. You can find areas running outdated software.

Scan output becomes an intelligence database. You can interrogate it. No more starting over.

IVRE sits on top of your existing scanning workflow. Nmap, for example, still does the heavy lifting. IVRE then takes that output and makes it useful over time.

You query by host, by port, by time. What was here last month? What's running OpenSSH 7.4? The answers come from your accumulated scan history.

That's the power of persistence. Your scans aren't just one-off assessments. They're a data source you can mine.

What IVRE Is

IVRE is network reconnaissance, not a scanner. It processes data from other tools, Nmap, Masscan, ZMap for active scanning. It also takes passive traffic data from Bro/Zeek, p0f, Argus, Netflow. The data is normalized and stored in a MongoDB database.

The goal of IVRE is large-scale, continuous network mapping, not one-off scans. A single Nmap run provides a snapshot, while ten runs give you a history. You can query changes over time, find persistent anomalies, services that appear and disappear, and hosts that vanish.

If you scan regularly and ignore old data, IVRE may be worth a look.

Architecture: Scanners, Ingestors, and the Database Layer

Introduction to IVRE's Ingestion Pipeline

IVRE interfaces with existing tools through its ingestion pipeline. For active scans, ivre scan2db handles Nmap XML and Masscan results. It normalizes the data into IVRE's schema, and writes it to MongoDB.

The parsers manage quirks in scanner output, such as service detection, script output, and OS fingerprinting. They map these to consistent database fields. You query them uniformly, no matter the scanner.

Handling Active and Passive Reconnaissance Data

Active scan data comes from ivre scan2db. Passive data comes from ivre passiverecon, which processes logs from Zeek, p0f, Argus, and Netflow.

Passive data reflects observed network behavior. Hosts appear if they initiate connections. Services show up if other hosts talk to them.

MongoDB Backend

The MongoDB backend makes stored data useful. It supports complex queries to find hosts with a specific HTTP title, certificates with a given organizational unit. It handles compound queries across scan history.

You can't do this with XML files or grep. MongoDB lets you dig deep into accumulated data.

Web UI and Query Interface

IVRE's web interface allows you to browse and filter scan data. The interface is designed for analysts, not presentations. You can filter by IP range, open ports, service, banner text, OS fingerprint, cert subject fields, hostname — any combination of these across all scans.

The diff and timeline views show changes between scans, including new hosts, opened or closed ports, and changed banners. These views help with constant network monitoring, answering the question of what changed without manual scan comparisons. For example, if a host appears with an open management port one week, it will show up as a signal in IVRE's diff.

The CLI tools, ivre db2view and ivre ipinfo, provide scripted access to the same database. If the web UI is not suitable, or if results need to feed into another pipeline, the CLI handles it. The CLI and web UI both query the same database, allowing you to choose your preferred interface. You get the same data either way.

IVRE vs Shodan: The Self-Hosted Case

Shodan operates on the public internet, scanning, indexing, and allowing queries through an API. When it finds something, it stores the data on its own servers. Your data stays on their servers.

IVRE works differently. It scans the networks you can see, including your internal networks, VPCs, and air-gapped networks. Scans occur on your schedule, and the data is stored in your MongoDB instance. The key difference is that you control the data.

Shodan has limitations, such as missing internal networks, being unable to see behind security groups, and not scanning on your timetable. IVRE fills those gaps. You own the data and decide how long it stays.

This matters to some organizations, including regulated industries, classified environments, and places where network maps are sensitive. For these cases, hosted services are not an option. IVRE's self-hosted model works, and the data stays with you.

Operational Use Cases

Asset Discovery and Continuous Inventory

Scan an IP range, weekly or daily, at the frequency that suits your operations tempo. Feed each scan into IVRE. The diff view shows changes, with new devices appearing and decommissioned hosts lingering. You can also identify unauthorized services through port and banner changes, which may not be visible in individual scan files, and avoid the burden of too much manual work.

Benefits of Query Model

IVRE's query model aids in attack surface management. You can find all hosts running a specific software version, services with default configurations, certificates nearing expiration, and exposed management ports in the wrong network range. These queries are systematic, eliminating the need for custom scripts.

Adding Passive Network Intelligence

IVRE also ingests Zeek logs from a network tap or span port, alongside active scan data. This provides a behavioral picture of what's communicating with what, what external destinations internal hosts access, and what's actually used versus just open. Some anomalous hosts may not show up in active scans, but they generate traffic. Passive ingestion is the only way to detect them, providing

Deployment Considerations and Limitations

Introduction to IVRE and MongoDB

IVRE needs a MongoDB instance to run; the database handles scan results. Sizing it right, backing it up, and keeping indices in check add operational work. For a team scanning continuously and keeping data long-term, MongoDB's overhead makes sense, as it supports ongoing scanning and data retention. For solo analysts doing spot checks, it might not. MongoDB handles scan results, and its requirements include

IVRE and Scanner Integration

IVRE assumes you're already using Nmap and Masscan. It's best for teams with existing scanning workflows looking to process output more efficiently. If you're setting up scanning from scratch, learn the scanners first, then add IVRE when you have enough data to see the database's value. Nmap, Masscan are prerequisites.

IVRE's Web UI

The web UI gets the job done for analysts; it queries and visualizes data. However, it's not suitable for non-technical reports, as the output isn't polished enough. You'll need to export results and format them externally for stakeholder reports, as IVRE doesn't handle native formatting.

Verdict

IVRE is for teams that scan their network regularly but don't get much from the results. You run scans. You get data. You don't know what to do with it. IVRE changes that. It keeps all your scan data in a database, turning what would be isolated snapshots into an ongoing view of your network.

Repeated scans are about seeing changes over time. IVRE helps you do that. It provides a history of your network. You can query it like Shodan, but with your own data.

IVRE does more than active scanning. It can ingest Zeek and Netflow data. You can analyze network behavior without extra hardware. If you already capture network traffic, IVRE gives you more use out of it. You don't need a pricey SIEM or network analyzer.

To use IVRE, you should know MongoDB and how to scan. If you do, IVRE adds a lot. If not, set those up first. MongoDB knowledge, scanning skills are required.

IVRE suits teams that continuously scan their network, need a history of scans, see changes over time, and query that data like Shodan — but for their own infrastructure. The website is ivre.rocks and GitHub is ivre/ivre.