ivre is a self-hosted network recon framework that aggregates passive Zeek and active Nmap scan data into queryable databases for authorized assessment and defensive monitoring workflows.
| Tool | ivre/ivre — network recon framework combining passive and active scan data into self-hosted, fully-controlled databases |
| Category | Network reconnaissance and external attack surface management (EASM) |
| Primary Use | Centralizing Nmap, Masscan, ZGrab2 and Zeek results into a searchable repository for network cartography during authorized engagements |
| Safe Use | For authorized security assessments, internal asset inventory, lab research and defensive attack-surface monitoring of networks you own or are contracted to test |
| Telemetry Note | Active scans launched via ivre+Nmap/Masscan generate ordinary scan traffic visible to IDS; passive ingestion via Zeek leaves traces only in sensor logs, not on targets |
ivre — the French acronym for Instrument de veille sur les réseaux extérieurs, playfully mirrored in English as DRUNK (Dynamic Recon of UNKnown networks) — is a mature network reconnaissance framework designed to let a team build its own, self-hosted and fully-controlled alternative to commercial scanning platforms. With roughly 4100 GitHub stars, a GPL-3.0 license, and a Python codebase dating back to 2011 per the project's own citation block, it is one of the longer-lived open-source projects in the recon space, and the README's tone suggests a maintainer who cares about documentation as much as code. The framing throughout is deliberately defensive-adjacent: ivre is positioned as an instrument de veille — a surveillance or watch instrument — over external networks, which maps naturally onto authorized asset inventory and attack surface management use cases.
What ivre actually does is solve the unglamorous but critical problem of scan data persistence and correlation. Anyone who has run more than a handful of Nmap scans knows the pain of XML files scattered across directories, results that cannot be diffed over time, and discoveries that exist only in a terminal scrollback buffer. ivre ingests output from a wide set of active scanners — Nmap, Masscan, ZGrab2, ZDNS, Nuclei, httpx, dnsx, tlsx, and Dismap are all named in the README — normalizes it, and stores it in a database you control. The result is a queryable historical record of what your network, or a client's authorized scope, looked like at any point in time.
The passive side of the house is equally well developed, and arguably more interesting from a defender's perspective. ivre can consume telemetry from Zeek (the sensor formerly known as Bro), Argus, Nfdump, p0f, and even airodump-ng for 802.11 captures. This means a SOC can feed it straight off a monitoring tap and build network cartography without sending a single packet at the targets — pure observation of traffic that already exists. The topic list on the repository reinforces this dual identity, tagging both network-recon and external-attack-surface-management, along with osint and the specific nmap-parser and nmap-results-analyse labels.
Storage backends are a point of visible engineering investment. The repository's continuous integration badges show dedicated test workflows for MongoDB, Elasticsearch, PostgreSQL, and a separate Maxmind workflow, which implies first-class support for geolocation enrichment via MaxMind databases and validated compatibility across multiple database engines rather than a single hardcoded choice. There is also a linting workflow, a Read the Docs documentation pipeline hosted at doc.ivre.rocks, and published artifacts on both PyPI and Docker Hub (ivre/web), so deployment can go whichever way your infrastructure prefers.
The most contemporary feature documented in the README is an MCP (Model Context Protocol) server that exposes the ivre database to LLM agents. Installing the optional extra with pip install 'ivre[mcp]' and launching ivre mcp-server makes the recon corpus queryable by agent clients including Claude Code, Claude Desktop, Cursor, OpenCode, VS Code, Windsurf, and JetBrains IDEs, per the referenced doc/usage/mcp-server.rst. There is also an extension point documented in doc/dev/mcp-plugins.rst for adding custom tools to the server. This is a notable architectural bet: rather than bolting an AI assistant onto the web UI, the project exposes the data layer itself, letting an analyst's agent run structured queries against months of accumulated scan history.
Interaction happens at three levels, and the README is explicit about all of them. CLI tools accept a --help flag on most commands; Python users can call help(ivre.module) against the importable sub-modules, which confirms ivre is designed as a library as well as a toolchain; and the web interface ships with a HELP button plus a /doc/ path that serves the rendered documentation locally. There is a screenshot gallery and a quick video introduction linked from the README, and the maintainers offer access to a demonstration instance on request — a sensible way to evaluate the UI before committing a database and scanner infrastructure to it.
The web interface is clearly a first-class deliverable rather than an afterthought; the Docker pull badge for ivre/web and the dedicated screenshot gallery both point to it. For a team doing recurring authorized assessments or continuous external attack surface review, this matters: the value of a recon database compounds only if non-scanner operators — managers, clients, junior analysts — can actually explore it. The demo instance lowers the adoption barrier considerably, and the Gitter channel plus a dev@ivre.rocks contact address give two support paths alongside GitHub issues.
Operational discipline within ivre follows the standard pattern for this class of tool: a scanner runs with its own tooling (Nmap for thorough sweeps, Masscan for breadth, the projectdiscovery suite for protocol-specific probing), and ivre parses, uploads, and indexes the results. Because the framework is storage and retrieval rather than an exploitation engine, its footprint on targets is exactly the footprint of whichever scanners you configure — a useful property for keeping authorized engagements inside documented scope, since every packet sent is attributable to a scanner you explicitly invoked.
From a telemetry standpoint, defenders should understand the two modes leave very different traces. Active workflows produce ordinary Nmap/Masscan traffic that any IDS will flag as scanning; passive workflows built on Zeek or Argus sensors emit nothing toward the observed network at all, which is precisely why the passive mode is attractive for internal visibility and why blue teams can use ivre to inventory what their own sensors have already seen. As an IOC, ivre itself is nearly invisible — it is a local Python application talking to its own database.
The project's longevity is its own argument: the citation block spans 2011–2026, the repository participates in hacktoberfest, and the maintainers actively solicit scan results and capture files as sample contributions, plus offers of servers to run scans — evidence of an ongoing effort to grow the corpus of tested parser inputs. For an authorized assessment team or a SOC wanting self-hosted network cartography without shipping scan data to a SaaS vendor, ivre remains the reference open-source answer, and the new MCP server suggests it intends to stay relevant in an agent-assisted workflow.
ivre/ivre.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.