pfSense und OPNsense

Was NODE64 auf einer Firewall prüft – und was ausdrücklich nicht.

Vorbereitet, nicht unterstützt #

Diese Seite beschreibt einen Stand, der vorbereitet ist: Die Prüfungen sind gebaut, der Agent ist auf FreeBSD 15.1 gemessen worden. Auf einer echten pfSense- oder OPNsense-Installation ist er noch nicht erprobt. Solange das so ist, steht hier nicht „unterstützt".

Wie der Agent dorthin kommt #

Beide Systeme sind FreeBSD. Der NODE64-Agent wird seit Phase 22 auch für FreeBSD gebaut – statisch, ohne Bibliotheken des Zielsystems. Er wird als Programm abgelegt und über ein rc.d-Skript gestartet.

Bewusst kein Paket und kein Plugin. Netgate schreibt zu fremden Paketquellen auf pfSense, ihre Verwendung sei nicht unterstützt und trage ein erhebliches Risiko, die Installation zu beschädigen – bis hin zu Systemen, die nicht mehr starten. Ein Werkzeug, das die Sicherheit eines Systems prüfen soll, darf dieses System nicht gefährden. Für OPNsense wäre ein Plugin möglich, müsste aber in das Projekt aufgenommen und dauerhaft mitgepflegt werden; der Agent braucht die Oberfläche gar nicht.

Was daraus folgt: Nach einem Firmware-Update kann das Programm verschwunden sein. Das Installationsskript lässt sich dann erneut ausführen. Bleibt es aus, hört der Herzschlag auf und das Gerät fällt im Dashboard sichtbar auf „offline" – es verschwindet nicht still.

Was gelesen wird #

Die gesamte Konfiguration beider Systeme steht in einer Datei: /conf/config.xml. Der Agent liest sie und wertet sie an Ort und Stelle aus.

Aus dieser Datei verlässt nichts das Gerät. Sie enthält die Passwörter aller Benutzer, IPsec-Schlüssel, WireGuard-Privatschlüssel, Zertifikate samt privatem Teil, RADIUS- und LDAP-Zugangsdaten. Übertragen werden ausschließlich Zahlen und Ja/Nein-Angaben: „drei Regeln ohne Beschreibung", „UPnP ist an", „ein IPsec-Tunnel benutzt ein überholtes Verfahren". Kein Auszug, kein Regelname, keine Adresse.

Zwei Tests sichern das ab. Der erste füttert eine Konfiguration mit erfundenen Geheimnissen und prüft, dass keines davon in den erhobenen Werten auftaucht. Der zweite ist schärfer: Er verlangt, dass jeder erhobene Wert eine Zahl ist – damit kann auch nichts durchrutschen, an das beim Schreiben des Tests niemand gedacht hat.

Was geprüft wird #

Bereich	Prüfungen
Zugang	Weboberfläche auf der WAN-Seite, HTTP statt HTTPS, SSH von außen, Konto `admin` noch aktiv
Regelwerk	Regeln „von überall nach überall", Regeln ohne Beschreibung, Regeln ohne Protokollierung
NAT	Portweiterleitung ohne Quellbeschränkung, UPnP eingeschaltet
Dienste	DNS-Resolver nach außen offen, Zeitdienst nach außen offen, SNMP mit Standard-Community
VPN	IPsec mit überholten Verfahren, OpenVPN ohne TLS-Schlüssel, OpenVPN mit schwacher Verschlüsselung
Betrieb	kein entferntes Protokollziel, keine automatische Sicherung

Was NICHT geprüft wird #

Der Linux-Prüfkatalog greift dort nicht. Auf einer Firewall ist /etc/rc.conf fast leer, Dienste werden von der Oberfläche erzeugt, und Aktualisierungen laufen über die Firmware. Der gewöhnliche Katalog würde reihenweise Dinge melden, die auf einer Firewall richtig sind. Jede der über 300 anderen Prüfungen ist ausdrücklich gegen Firewalls abgegrenzt.
Es wird nichts geändert. NODE64 liest, wertet aus und meldet. Keine Regel wird angelegt, keine abgeschaltet, kein Dienst neu gestartet.
Keine Prüfung von außen. Ob ein Port wirklich offen ist, sagt die Konfiguration – nicht ein Scan. Ein Werkzeug, das die eigene Firewall von außen abklopft, wäre etwas anderes.