Zum Inhalt springen
SHIELDMYSERVER

Bestandsliste statt Bauchgefühl: was läuft hier eigentlich?

Eine Liste, die die Maschine selbst erzeugt: Pakete, Sprachabhängigkeiten, Container-Images, Randgeräte. Grundlage jeder Betroffenheitsprüfung und des Kundenfragebogens.

mittelDiesen Monat. Wichtig, aber kein Feuer.

veröffentlicht 18.08.2026 · 2 min

Titelbild: Bestandsliste statt Bauchgefühl: was läuft hier eigentlich?

Eine Bestandsliste klingt nach Bürokratie und ist in Wahrheit das Werkzeug, das die meisten Stunden spart: Sie beantwortet die Frage „betrifft uns das?“ in zwei Minuten statt in einem halben Nachmittag und sie beantwortet nebenbei den Sicherheitsfragebogen, den irgendwann ein Kunde schickt.

Warum mittel

Ohne Liste ist keine der schnellen Reaktionen möglich, die diese Seite an anderer Stelle empfiehlt. Sie schließt keine Lücke, aber sie ist die Voraussetzung dafür, die richtige Lücke zuerst zu schließen.

Vier Ebenen, vier Befehle#

Ebene 1, Distributionspakete. Die Ebene, die apt und unattended-upgrades abdecken.

dpkg-query -W -f='${binary:Package}\t${Version}\n' | sort > /tmp/pakete.tsv
. /etc/os-release && echo "$PRETTY_NAME  kernel $(uname -r)"

Ebene 2, Sprachabhängigkeiten. Die Ebene, die kein Distributionsupdate erreicht.

npm ls --all --parseable 2>/dev/null | wc -l
pip list --format=freeze 2>/dev/null
composer show --format=json 2>/dev/null | head

Ebene 3, Container-Images. Ein Image altert still weiter, auch wenn der Host aktuell ist.

docker ps --format '{{.Names}}\t{{.Image}}' 
docker image inspect $(docker ps -q) --format '{{index .RepoDigests 0}}'

Ebene 4, was nicht auf dem Server läuft. Router, VPN-Gateway, NAS, Verwaltungsoberflächen, Firmware. Diese Ebene erzeugt kein Befehl, sie wird einmal aufgeschrieben und bei jeder Änderung nachgezogen. Sie ist gleichzeitig die, über die eingebrochen wird: Verwaltungsoberflächen im Internet.

Eine Zeile, die alles einsammelt#

#!/usr/bin/env bash
# /usr/local/sbin/bestand.sh — läuft wöchentlich, schreibt nach außen
set -euo pipefail
ZIEL="/var/backups/bestand-$(hostname -s)-$(date +%F).txt"
{
  echo "== System";      . /etc/os-release; echo "$PRETTY_NAME  kernel $(uname -r)"
  echo "== Pakete";      dpkg-query -W -f='${binary:Package} ${Version}\n' | sort
  echo "== Dienste";     systemctl list-units --type=service --state=running --no-legend | awk '{print $1}'
  echo "== Lauscht";     ss -tulpn | grep LISTEN
  echo "== Container";   docker ps --format '{{.Names}} {{.Image}}' 2>/dev/null || true
} > "$ZIEL"

Wichtig ist die letzte Eigenschaft: Die Liste gehört nicht auf die Maschine, die sie beschreibt. Nach einem Einbruch ist der lokale Stand genauso vertrauenswürdig wie die lokalen Protokolle, nämlich nicht. Dieselbe Begründung wie in Protokolle, die den Angreifer überleben.

Was ein SBOM zusätzlich bringt#

Ein SBOM (Software Bill of Materials) ist dieselbe Idee in maschinenlesbar, üblicherweise im Format CycloneDX oder SPDX. Für den Eigenbetrieb reicht die Textliste oben. Interessant wird das Format, sobald

  • ein Kunde es verlangt (kommt zunehmend über Lieferkettenklauseln),
  • man Images automatisch gegen Schwachstellendatenbanken prüfen will,
  • oder man selbst Software ausliefert, dann wird es zur Pflicht, siehe Cyber Resilience Act.
# Erzeugen und prüfen, beides ohne Anmeldung nutzbar
syft dir:/opt/app -o cyclonedx-json > sbom.json
grype sbom:sbom.json --fail-on high
Erwartung dämpfen

Scanner melden regelmäßig Treffer in Bibliotheken, die im Image liegen, aber nie ausgeführt werden. Die Trefferliste ist eine Kandidatenliste, kein Befund, die Bewertung macht Ausgenutzt schlägt kritisch daraus.

Der Nebennutzen#

Dieselbe Liste beantwortet ohne Zusatzaufwand: Was muss ins Wartungsfenster? Was läuft noch auf einer Distribution kurz vor Supportende (Distribution aktualisieren)? Und was steht im Abschnitt „eingesetzte Systeme“ der technischen Maßnahmen, die man Kunden gegenüber belegen muss.

Wie oft, und von wem#

Eine Liste, die einmal erzeugt und dann abgelegt wird, altert schneller als der Bestand, den sie beschreibt. Wöchentlich automatisch erzeugen, monatlich einmal ansehen, mehr braucht es nicht, und weniger reicht nicht. Der interessante Teil ist ohnehin nicht die Liste selbst, sondern der Unterschied zur letzten:

diff /var/backups/bestand-web01-2026-07-14.txt /var/backups/bestand-web01-2026-08-18.txt

Was dort auftaucht, sind neue Dienste, neue Ports, ausgetauschte Images, entfernte Pakete. Jede dieser Zeilen sollte man erklären können. Kann man es nicht, ist genau das der Befund, dieselbe Logik wie beim monatlichen Prüfdurchlauf aus Einen Einbruch erkennen.

Bei mehreren Maschinen lohnt es, die Listen an einer Stelle zusammenzuführen. Das muss kein Werkzeug sein: ein Verzeichnis auf dem Sicherungsziel, benannt nach Host und Datum, reicht für den Zweck völlig aus und ist im Ernstfall auch dann noch lesbar, wenn die Maschine selbst nicht mehr erreichbar ist.

MRMedia

Geschrieben aus dem laufenden Betrieb: MRMedia betreibt eigene Hosts, Kundendienste und deren Härtung in der EU. Eine veraltete Anleitung ist hier ein Sicherheitsproblem, kein Schönheitsfehler. Korrekturen bitte über Discord.