KeyHelp: Firewall im Panel verwalten, Ports öffnen und sich nicht selbst aussperren

Ein neuer Dienst braucht einen offenen Port, eine Datenbank soll nur für eine feste Adresse erreichbar sein, oder Sie wollen einen Port schließen, den Sie nicht nutzen. KeyHelp bringt dafür unter „Sicherheit“, „Firewall“ eine eigene Regelverwaltung mit. Diese Anleitung zeigt, wie Sie damit einen Port gezielt für eine Quelladresse öffnen, warum die Reihenfolge der Regeln entscheidet und was KeyHelp tut, wenn Sie sich selbst aussperren. Wir haben das in einer Test-VM nachgestellt, inklusive echtem Aussperren. Dabei zeigte sich eine Lücke im Schutzmechanismus, die Sie kennen sollten. Grundlage ist ein Server wie in KeyHelp installieren und absichern.

Voraussetzungen

• KeyHelp-Server mit Admin-Zugang, getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12.15.
• Root-Zugang auf der Konsole als Rückfallweg, zum Beispiel die Rescue- oder VNC-Konsole Ihres Hosters. Im Test war das incus exec der Test-VM.
• Für die Verbindungstests haben wir auf dem Server eine zweite Netzwerkumgebung (Network Namespace) mit den Adressen 198.51.100.10 und 198.51.100.20 angelegt und einen kleinen Testdienst auf Port 8080 gestartet. Das simuliert zwei Clients, ist aber kein Test über das Internet.

Schritt 1: Ausgangslage im Panel und auf dem Server prüfen

Öffnen Sie im Admin-Bereich „Sicherheit“, „Firewall“. Ab Werk war die Firewall aktiviert. Unter „Eingehender Traffic“ standen acht Regeln, dazu „Ping“ mit „Zulassen“ und die „Standardrichtlinie“ mit „Verweigern“. Ausgehender Traffic ist ab Werk erlaubt, weitergeleiteter verweigert.

Die Regel „MariaDB / MySQL“ steht auf „Verweigern“, alle anderen auf „Zulassen“. Den Hinweis über der Tabelle sollten Sie ernst nehmen: „Sobald eine Regel zutrifft, werden die folgenden Regeln nicht mehr ausgewertet.“

Verifizieren: Auf dem Server zeigt iptables -S dieselben Regeln. Auszug:

iptables -S | head -60

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
...
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
...
-A INPUT -p tcp -m tcp --dport 3306 -j DROP

Vor den Panel-Regeln stehen feste Regeln, die KeyHelp selbst setzt, etwa für bestehende Verbindungen und das Loopback-Interface lo. Ein separater Firewall-Dienst wie ufw oder firewalld war im Test nicht aktiv, systemctl zeigte nur Fail2Ban. Unter Debian 12 ist iptables das Frontend für nftables, nft list ruleset meldet dazu table ip filter is managed by iptables-nft, do not touch!.

Schritt 2: Bearbeitungsmodus aktivieren und Regel anlegen

Klicken Sie auf „Bearbeitungsmodus aktivieren“. Erst dann erscheinen „Regel hinzufügen“, „Änderungen übernehmen“, „Änderungen verwerfen“, „Aktive Regeln laden“ und „Standardregeln laden“. KeyHelp blendet den Hinweis ein: „Der Bearbeitungsmodus ist aktiviert. Bitte beachten Sie, dass Änderungen erst wirksam werden, sobald Sie die Schaltfläche Änderungen übernehmen betätigen.“

Über „Regel hinzufügen“ öffnet sich das Formular mit diesen Feldern:

• „Name *“: Pflichtfeld, im Test „Testdienst 8080“.
• „Richtung“: „Eingehender Traffic“, „Ausgehender Traffic“ oder „Weitergeleiteter Traffic“.
• „Aktion“: „Zulassen“, „Verweigern“ (verwirft ohne Antwort) oder „Zurückweisen“ (meldet dem Absender die Sperre).
• „TCP-Ports“ und „UDP-Ports“: einzelne Ports oder Bereiche, laut Feldhilfe zum Beispiel 900, 1000-1030.
• „Quellen“: eine oder mehrere IP-Adressen oder Netzwerkmasken. Leer bedeutet: alle.

