How it works

How DENIS works: one program, out of band

DENIS watches a copy of your traffic and the announcements devices make anyway. It does not sit in the traffic path, needs no software on the devices it watches, and keeps its data on the machine it runs on.

From installation to investigation

  1. 01Deploy

    One program on a machine you control

    DENIS is a single program with the web console and documentation built in. It runs as a service on Linux (x86-64 and ARM64, systemd or OpenRC), on a Mac, or in Docker. The signed installer sets it up as an unprivileged service. There is no database server to run: data is kept in one SQLite file, with PostgreSQL and a two-node setup as an option.

  2. 02Connect

    Give it a view of the network

    From any port on a segment DENIS discovers the devices there from their broadcast announcements. To see who talks to whom, connect it to a mirror (SPAN) port or a network tap, or run it on the gateway. One machine can read several mirror ports. Each further segment or site gets its own small collector.

  3. 03Discover

    Build the inventory

    Passive listening (ARP, DHCP, mDNS, SSDP, LLDP/CDP, PROFINET DCP) plus, on IT networks, an optional ARP sweep, ping and light port scan. Each device is identified from weighted evidence and lands in a review queue.

  4. 04Observe

    Learn what is normal

    With traffic accounting on, DENIS aggregates conversations per device and learns a baseline: destinations, ports, volume and active hours. The first 24 hours are a learning period without alerts for new devices and destinations.

  5. 05Detect and investigate

    Explain what changed

    Baselines, rules and industrial decoders raise alerts with a 0–100 score built from named reasons. Related alerts become incidents. Each alert has an Investigate section with the device’s surrounding events.

  6. 06Respond (optional)

    Act through equipment you own

    An administrator can block or quarantine a device through supported switches and firewalls, after a preview, with a time limit and a release. Off by default; automation is experimental and separate.

What it sees, from where

  • Any switch port: broadcast and multicast announcements, enough to discover the devices on that segment; traffic analysis sees only DENIS’s own traffic.
  • Mirror (SPAN) port: a copy of the ports or VLANs you mirror, including traffic between your own devices on that switch.
  • Network tap: everything on one cable.
  • The router or firewall: what crosses it.
  • Remote sites: a collector per site, connecting outbound to the console over HTTPS; no inbound connection into the remote network.

Guide: passive discovery, SPAN and TAP placement →

  1. Your networkPCs · servers · cameras · PLCs · HMIs
  2. SPAN / mirror port or TAPread-only copy
  3. DENISdecodes, does not transmit on the mirror
A mirror port or tap gives DENIS a copy of the traffic. DENIS listens on it and sends nothing back into it.

The processing pipeline

  1. Capturelibpcap, optional polite probes
  2. Parseframes → observations
  3. Inventoryobservations → devices
  4. Fingerprintvendor, type, OS, banners Flow aggregationconversations per window
  5. Detectbaselines, rules, scoring
  6. Riskper device, 0–100
  7. Alerts · Console · API · Integrations
The processing pipeline, as in the architecture section of the README.

Placement and platform

Placement diagram: a switch connects to devices on one side; a mirror port on the switch sends a copy of the traffic to DENIS, which is not in the production path LaptopsServers · IoTPLCs · HMIs Switch mirror / SPAN port copy only DENIS out of band
Out-of-band: if DENIS stops, your network doesn’t notice.
  • Out of band. If DENIS stops, your network does not notice.
  • Platforms. Linux x86-64 and ARM64 (including a static build for Alpine), macOS on Intel and Apple silicon, and a Docker image. No Windows release yet.
  • Storage. One SQLite database file by default; optional PostgreSQL, and two nodes with automatic failover. Experimental in 4.4, tested on PostgreSQL 16 in containers and in a local fault lab, not yet on a managed service.
  • Updates. Signed releases from GitHub; usedenis.com only if GitHub cannot be reached. A backup is taken first and a failed update rolls back by itself.
  • Industrial networks. The OT profile listens only, and devices identified as industrial are never pinged or scanned in any profile.

What traffic accounting adds

With traffic accounting on and a mirror port, a tap or the gateway, DENIS shows trends, top talkers and each device’s destinations over time.

Five trend charts from the DENIS dashboard: new devices, data sent outside the network, data received, total traffic, and alerts raised over the last 24 hours
Trend charts on the demo network. They need traffic accounting and a mirror port, tap or gateway placement.

Limitations

  • DENIS sees only what reaches the interfaces it listens on, and it cannot read encrypted traffic.
  • Traffic between two of your own devices is recorded only when you switch east-west recording on.
  • Duplicate packets from overlapping mirror sessions can be counted or removed since 4.3; loss before a packet reaches DENIS’s port cannot be measured, and the page What DENIS cannot see says so.
  • Many integrations and some deployment options are tested only against simulations; see supported infrastructure and security and trust.