Skip to content

Package monitor

Source: /var/log/dpkg.log

The package monitor tails dpkg's log to detect software installs, upgrades, removes, and purges in real time.

Why it matters

A new binary appearing on a server outside a maintenance window is one of the strongest signals you can get. Common attacker behaviors that this catches:

  • Privilege-escalation toolkits (linux-exploit-suggester, pwncat)
  • Reverse-shell utilities (ncat, socat) — legitimate but rare on production
  • Cryptominers (xmrig, cpuminer)
  • Persistence frameworks installed via apt repos compromised upstream

It also catches legitimate but undocumented installs — a teammate ran apt install vim on production without telling anyone. That's worth knowing.

Event types

parsed_data.type Trigger Default severity
package_install New package added MEDIUM
package_remove Package removed LOW
package_purge Package purged (config + data) LOW
package_upgrade Package upgraded INFO

Each event captures: package name, old version, new version, timestamp.

Sample event

{
  "source": "package",
  "category": "package_install",
  "severity": "MEDIUM",
  "ip": null,
  "description": "Pacchetto installato: vim 2:9.0.1378-2ubuntu1",
  "raw_line": "2026-05-03 14:32:11 install vim:amd64 <none> 2:9.0.1378-2ubuntu1"
}

When does this trigger an investigation?

By default, package_install is MEDIUM — below the HIGH threshold the AI dispatcher uses. So a single install does not automatically open an investigation.

But if it correlates in time with another suspicious event (e.g. a successful SSH login from an unusual IP within 10 minutes of an install), the rule engine raises severity to HIGH and the dispatcher fires.

You can also use the AI bot to query interactively:

You: "What got installed in the last 24 hours?"
Fenrir: [executes search_logs on dpkg.log] "Two installs:
        - 14:32 vim 2:9.0.1378
        - 14:35 htop 3.3.0-1
        Want me to check who triggered them via auth.log?"

Tuning

If your environment has a busy CI that runs apt-get install constantly, MEDIUM-severity package events can be noisy on the dashboard. Two options:

  1. Lower severity to INFO for package_install in analyzers/rule_engine.py (one line change).
  2. Whitelist a maintenance window — coming in 0.6.x. For now, just ignore alerts from your CI server's IP via IP_WHITELIST.

Limitations

  • Apt only. No dnf/yum/zypper/apk/pacman parsers yet — would be straightforward to add.
  • No checksum verification. Fenrir trusts dpkg.log to be authoritative. If an attacker is sophisticated enough to install a package and rewrite dpkg.log, you have bigger problems (and the baseline monitor likely catches the result anyway).
  • First boot. The monitor seeks to end-of-file at startup, so historical installs from before the service started are NOT replayed.