Collector-VM härten¶
Der Collector steht im Kundennetz und kennt die Zugangsdaten der Geräte, die er prüft. Läuft auf einer VM nur der Collector, lässt sie sich deutlich enger einstellen als ein gewöhnlicher Server. Dafür gibt es ein Script, das jeden Schritt zuerst zeigt, begründet und erst nach Rückfrage ausführt. Jede Änderung ist protokolliert und mit einem Befehl rückgängig zu machen.
Nur für reine Collector-VMs
Das Script bricht ab, wenn auf der Maschine Docker oder ein Aktiver Collector läuft — also auf dem Vesana-Server selbst. Andere Dienste auf der VM (z. B. ein Syslog-Empfänger) sind kein Problem: was beim Härten von außen erreichbar ist, bleibt erreichbar.
Empfohlene Grundlage¶
| Empfehlung | |
|---|---|
| Betriebssystem | Debian 13 oder Ubuntu 26.04 LTS (24.04 LTS wird ebenfalls unterstützt) |
| Installation | Minimal: nur SSH-Server, keine Desktop- oder Server-Pakete |
| Größe | 2 vCPU, 2 GB RAM, 20 GB Platte |
| Netz | Sicht auf die Geräte, die geprüft werden; ausgehend HTTPS zum Vesana-Server |
| Zugang | ein Admin-Konto mit sudo und SSH-Schlüssel |
Die SSH-Anmeldung mit Passwort bleibt standardmäßig erlaubt. Nur mit Schlüssel ist sicherer — das Script fragt danach, schaltet das Passwort aber nur ab, wenn für dich ein Schlüssel hinterlegt ist. Es sperrt niemanden aus.
In vier Schritten¶
1. VM aufsetzen, Admin-Konto mit SSH-Schlüssel anlegen, Updates einspielen.
2. Collector installieren wie unter Collector beschrieben.
Wer die VM auch gegen einen kompromittierten Vesana-Server absichern will,
installiert mit Agent Lock (VESANA_LOCK=1) — das ist der
stärkste Schutz und nicht Teil dieses Scripts, weil er Freigaben am Host
verlangt.
3. Härten — Script von deinem Vesana-Server laden und ausführen:
Zuerst stellt das Script höchstens drei Fragen. Enter übernimmt die Vorgabe:
| Frage | Eingabe | Vorgabe |
|---|---|---|
| SSH-Anmeldung mit Passwort erlauben? | j oder n |
ja (nur gefragt, wenn für dich ein Schlüssel hinterlegt ist) |
| SSH nur aus bestimmten Netzen erlauben? | z. B. 192.168.1.0/24,10.0.0.5 oder alle |
alle |
| root-Passwort sperren? | j oder n |
ja (nur gefragt, wenn ein sudo-Konto mit Schlüssel da ist) |
Alles andere hat einen sicheren Standard und lässt sich bei Bedarf per Option ändern (siehe Optionen).
Dann zeigt es den vollständigen Plan und fragt Jetzt anwenden? [j/N]. Nach
dem Laden der Firewall bittet es dich, eine zweite SSH-Sitzung zu öffnen.
Klappt die Anmeldung, bestätigst du mit ok. Ohne Bestätigung nimmt die VM die
Firewall nach 180 Sekunden von selbst wieder zurück — auch wenn deine Sitzung
abbricht.
Nur ansehen, ohne etwas zu ändern: sudo bash harden.sh --plan. Die
Firewall-Regeln im Wortlaut: sudo bash harden.sh --show-firewall.
4. Prüfen — in Vesana zeigt der Collector weiter „online", und auf der VM:
Das prüft die Härtung, ob der Collector läuft, ob er den Server erreicht und ob sein Log Fehler zeigt. Stimmt etwas nicht, endet der Befehl mit Exit-Code 1 — so lässt er sich auch in eigene Überwachung oder Automatisierung einbauen.
Was das Script tut¶
| Modul | Was | Bewusst nicht |
|---|---|---|
updates |
Updates der installierten Version täglich automatisch (unattended-upgrades). | Kein Versionssprung. Kein automatischer Neustart, außer mit --auto-reboot 03:30. |
ssh |
Passwort-Anmeldung nach Wahl (Standard: bleibt; aus nur, wenn für dich ein Schlüssel hinterlegt ist), root-Anmeldung aus bzw. nur mit Schlüssel, 30 s Anmeldefrist, kein X11. Lockert nie, was schon strenger ist. | Port-Weiterleitung bleibt (Collector als Sprungserver, ssh -J). MaxAuthTries bleibt beim Standard. Die Verschlüsselungsverfahren bleiben unverändert. |
firewall |
Eingehend nur: Antworten auf eigene Verbindungen, SSH, Ping, DHCP, mDNS/SSDP/LLMNR-Antworten (Discovery) und jeder Dienst, der beim Härten von außen lauscht. | Ausgehend wird nicht gefiltert — der Collector muss jedes Gerät auf jedem Port erreichen. |
sysctl |
Kernel-Parameter verschärfen: Kernel-Infos nur für root, kein unprivilegiertes BPF/User-Namespaces/io_uring, keine ICMP-Redirects und kein Source-Routing. Nur verschärfen, nie lockern. | ping_group_range bleibt (der Collector pingt darüber ohne Sonderrechte), ip_forward bleibt, kein strenger Reverse-Path-Filter (bräche VMs mit mehreren Netzkarten/VLANs). |
kernelmodule |
cramfs, freevxfs, hfs, hfsplus, jffs2, dccp, sctp, rds, tipc nicht mehr ladbar. | USB-Speicher, udf, squashfs bleiben (Cloud-Init-Datenträger, Snaps). |
dienste |
avahi, cups, rpcbind abschalten, falls sie laufen (rpcbind nicht, wenn NFS eingehängt ist). systemd-resolved beantwortet LLMNR nicht mehr im Netz. | Namen ohne Domäne löst die VM weiter über LLMNR auf. |
konten |
root-Passwort sperren — nur wenn das Script per sudo von einem Konto mit SSH-Schlüssel läuft; abwählbar. | Keine Konten anlegen oder löschen. |
protokoll |
Journal dauerhaft; auditd schreibt Änderungen an Vesana-Konfiguration und -Programmdatei, Agent-Lock-Freigaben, SSH-Konfiguration, sudo und Benutzern mit. | Keine Mitschrift jedes Befehls. |
coredumps |
Speicherabbilder aus — ein Abbild des Collectors enthielte entschlüsselte Zugangsdaten. | |
zeit |
Sicherstellen, dass die Uhr synchronisiert wird (TLS und Messzeiten brauchen sie). | Zeitserver bleiben. |
shm |
/dev/shm ohne Ausführrecht. |
/tmp bleibt ausführbar — der Collector-Installer prüft die heruntergeladene Programmdatei dort mit einem Probelauf; mit noexec scheiterte jedes Neuinstallieren und Aktualisieren über den Installer. |
Der Collector-Dienst selbst ist schon vom Installer eingeschränkt (eigener Benutzer ohne Login, schreibgeschütztes System, nur die nötigen Netz-Berechtigungen, signierte Updates). Das Script ändert an der Collector-Installation nichts.
Wird die VM selbst überwacht?¶
Das ist der Fall, an dem eine Härtung am leichtesten etwas kaputt macht.
| Wie wird die VM geprüft? | Was zu tun ist |
|---|---|
| Ping | nichts — Ping bleibt erlaubt. |
| SSH mit Schlüssel (z. B. vom Aktiven Collector) | nichts. |
| SSH mit Passwort | nichts, solange die Passwort-Anmeldung erlaubt bleibt (Standard). Wer sie abschaltet, nimmt den prüfenden Server mit --password-from <IP> aus — sonst schlägt der Check mit „credentials rejected" fehl. |
| SNMP (snmpd auf der VM) | nichts, wenn snmpd beim Härten läuft — er bleibt erreichbar. Sonst --allow udp/161. |
| Vesana-Agent auf der VM | nichts — der Agent baut nur ausgehende Verbindungen auf. |
Dasselbe gilt für Dienste, die auf der VM Daten annehmen, etwa ein
Syslog-Empfänger für Switches oder ein NAS: läuft er beim Härten, bleibt sein
Port offen. Kommt er später dazu: --allow udp/514.
Grün heißt erst nach einer neuen Verbindung wirklich grün
Der Collector hält SSH-Verbindungen offen und benutzt sie wieder. Ein
SSH-Check, der schon vor dem Härten verbunden war, bleibt deshalb grün, bis
die Verbindung neu aufgebaut wird. Wer sichergehen will, startet nach dem
Härten den prüfenden Collector neu
(sudo systemctl restart vesana-collector) und sieht sich die Checks danach
an.
Optionen¶
| Option | Wirkung |
|---|---|
--plan |
Nur zeigen, nichts ändern. |
--yes |
Ohne Fragen anwenden (Automatisierung) — es gelten Standards, letzter Lauf und Optionen. Ohne Terminal entfällt das 180-s-Fenster — SSH bleibt nach den --ssh-from-Regeln erreichbar. |
--ssh-from 10.0.0.0/8,192.168.1.0/24 |
SSH nur aus diesen Netzen. Das Script bricht ab, wenn deine aktuelle Verbindung nicht darin liegt. Zurück auf „von überall": --ssh-from all. |
--no-keep-password-login |
SSH nur noch mit Schlüssel (zurück: --keep-password-login). |
--password-from 10.1.2.3/32 |
Bei abgeschaltetem Passwort: von dort weiter erlauben. Entfernen: --password-from none. |
--allow udp/514,tcp/6556 |
Zusätzlich eingehend erlauben. Entfernen: --allow none. |
--no-keep-listening |
Lauschende Dienste NICHT automatisch offen lassen (zurück: --keep-listening). |
--keep-root-password |
root-Passwort nicht sperren (zurück: --lock-root-password). |
--auto-reboot 03:30 |
Nach Sicherheitsupdates, die es brauchen, zu dieser Uhrzeit neu starten (aus: --auto-reboot none). |
--skip firewall,konten |
Module für diesen Lauf auslassen (--modules listet alle). |
--show-firewall |
Die Firewall-Regeln zeigen, die geladen würden. |
Das Script lässt sich beliebig oft ausführen, und ein erneuter Lauf lockert nie
still: Optionen eines früheren Laufs gelten weiter (der Plan sagt „aus dem
letzten Lauf übernommen"), bis du sie ausdrücklich änderst. Eine nachträgliche
Freigabe ist deshalb einfach sudo vesana-haertung --allow udp/514 — die übrigen
Einstellungen bleiben.
Zurücknehmen¶
Legt jede gesicherte Originaldatei zurück, entfernt die eigenen Dateien und die
Firewall, schaltet abgeschaltete Dienste wieder ein, entsperrt das root-Passwort
und setzt die Kernel-Parameter auf die Werte von vorher. Installierte Pakete
(unattended-upgrades, nftables, auditd) bleiben installiert, nur ohne die
Einstellungen des Scripts. kernel.kexec_load_disabled lässt sich zur Laufzeit
nicht zurücknehmen und gilt bis zum nächsten Neustart.
Was das Script getan hat, steht in /var/log/vesana-haertung.log; die Originale
liegen unter /var/lib/vesana-haertung/backup/.
Fehlersuche¶
Ein Gerät erreicht die VM nicht mehr (z. B. Syslog kommt nicht an): Die Firewall protokolliert verworfene Pakete gedrosselt im Kernel-Log.
Steht dort Absender und Port, gibt sudo vesana-haertung --allow udp/514 den
Port frei (der Lauf zeigt vorher wieder den Plan; frühere Einstellungen bleiben). Rundrufe im LAN
(z. B. NetBIOS von Windows-Rechnern) werden verworfen, ohne das Log zu füllen.
Ein Check zeigt nach dem Härten einen Fehler: Die Firewall filtert nur eingehend — Checks, die der Collector selbst aufbaut, betrifft sie nicht. Ist das Ziel des Checks die VM selbst, siehe Wird die VM selbst überwacht?.
Die Firewall wurde übersprungen: Läuft schon eine andere Firewall (ufw, firewalld oder eigene nftables-Regeln für eingehenden Verkehr), lädt das Script keine zweite — zwei Firewalls nebeneinander verwerfen sich gegenseitig Pakete. Dann in der vorhandenen Firewall SSH, Ping, DHCP, udp/1900 + 5353 + 5355 und die eigenen Dienste erlauben.
Was darüber hinaus sinnvoll ist¶
Nicht Teil des Scripts, weil es außerhalb der VM liegt oder Entscheidungen verlangt:
- Agent Lock — der Collector führt nur Scripts aus, die am Host freigegeben sind; ein kompromittierter Vesana-Server kann dann nichts Neues auf der VM ausführen.
- Eigenes Netzsegment für die VM mit einer Firewall davor, die nur die Wege erlaubt, die der Collector braucht.
- Zugang zur Hypervisor-Konsole schützen — sie umgeht jede Anmeldung an der VM.
- Sicherung der VM vor größeren Änderungen (Snapshot).
Anschluss¶
- Collector — Installation und Betrieb
- Agent Lock — Scripts nur nach Freigabe am Host
- Agent-Gateway — Agents und Collectors über einen eigenen Port anbinden