Wir haben „Eingehender Traffic“, „Zulassen“, TCP-Port 8080 und als Quelle 198.51.100.10 eingetragen und gespeichert. Die neue Regel landet ganz oben auf Position 1.

Verifizieren: Solange Sie nicht übernommen haben, ändert sich auf dem Server nichts. Im Test meldete iptables -S INPUT | grep -c 8080 nach dem Speichern noch 0.

Schritt 3: Änderungen übernehmen und Wirkung testen

Klicken Sie auf „Änderungen übernehmen“. Es erscheint der Dialog „Verhindert Serveraussperrung“ (mehr dazu in Schritt 5), danach die Meldung „Die Firewall-Regeln wurden erfolgreich übernommen.“ Im Journal sieht man, was technisch passiert: KeyHelp sichert die laufenden Regeln mit iptables-save, prüft die neue Konfiguration mit iptables-restore --test, lädt sie mit iptables-restore und startet Fail2Ban neu (systemctl restart fail2ban).

Verifizieren: Regel und Verbindungstest von beiden simulierten Clients:

iptables -S INPUT | grep -n 8080; ls -la /etc/keyhelp/iptables; ip netns exec client ip addr add 198.51.100.20/24 dev veth-cli; ip netns exec client curl -sS -m 5 -o /dev/null -w "von .10: %{http_code}\n" http://198.51.100.1:8080/; ip netns exec client curl -sS -m 5 --interface 198.51.100.20 -o /dev/null -w "von .20: %{http_code}\n" http://198.51.100.1:8080/

11:-A INPUT -s 198.51.100.10/32 -p tcp -m tcp --dport 8080 -j ACCEPT
total 16
drwx------ 2 keyhelp keyhelp 4096 Oct  1 09:24 .
drwx------ 5 keyhelp keyhelp 4096 Oct  1 09:24 ..
-rw------- 1 keyhelp keyhelp 1962 Oct  1 20:22 startup_rules_ipv4
-rw------- 1 keyhelp keyhelp 1874 Oct  1 20:22 startup_rules_ipv6
von .10: 200
curl: (28) Connection timed out after 5000 milliseconds
von .20: 000

Die freigegebene Adresse bekommt Antwort, die andere läuft in die Standardrichtlinie und erhält keine Antwort. KeyHelp legt die Regeln zusätzlich in /etc/keyhelp/iptables/startup_rules_ipv4 und startup_rules_ipv6 ab. Diese Dateien lädt /etc/cron.d/keyhelp-firewall beim Start:

@reboot root bash /home/keyhelp/www/keyhelp/bin/keyhelp_load_rules.sh

Nach einem Neustart der VM waren die Regeln für Port 8080 wieder aktiv.

Schritt 4: Reihenfolge richtig setzen

Wollen Sie anderen Absendern eine klare Absage erteilen statt sie ins Leere laufen zu lassen, brauchen Sie eine zweite Regel „Zurückweisen“ für Port 8080 ohne Quelle. Wir haben sie angelegt. Wie schon die erste Regel landete auch sie im Test auf Position 1, also vor der Freigabe. Ergebnis nach dem Übernehmen:

-A INPUT -p tcp -m tcp --dport 8080 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -s 198.51.100.10/32 -p tcp -m tcp --dport 8080 -j ACCEPT
von .10: 000
curl: (7) Failed to connect to 198.51.100.1 port 8080 after 0 ms: Couldn't connect to server

Die allgemeine Sperre greift zuerst, auch die eigentlich freigegebene Adresse kommt nicht mehr durch. Korrigieren Sie das im Bearbeitungsmodus über das Auswahlfeld in der Spalte „Position“: Wir haben die Sperrregel auf Position 2 gesetzt und erneut übernommen.

Verifizieren:

11:-A INPUT -s 198.51.100.10/32 -p tcp -m tcp --dport 8080 -j ACCEPT
12:-A INPUT -p tcp -m tcp --dport 8080 -j REJECT --reject-with icmp-port-unreachable
von .10: 200
von .20: 000
curl: (7) Failed to connect to 198.51.100.1 port 8080 after 0 ms: Couldn't connect to server

Jetzt bekommt 198.51.100.10 Antwort, 198.51.100.20 wird sofort abgewiesen statt nach fünf Sekunden Zeitüberschreitung.

