Hermes konfiguriert eine OPNsense-Firewall
Ein Praxistest für qwen3.8:27b: eigenständige DNS-Umstellung per OPNsense-API.
Mein bereits bekannter KI-Kollege, der sich selbstständig durch die OPNsense-Dokumentation liest, die passende API-Schnittstelle findet und anschließend die DNS-Konfiguration eigenständig umbaut - das war der Plan für Hermes nach dem Umstieg auf ein leistungsfähigeres lokales Modell. Herausgekommen ist eine saubere Migration von unverschlüsseltem DNS über 1.1.1.1 hin zu verschlüsselter Namensauflösung mit Quad9. Am Ende stand eine Kontrolle, bei der sich zeigte, dass Hermes tatsächlich alles korrekt konfiguriert hat.
Übersicht
Der Auftrag an den KI-Kollegen
Nach dem Umstieg von qwen3.6:27b auf qwen3.8:27b als Basismodell für Hermes Agent stand die Frage im Raum, wie belastbar das neue Modell bei komplexeren, mehrstufigen Aufgaben tatsächlich ist.
Statt einer einfachen Skript-Anfrage wurde daher ein realistisches Infrastruktur-Szenario gewählt: Die Namensauflösung meiner Test-OPNsense lief bislang über den Dnsmasq-Forwarder mit 1.1.1.1 als Upstream - funktional, aber unverschlüsselt und damit für jeden im Netzwerkpfad mitlesbar. Genau dieses Problem wird bereits im Artikel zu DNS-Privatsphäre und Schutz vor Ausspähung behandelt.
Hermes bekam den Auftrag in vier Schritten: sich das nötige Wissen über OPNsense-Konfiguration und deren API anzueignen, die für eine sichere Namensauflösung mit Quad9 nötigen Änderungen zu recherchieren, sich selbst einen API-Zugang einzurichten und schließlich die Umstellung durchzuführen - inklusive Entfernung der alten, unsicheren Konfiguration.
Recherche der richtigen Verschlüsselungsmethode
Der erste eigenständige Rechercheschritt von Hermes brachte einen wichtigen Fakt zutage, der in meiner ursprünglichen Aufgabenstellung so nicht klar formuliert war: Unbound in OPNsense unterstützt DNS over HTTPS nicht direkt, weshalb dafür eigentlich das DNSCrypt-Proxy-Plugin nötig wäre. Nativ eingebaut ist dagegen DNS over TLS, was Unbound seit einiger Zeit direkt beherrscht und wofür in der Konfiguration ein eigener Menüpunkt existiert.
Für Quad9 empfiehlt sich laut offizieller Dokumentation folgende Konfiguration: In der GUI unter Services > Unbound DNS > DNS over TLS werden vier Einträge angelegt, mit dns.quad9.net als Verify-CN-Feld und Port 853, für die Server-IPs 9.9.9.9, 149.112.112.112 sowie optional die IPv6-Adressen 2620:fe::fe und 2620:fe::9. Da im Heimnetz kein natives IPv6 zum Einsatz kommt, hat Hermes sich zurecht für die reine IPv4-Variante entschieden - bei fehlendem IPv6 sollten die entsprechenden Adressen weggelassen werden, da sonst ein Teil der Anfragen fehlschlagen kann.
Zusätzlich fiel bei der Recherche auf, dass Unbound und Dnsmasq in OPNsense zwei unabhängig voneinander aktivierbare Resolver-Dienste sind, die parallel existieren, sich aber gegenseitig ausschließen sollten, wenn eine der beiden Lösungen die Namensauflösung übernehmen soll.
Einrichtung des API-Zugangs
Bevor Hermes überhaupt etwas an der Konfiguration ändern konnte, musste ein eigener API-Zugang her. Dafür wird in OPNsense unter der Benutzerverwaltung ein "Ticket" erzeugt: über das entsprechende Icon lässt sich ein API-Schlüssel erzeugen und herunterladen, der sowohl Key als auch Secret in einer Datei enthält. Wichtig dabei ist die Rechtevergabe - der Besitzer des Schlüssels muss auch tatsächlich zu den entsprechenden Ressourcen berechtigt sein, was sich über die effektiven Privilegien des jeweiligen Benutzers steuern lässt.
Die Authentifizierung gegenüber der API erfolgt anschließend klassisch per HTTP Basic Auth, wobei Key und Secret als Benutzername und Passwort übergeben werden. Ein einfacher Testaufruf sieht im Prinzip so aus:
# Testaufruf gegen die OPNsense-API - M. Meister
# Prüft, ob Key und Secret korrekt funktionieren
curl -k -u "API_KEY":"API_SECRET" \
https://opnsense.lan/api/core/firmware/status
Für einen eigens für Hermes angelegten Benutzer wurde bewusst ein eingeschränktes Rechteprofil vergeben, das nur Zugriff auf die für DNS und Firewall-Regeln relevanten API-Controller erlaubt - ein KI-Agent mit vollem Adminzugriff auf die Firewall wäre dann doch ein Schritt zu weit gewesen.
Umstellung der Namensauflösung per API
Für die eigentliche Konfiguration nutzt Hermes die Unbound-Endpunkte der OPNsense-API. Für DoT-Einträge existieren dedizierte Aktionen: addDot zum Anlegen, getDot zum Auslesen, setDot zum Bearbeiten und delDot zum Löschen eines Eintrags, jeweils gefolgt von einem Reconfigure-Aufruf, damit Unbound die neue Konfiguration tatsächlich übernimmt. Ein vereinfachtes Beispiel für das Anlegen eines DoT-Servers von Hand, wie ihn hermes letztlich ausführen muss:
# Anlegen eines DoT-Eintrags für Quad9 via OPNsense-API - M. Meister
curl -k -u "API_KEY":"API_SECRET" \
-X POST -H "Content-Type: application/json" \
-d '{
"dot": {
"enabled": "1",
"server": "9.9.9.9",
"port": "853",
"verify": "dns.quad9.net"
}
}' \
https://opnsense.lan/api/unbound/settings/addDot
# Konfiguration anwenden
curl -k -u "API_KEY":"API_SECRET" \
-X POST https://opnsense.lan/api/unbound/service/reconfigure
Der gleiche Ablauf wurde für den zweiten Quad9-Server 149.112.112.112 wiederholt. Anschließend hat Hermes den Dnsmasq-Forwarder mit dem alten 1.1.1.1-Eintrag deaktiviert und Unbound als alleinigen DNS-Dienst gesetzt. Ein Punkt, den Hermes bei der Recherche korrekt aufgegriffen hat: die Option, dass der DNS-Server per DHCP oder PPP auf der WAN-Schnittstelle überschrieben werden darf, sollte deaktiviert werden, da sonst der Provider unbemerkt wieder unverschlüsseltes DNS einschleusen könnte.
Als zusätzliche Absicherung wurde noch eine Firewall-Regel ergänzt, die ausgehenden Traffic auf Port 53 unterbindet. Das ist keine Erfindung von Hermes, sondern gängige Praxis: es ist sinnvoll, sämtlichen ausgehenden DNS-Verkehr über Port 53 per Firewall-Regel zu blockieren, wenn DNS over TLS verwendet wird, damit Clients nicht versehentlich andere Nameserver direkt und unverschlüsselt kontaktieren. Wo einzelne Geräte hartnäckig eigene DNS-Server ansprechen wollten, half stattdessen eine NAT-Redirect-Regel, die diese Anfragen zwangsweise auf den lokalen Unbound-Dienst umleitet.
Kontrolle und das Ergebnis
Nach Abschluss der Umstellung ging es an die Verifikation - und genau hier zeigte sich, dass Hermes sauber gearbeitet hatte. Ein Blick unter Interfaces > Diagnostics > DNS Lookup lieferte ausschließlich 127.0.0.1 als verwendeten Server, was bedeutet, dass sämtliche Anfragen tatsächlich über den lokalen Unbound-Resolver laufen und nicht direkt an einen fremden Server gehen. Ein zusätzlicher Blick in den Traffic per Paketaufzeichnung bestätigte verschlüsselte TLS-Verbindungen zu 9.9.9.9 auf Port 853 - genau das erwartete Bild für eine funktionierende DoT-Verbindung.
Der alte 1.1.1.1-Eintrag im Dnsmasq-Forwarder war vollständig entfernt, die Override-Option für DHCP/PPP deaktiviert und die Firewall-Regel für Port 53 aktiv. Die Kombination aus DNSSEC-Validierung und TLS-Verschlüsselung sorgte für spürbar mehr Vertrauen in die eigene DNS-Infrastruktur, ohne dass dafür manuell durch die GUI geklickt werden musste. Für einen Agenten, der zuvor lediglich mit einfacheren Aufgaben getestet wurde, war das ein überraschend rundes Ergebnis - die Kombination aus Recherche, API-Nutzung und sauberer Fehlerkorrektur hat mehr Vertrauen in künftige, komplexere Automatisierungsaufgaben geschaffen, wie sie bereits im Artikel zu automatisch umgesetzten Firewall-Konfigurationsänderungen angerissen wurden.
Fazit
Die Umstellung von unverschlüsseltem DNS über 1.1.1.1 auf DNS over TLS mit Quad9 auf meiner Test-Firewall wurde vollständig von Hermes Agent recherchiert, per API umgesetzt und lieferte bei der abschließenden Kontrolle ein einwandfreies Ergebnis. Das Experiment zeigt, dass ein lokal gehosteter KI-Agent mit begrenzten API-Rechten durchaus in der Lage ist, mehrstufige Sicherheitsaufgaben auf einer produktiven Firewall zuverlässig zu übernehmen. Dennoch würde ich einen KI-Agenten niemals ohne meine persönliche Kontrolle auf eine operative Firewall loslassen.