Schritt 5: Was beim Aussperren passiert

Nach jedem „Änderungen übernehmen“ zeigt KeyHelp den Dialog „Verhindert Serveraussperrung“: „Das System stellt nun sicher, dass Sie sich nicht vom Server ausgesperrt haben. Dieser Test dauert etwa 10-15 Sekunden.“ Bleiben Sie auf der Seite. Laut Skript der Seite (page_firewall.js) fragt der Browser nach sechs Sekunden per AJAX beim Server nach. Kommt die Antwort, erscheint „Alles okay!“. Andernfalls lautet der Text „Überprüfung fehlgeschlagen. Die Firewall-Regeln werden innerhalb der nächsten 2 Minuten zurückgesetzt.“

Wir haben das bewusst ausgelöst: Im Bearbeitungsmodus die Regeln „SSH“ und „HTTP / HTTPS“ markiert, „Auswahl löschen“ gewählt und übernommen. Eine Warnung, dass damit SSH und Panel gesperrt werden, gab es nicht, nur die allgemeine Rückfrage „Sind Sie sicher, dass Sie die ausgewählten Elemente löschen möchten?“. Danach kam vom simulierten Client nichts mehr durch, auf dem Server stand keine Regel mehr für die Ports 22, 80 und 443:

rc_grep=1
HTTPS neu: 000
SSH zu

Das Journal zeigt, wie KeyHelp sich selbst geholfen hat. Die Regeln wurden um 20:22:58 (Serverzeit UTC) übernommen. Um 20:24:01, also 63 Sekunden später und in derselben Sekunde, in der der minütliche KeyHelp-Cronjob startete, lud KeyHelp als root wieder eine Regelkonfiguration (Auszug):

Oct 01 20:24:01 server.example.de CRON[2149]: (root) CMD (nice -n 5 php /home/keyhelp/www/keyhelp/cronjob/mastercronjob.php)
Oct 01 20:24:01 server.example.de sudo[2222]:     root : PWD=/root ; USER=root ; COMMAND=/usr/sbin/iptables-restore /tmp/keyhelp/firewall-config-ipv4

Verifizieren: Nach dem Zurücksetzen enthielt die Startdatei wieder die Regeln für die Ports 22, 80 und 443 (grep -cE "dport (22|80|443) " /etc/keyhelp/iptables/startup_rules_ipv4 lieferte 3). Im Panel stand: „Ihre Firewall-Regeln wurden zurückgesetzt, weil Sie sich vom Server ausgesperrt haben. Bitte überprüfen Sie Ihre aktuellen Firewall-Einstellungen.“ Auf dem Server standen wieder die Regeln vor dem Löschen, einschließlich der Freigabe für Port 8080. Sicherungen der vorherigen Regeln lagen im Test in /tmp/keyhelp/firewall-backups/, je eine Datei für IPv4 und IPv6 pro Übernehmen und Zurücksetzen.

Wichtig: Der Schutz prüft nur, ob Ihr Browser das Panel noch erreicht. Im zweiten Versuch haben wir nur die Regel „SSH“ gelöscht und übernommen. Der Dialog meldete „Alles okay!“, ein Zurücksetzen gab es nicht. Auch gut eine Minute später stand keine Regel für Port 22 in iptables (Zähler 0). Der Test vom simulierten Client zeigte Port 22 geschlossen, das Panel per HTTPS aber erreichbar:

SSH zu
HTTPS: 302

Wer SSH, E-Mail-Ports oder FTP schließt, wird vom Panel also nicht gewarnt. Prüfen Sie jeden Dienst nach dem Übernehmen selbst, bevor Sie die Seite verlassen.

Schritt 6: Zurück zum Werkszustand

Im Bearbeitungsmodus setzt „Standardregeln laden“ die Tabelle ohne Rückfrage auf die acht Werksregeln zurück. Eigene Regeln, im Test beide Regeln für Port 8080, sind danach entfernt. Wirksam wird das erst mit „Änderungen übernehmen“.

Verifizieren:

1
SSH offen
curl: (28) Connection timed out after 5000 milliseconds
8080 von .10: 000

SSH ist wieder offen, Port 8080 ist zu (die 1 ist die SSH-Regel, keine 8080-Regel mehr).

Typische Fehler

Regel angelegt, aber wirkungslos. Im Test meldete iptables nach dem Speichern keine neue Regel. Erst „Änderungen übernehmen“ schreibt sie auf den Server. Bis dahin können Sie mit „Änderungen verwerfen“ alles zurücknehmen.

„Couldn't connect to server“ trotz Freigabe. Eine allgemeinere Regel steht davor. Neue Regeln landeten im Test auf Position 1. Verschieben Sie Sperrregeln hinter die spezifischen Freigaben.

„Ihre Firewall-Regeln wurden zurückgesetzt, weil Sie sich vom Server ausgesperrt haben.“ Die Anti-Aussperr-Prüfung ist fehlgeschlagen und KeyHelp hat die vorherigen Regeln wiederhergestellt. Kontrollieren Sie die Tabelle, bevor Sie erneut übernehmen.

Firewall versehentlich ausgeschaltet. Der Status „Firewall ist aktiviert“ ist zugleich ein Schalter. Ein Klick schaltete die Firewall im Test ohne Rückfrage ab. Danach stand -P INPUT ACCEPT, und auch Port 3306 (MariaDB, im Test auf allen Adressen lauschend) war vom simulierten Client erreichbar: 3306 offen. Nach dem Wiedereinschalten standen die Regeln wieder in iptables.

Häufige Fragen

Was tun, wenn ich trotzdem ausgesperrt bin?

Melden Sie sich über die Konsole Ihres Hosters als root an und setzen Sie eine zusätzliche Regel an den Anfang der Kette:

iptables -I INPUT 1 -p tcp -m multiport --dports 22,80,443 -j ACCEPT

Im Test stand die Regel danach an erster Stelle in INPUT. Ihre Wirkung konnten wir nicht getrennt nachweisen, weil KeyHelp die Regeln zu diesem Zeitpunkt bereits selbst zurückgesetzt hatte. Korrigieren Sie danach die Regeln im Panel und entfernen Sie die Notfallregel mit iptables -D INPUT -p tcp -m multiport --dports 22,80,443 -j ACCEPT.

Hebelt die Firewall Fail2Ban aus?

Die Firewall-Seite selbst zeigt keine Fail2Ban-Sperren. Im Journal war aber zu sehen, dass KeyHelp nach jedem Übernehmen systemctl restart fail2ban ausführt. Sperren verwalten Sie unter „Sicherheit“, „Fail2Ban-Verwaltung“.

Gilt eine Regel auch für IPv6?

Im Test ja: Die Regel ohne Quelle stand nach dem Übernehmen auch in ip6tables. KeyHelp schreibt dafür eine eigene Datei startup_rules_ipv6.

Testumfang

Wir haben in KeyHelp 26.1.1 eine Freigabe für eine Quelladresse angelegt, die Reihenfolge geprüft, uns bewusst ausgesperrt und den Neustart getestet, mit zwei simulierten Clients im Netzwerk-Namespace auf dem Server. Auffällig: Die Aussperr-Prüfung schützt nur den Panel-Zugang, nicht SSH. Nicht geprüft: echte Verbindungen über das Internet, Regeln mit Netzmasken, ausgehende Regeln und mehrere Aussperr-Durchläufe (die Rücksetzzeit von 63 Sekunden stammt aus einem einzigen Lauf). Testen Sie nach jeder Änderung alle Dienste.

Fazit

Die KeyHelp-Firewall ist eine schlanke Oberfläche für iptables: Bearbeitungsmodus, Regel, Übernehmen. Wichtig sind zwei Dinge. Erstens die Reihenfolge, weil neue Regeln im Test oben landeten und die erste zutreffende Regel gewinnt. Zweitens das Wissen, dass die eingebaute Prüfung „Verhindert Serveraussperrung“ nur den Weg zum Panel absichert. Im Test hat sie ein echtes Aussperren nach 63 Sekunden zurückgenommen, eine gelöschte SSH-Regel aber durchgelassen. Halten Sie deshalb immer einen Konsolenzugang bereit und testen Sie nach jeder Änderung von einem zweiten Rechner aus.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern
• Linux-Server absichern: UFW-Firewall und Fail2ban
• Keyweb: KeyHelp, alle Funktionen im Überblick