firewalld auf Rocky und AlmaLinux richtig konfigurieren

Was firewalld ist und warum Rocky und AlmaLinux es ausliefern

firewalld ist der Firewall-Manager, der standardmäßig unter Rocky Linux, AlmaLinux und den anderen Rebuilds von Red Hat Enterprise Linux (RHEL) installiert wird. firewalld untersucht Pakete nicht selbst. Es verwaltet eine gespeicherte Konfiguration und setzt diese Konfiguration in nftables-Regeln um. Mit einem einzigen Befehl, firewall-cmd, können Sie die Konfiguration ändern, während der Server online bleibt.

Wenn Sie bereits wissen, wie ufw auf einem Ubuntu-VPS funktioniert, kennen Sie die grundlegende Aufgabe. firewalld ergänzt zwei Konzepte, die ufw nicht bietet. Das erste sind Zonen: benannte Richtlinien, denen Pakete zugeordnet werden. Das zweite ist die Trennung zwischen den aktiven und den gespeicherten Regeln. Dafür steht das Flag --permanent. Diese Trennung ist die häufigste Fehlerquelle bei diesem Tool.

Alle folgenden Befehle führen Sie auf Ihrem eigenen Server aus. Testen Sie jede Änderung von einem zweiten Rechner aus. Eine Regel, die auf dem Server korrekt aussieht, kann aus dem Internet trotzdem falsch sein.

SSH öffnen, bevor Sie etwas anderes tun

Bei den meisten Rocky- und AlmaLinux-Installationen ist firewalld bereits vorhanden und aktiv. Die mitgelieferte Konfiguration erlaubt SSH. Einige minimale Cloud-Images enthalten firewalld nicht. Prüfen Sie dies, statt es vorauszusetzen.

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --state

firewall-cmd --state gibt running aus. Wenn der Dienst angehalten ist, antwortet jeder weitere Aufruf von firewall-cmd mit FirewallD is not running und wird mit einem Fehlercode ungleich 0 beendet. Das ist die erste Prüfung, wenn ein Befehl scheinbar überhaupt nichts tut.

Lesen Sie nun, was derzeit erlaubt ist.

sudo firewall-cmd --list-all

Die tatsächliche Ausgabe enthält einige weitere Zeilen. Relevant sind diese:

public (active)
  target: default
  interfaces: eth0
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
  rich rules:

ssh in der Zeile services: ist der Grund, warum Ihre Sitzung weiterhin funktioniert. Fehlt dieser Eintrag, fügen Sie ihn hinzu, bevor Sie etwas anderes ändern. Wenn Sie die Firewall ohne SSH-Regel starten, wird die Sitzung beendet und Sie können sich nicht erneut verbinden.

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

target: default bedeutet, dass ein Paket ohne passende Regel mit einer ICMP-Antwort (Internet Control Message Protocol) vom Typ host-prohibited abgewiesen wird. Ein Client, der einen geschlossenen Port erreicht, sieht daher sofort No route to host. Wenn Sie das Ziel auf DROP setzen, bleibt der Server stattdessen stumm. Scanner warten dann bis zum Timeout.

sudo firewall-cmd --permanent --zone=public --set-target=DROP
sudo firewall-cmd --reload

Beachten Sie die Auswirkungen, bevor Sie dies ausführen: DROP verhindert auch, dass der Server auf ping antwortet. Dadurch bleibt auch Ihre eigene Überwachung stumm.

Warum ist meine Regel verschwunden? Das Flag --permanent

firewalld hält zwei Konfigurationen gleichzeitig vor. Die Runtime-Konfiguration ist die Konfiguration, die der Kernel in diesem Moment erzwingt. Die permanente Konfiguration liegt in /etc/firewalld/zones/public.xml und wird nach einem Reload oder Reboot wieder geladen.

Ein Befehl ohne --permanent ändert nur die Runtime-Konfiguration. Er wirkt sofort und ist beim nächsten Reload oder Boot verschwunden. Ein Befehl mit --permanent schreibt die Datei, ändert aber nichts an der laufenden Konfiguration. Der Port bleibt daher geschlossen, bis Sie einen Reload durchführen. Keine dieser Verhaltensweisen ist ein Fehler. Beide führen häufig zu Verwirrung, weil der Befehl in beiden Fällen success ausgibt.

Geben Sie jedes Mal beide Optionen an.

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --reload

Sie können beide Konfigurationen auslesen. So finden Sie am schnellsten heraus, welcher der beiden Fehler vorliegt.

sudo firewall-cmd --list-services
sudo firewall-cmd --permanent --list-services

Der erste Befehl gibt die aktive Konfiguration aus. Der zweite gibt die gespeicherte Konfiguration aus. Wenn die aktive Konfiguration einen Dienst enthält, der in der gespeicherten Konfiguration fehlt, wird diese Regel beim nächsten Reload entfernt. Wenn die gespeicherte Konfiguration eine Regel enthält, die in der aktiven Konfiguration fehlt, haben Sie den Reload vergessen. sudo firewall-cmd --runtime-to-permanent kopiert die gesamte aktive Konfiguration in die gespeicherte Datei. Das ist nach einer Sitzung mit Tests nützlich.

--reload erhält den Zustand der Connection-Tracking-Tabelle, sodass Ihre SSH-Sitzung bestehen bleibt. --complete-reload lädt zusätzlich die Kernel-Module neu und verwirft diesen Zustand. Dadurch werden normalerweise alle offenen Verbindungen beendet, einschließlich Ihrer eigenen. Verwenden Sie den normalen Reload.

Eine Sicherheitsfunktion ist integriert. Eine Runtime-Regel kann automatisch ablaufen.

sudo firewall-cmd --add-service=http --timeout=5m

Diese Regel entfernt sich nach fünf Minuten selbst. Sie kann nicht mit --permanent kombiniert werden. Genau dafür ist sie vorgesehen: zum Testen einer Änderung, bei der Sie unsicher sind. Die ältere Sicherheitsmaßnahme ist besser. Lassen Sie eine zweite SSH-Sitzung geöffnet, während Sie Regeln bearbeiten. Schließen Sie sie erst, wenn eine neue Anmeldung bestätigt, dass die neuen Regeln funktionieren.

Zonen und warum auf einem VPS nur die Standardzone relevant ist

Eine Zone ist eine benannte Gruppe von Berechtigungen mit einer zugeordneten Vertrauensstufe. firewalld ordnet jedes eingehende Paket genau einer Zone zu. Zuerst vergleicht es die Quelladresse des Pakets mit der sources:-Liste jeder Zone. Wenn keine Übereinstimmung gefunden wird, verwendet es die Zone, an die das eingehende Interface gebunden ist. Wenn das Interface an keine Zone gebunden ist, wird das Paket der Standardzone zugeordnet.

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --get-active-zones

Auf einem VPS mit einem Netzwerk-Interface lautet die erste Antwort fast immer public. Das ist die einzige Zone, die Sie verwenden werden. firewall-cmd ohne das Argument --zone= arbeitet mit der Standardzone. Deshalb funktionieren alle kurzen Befehle in dieser Anleitung ohne Angabe einer Zone.

Dies ist der Fehler, der einen ganzen Nachmittag kosten kann. Wenn das Interface an eine andere Zone gebunden ist, landen Ihre Regeln in public, während der Datenverkehr an anderer Stelle verarbeitet wird. Dadurch hat keine hinzugefügte Regel eine Wirkung, und es wird keine Warnung ausgegeben. --get-active-zones zeigt die Zuordnung:

public
  interfaces: eth0

Wenn das Interface unter einem anderen Zonennamen erscheint, schreiben Sie Ihre Regeln entweder mit --zone= in diese Zone oder verschieben Sie das Interface.

sudo firewall-cmd --permanent --zone=public --change-interface=eth0
sudo firewall-cmd --reload

NetworkManager verwaltet die Interfaces unter Rocky und AlmaLinux und stellt die Zone wieder her, wenn die Verbindung aktiviert wird. Legen Sie die Zuordnung auch dort fest, damit ein Reboot Ihre Änderungen nicht rückgängig macht. Verwenden Sie den Verbindungsnamen aus dem ersten Befehl, da er nur selten mit dem Gerätenamen übereinstimmt.

sudo nmcli connection show
sudo nmcli connection modify "System eth0" connection.zone public

Die Zuordnung anhand der Quelle hat Vorrang vor der Zuordnung anhand des Interfaces. Dadurch kann eine Adresse eine andere Richtlinie erhalten. Die integrierte Zone trusted akzeptiert alles.

sudo firewall-cmd --permanent --zone=trusted --add-source=203.0.113.10/32
sudo firewall-cmd --reload

Seien Sie damit vorsichtig. Dadurch werden alle Ports des Servers für diese Adresse geöffnet, einschließlich der Datenbank, die Ihrer Ansicht nach nur intern erreichbar sein sollte. Verwenden Sie eine Rich Rule, wenn Sie einen einzelnen Port und nicht einen gesamten Host freigeben möchten.

Was ist ein firewalld-Service?

Ein Service ist ein benanntes Port-Bündel, das als XML-Datei bereitgestellt wird. --add-service=https öffnet 443/tcp, weil /usr/lib/firewalld/services/https.xml definiert, was https bedeutet.

sudo firewall-cmd --get-services
sudo firewall-cmd --info-service=https

--info-service gibt die Ports aus, die sich hinter dem Namen verbergen:

https
  ports: 443/tcp

Verwenden Sie den Namen, wenn einer vorhanden ist. Das ist auch sechs Monate später in --list-all eindeutig lesbar, und Pakete wie Cockpit installieren ihre eigene Service-Datei. Verwenden Sie --add-port für alles, wofür keine Definition vorhanden ist.

Der wichtige Punkt: Der ssh-Service bedeutet 22/tcp und nichts anderes. Wenn Sie SSH beim Absichern des SSH-Zugriffs auf dem Server auf einen anderen Port verschoben haben, öffnet --add-service=ssh nicht den tatsächlich verwendeten Port.

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

Bei einer erneuten RHEL-Installation gibt es für diesen Port eine zweite Sperre. SELinux (Security-Enhanced Linux) kennzeichnet Portnummern, und sshd darf nicht an einen Port außerhalb seiner Kennzeichnungen gebunden werden. Der Dienst startet dann nicht, und im Log steht error: Bind to port 2222 on 0.0.0.0 failed: Permission denied.. Kennzeichnen Sie den Port zuerst.

sudo dnf install -y policycoreutils-python-utils
sudo semanage port -a -t ssh_port_t -p tcp 2222

Was ist derzeit geöffnet?

sudo firewall-cmd --list-all
sudo firewall-cmd --list-rich-rules
sudo nft list table inet firewalld | head -n 40

Die ersten beiden Befehle zeigen, welche Regeln firewalld erwartet. Der dritte Befehl liest die Regeln aus, die der Kernel tatsächlich in der von firewalld verwalteten Tabelle hält. Beide Angaben sollten übereinstimmen.

Das ist noch kein Beweis. Testen Sie von einem anderen Rechner aus:

nc -zv 203.0.113.20 443

Führen Sie den Test nicht auf dem Server selbst aus. firewalld akzeptiert alle Verbindungen über das Loopback-Interface, daher ist curl http://localhost:8080 unabhängig von Ihren Regeln erfolgreich. Der Test zeigt, dass der Dienst läuft. Über die Firewall sagt er nichts aus.

Webport freigeben

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

Der letzte Befehl sollte jetzt http https zusätzlich zu den bereits vorhandenen Einträgen anzeigen. Wenn die Website weiterhin nicht antwortet, liegt das Problem möglicherweise nicht an der Firewall. Eine Regel erlaubt ein Paket. Ein Prozess muss weiterhin auf dem Port lauschen.

sudo ss -tlnp

Ein Socket mit 0.0.0.0:443 oder *:443 akzeptiert Verbindungen von jeder Adresse. Ein Socket mit 127.0.0.1:443 antwortet nur auf Loopback-Verbindungen. Keine Firewall-Regel macht ihn von außen erreichbar. Ports und lauschende Sockets unter Linux erläutert diesen Unterschied ausführlicher.

Wie schließe ich einen Port wieder?

sudo firewall-cmd --permanent --remove-service=http
sudo firewall-cmd --reload

Die Regel --permanent gilt auch hier. In dieser Richtung wirkt sie sich noch stärker aus. Entfernen Sie einen Dienst nur aus der Laufzeitkonfiguration, wirkt der Port geschlossen. Beim nächsten Reload oder Reboot wird er jedoch aus der gespeicherten Datei wieder geöffnet. Das ist eine Lücke, die Sie nicht bemerken werden, weil die von Ihnen ausgeführte Prüfung erfolgreich war.

Wenn Sie etwas entfernen, das nie vorhanden war, wird Warning: NOT_ENABLED: http ausgegeben und der Rückgabecode bleibt 0. Wenn Sie dasselbe zweimal hinzufügen, wird Warning: ALREADY_ENABLED: http ausgegeben. Beides ist unkritisch. Ein falsch geschriebener Name ist etwas anderes: Error: INVALID_SERVICE bedeutet, dass firewalld keine Definition mit diesem Namen hat und überhaupt nichts geändert wurde.

Wenn --list-all cockpit anzeigt und Sie die Cockpit-Webkonsole auf Port 9090 nicht verwenden, entfernen Sie es. Jeder offene Port gehört zu einem Dienst, den Sie aktuell halten und patchen müssen.

Einen Port auf eine Quelladresse beschränken

Rich Rules sind die ausführliche Form für Fälle, in denen ein einfacher Dienstname die gewünschte Regel nicht ausdrücken kann. SSH auf eine einzige Büro-Adresse zu beschränken, erfordert zwei Befehle. Der zweite wird häufig vergessen.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" service name="ssh" accept'
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

Eine Zone ist eine Gruppe von Berechtigungen und keine nummerierte Liste, die beim ersten Treffer endet. Die Rich Rule ergänzt eine Freigabe für eine Adresse. Sie verweigert niemandem den Zugriff. Solange ssh noch in der services:-Zeile steht, erreicht weiterhin das gesamte Internet Port 22, und die Rich Rule ändert nichts Messbares. Entfernen Sie den allgemeinen Eintrag. Andernfalls bleibt der spezifische Eintrag wirkungslos.

Wenn für einen Port kein Dienstname vorhanden ist, geben Sie stattdessen den Port an.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" port port="5432" protocol="tcp" accept'

Um ein lautes Netzwerk zu verwerfen und dabei einen Protokolleintrag zu behalten, setzen Sie das log-Element vor die Aktion. Das ist die Reihenfolge, die die Rich-Rule-Syntax erwartet.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="198.51.100.0/24" log prefix="fw-drop " level="info" limit value="3/m" drop'
sudo firewall-cmd --reload
sudo journalctl -k -g fw-drop

Der Wert limit verhindert, dass eine Flut von Paketen das Journal füllt. Bevor Sie SSH auf eine einzige Adresse beschränken, stellen Sie sicher, dass diese Adresse stabil ist. Eine Heimverbindung mit wechselnder IP-Adresse sperrt Sie am Tag der Änderung aus. Testen Sie daher vorher, ob der Konsolenzugriff Ihres Providers funktioniert.

ufw-Befehle und ihre firewall-cmd-Entsprechungen

Gleiche Aufgaben, anderes Werkzeug. Auf jede Zeile mit --permanent muss ein sudo firewall-cmd --reload folgen. Genau das lässt sich in einer solchen Liste nicht darstellen.

• sudo ufw enable wird zu sudo systemctl enable --now firewalld
• sudo ufw disable wird zu sudo systemctl disable --now firewalld
• sudo ufw status verbose wird zu sudo firewall-cmd --list-all
• sudo ufw allow OpenSSH wird zu sudo firewall-cmd --permanent --add-service=ssh
• sudo ufw allow 443/tcp wird zu sudo firewall-cmd --permanent --add-port=443/tcp
• sudo ufw delete allow 443/tcp wird zu sudo firewall-cmd --permanent --remove-port=443/tcp
• sudo ufw allow from 203.0.113.10 to any port 22 wird zur oben gezeigten Rich Rule
• sudo ufw reload wird zu sudo firewall-cmd --reload
• sudo ufw default deny incoming entspricht bereits dem Verhalten der Zone public, und --set-target=DROP ist die lautlose Variante davon
• sudo ufw logging on wird zu sudo firewall-cmd --set-log-denied=all

Ein Unterschied muss klar benannt werden. ufw führt eine nummerierte Liste, und Sie können eine Regel an Position 1 einfügen. firewalld verwendet keine Regelnummern. Daher hat „diese Regel an die erste Stelle setzen“ hier keine Bedeutung. Wenn sich zwei firewalld-Einträge scheinbar widersprechen, setzt sich die allgemeine Allow-Regel durch, weil keine Regel in der Menge den Zugriff verweigert. Den allgemeinen Eintrag müssen Sie selbst entfernen.

Warum ist mein Docker-Container erreichbar, obwohl die Firewall scheinbar geschlossen ist?

Ein veröffentlichter Container-Port erreicht den von Ihrer Zone kontrollierten Teil der Firewall nicht. docker run -d -p 8080:80 nginx weist Docker an, eigene NAT- (Network Address Translation) und Weiterleitungsregeln zu schreiben. Ein auf 8080 eintreffendes Paket wird umgeschrieben und an den Container weitergeleitet. Es wird daher weitergeleitet, statt an den Host zugestellt zu werden. Die Zeilen services: und ports: in Ihrer Zone steuern Pakete, die an den Host zugestellt werden. Die Regeln von Docker steuern den Weiterleitungspfad und akzeptieren diese Pakete.

Das Ergebnis ist ein Server, auf dem sudo firewall-cmd --list-all keinen Port 8080 anzeigt, während nc -zv 203.0.113.20 8080 von einem anderen Rechner trotzdem eine Verbindung herstellt. Prüfen Sie, welche Regeln Docker installiert hat:

sudo iptables -t nat -L DOCKER -n

Die Lösung liegt im Publish-Flag. Binden Sie den Port an Loopback und setzen Sie einen Reverse Proxy davor.

docker run -d -p 127.0.0.1:8080:80 nginx

Der Container antwortet jetzt auf curl http://127.0.0.1:8080 auf dem Server, aber auf keine Anfrage von außerhalb. Ubuntu-Benutzer stoßen auf dasselbe Problem. Es wird unter warum Docker-Container Ports direkt an ufw vorbei veröffentlichen beschrieben. Rootful Podman, das Rocky und AlmaLinux in den Basis-Repositorys ausliefern, veröffentlicht Ports mit demselben NAT-Verfahren. Testen Sie daher von einem anderen Rechner, statt der Zonenliste zu vertrauen.

Das System nach einem Reboot wiederherstellen und typische Fehler

sudo systemctl is-enabled firewalld
sudo systemctl status firewalld

enabled und active (running) sind die gewünschten Einstellungen. Eine laufende, aber nicht aktivierte Firewall schützt den Server nur bis zum ersten Reboot. Diese Prüfung gehört neben SSH-Schlüsseln und Updates auf die Liste, die Sie in den ersten zehn Minuten auf einem neuen VPS abarbeiten.

Raw-nftables-Befehle und firewalld lassen sich nicht kombinieren. firewalld verwaltet eine Tabelle namens inet firewalld. sudo nft flush ruleset löscht diese Tabelle. Der Server ist danach für sämtlichen Datenverkehr offen. firewall-cmd --list-all zeigt weiterhin Ihre vorgesehene Konfiguration an, weil firewalld meldet, was es erwartet, und nicht, was im Kernel tatsächlich vorhanden ist. sudo firewall-cmd --reload installiert die Regeln erneut. Schreiben Sie Regeln mit firewall-cmd, damit sie nach einem Reload wiederhergestellt werden.

Zwei Firewall-Manager auf einem Server. Wenn Sie ufw oder iptables-services neben firewalld installieren, schreiben zwei voneinander unabhängige Programme Regeln. Welches Programm sich durchsetzt, hängt davon ab, welcher Dienst zuletzt gestartet wurde. Verwenden Sie nur einen Manager. Auf Rocky und AlmaLinux wird firewalld von der Distribution unterstützt.

Die Provider-Firewall vor dem Server. Viele VPS-Panels haben eine separate Netzwerk-Firewall. Wenn --list-all einen Port als offen anzeigt und eine Verbindung von außen trotzdem fehlschlägt, prüfen Sie zuerst das Panel, bevor Sie etwas auf dem Server ändern. Das gilt auch umgekehrt: Eine offene Regel im Panel hat keine Wirkung, wenn firewalld das Paket ablehnt.

firewall-cmd ohne sudo ausführen. Jede Änderung erfordert root. Ohne root wird die Anfrage durch eine Berechtigungsprüfung abgelehnt und nichts geändert. Auf den ersten Blick sieht es dadurch so aus, als hätte der Befehl keine Wirkung gehabt.

Sechs Befehle decken die meisten Fälle ab: --list-all zum Anzeigen des Status, --permanent --add-service oder --add-port zum Öffnen eines Ports, --permanent --remove-service zum Schließen eines Ports, --reload zum Anwenden der gespeicherten Datei und --runtime-to-permanent nach einer Reihe von Tests. Die Zone ist public, das Flag ist --permanent, und die einzige verlässliche Prüfung erfolgt von einem anderen Rechner aus.

FAQ

Warum ist meine firewalld-Regel nach einem Reboot verschwunden?

Die Regel wurde nur in die Laufzeitkonfiguration übernommen. sudo firewall-cmd --add-service=http wird sofort angewendet und beim nächsten Reload oder Boot verworfen, weil die gespeicherte Konfiguration in /etc/firewalld/zones/public.xml nie geändert wurde. Fügen Sie --permanent hinzu und führen Sie anschließend sudo firewall-cmd --reload aus. Um bereits manuell hinzugefügte Regeln beizubehalten, führen Sie sudo firewall-cmd --runtime-to-permanent aus. Dadurch wird der aktive Regelsatz in die gespeicherte Datei kopiert.

Warum ändert sich nichts, nachdem ich eine Regel mit --permanent hinzugefügt habe?

Weil --permanent die Datei schreibt, die laufende Firewall aber unverändert lässt. Der Port bleibt geschlossen, bis sudo firewall-cmd --reload die gespeicherte Konfiguration in den Kernel lädt. Vergleichen Sie sudo firewall-cmd --list-services mit sudo firewall-cmd --permanent --list-services. Wenn die gespeicherte Liste einen Eintrag enthält, der in der aktiven Liste fehlt, fehlt der Reload.

Sollte ich --add-service oder --add-port verwenden?

Verwenden Sie --add-service, wenn für den von Ihnen ausgeführten Dienst ein Name vorhanden ist. Damit wird die Absicht angegeben, und sudo firewall-cmd --info-service=https zeigt genau, welche Ports dieser Name abdeckt. Verwenden Sie --add-port, wenn für Ihren Dienst keine Definition vorhanden ist oder wenn er auf einem nicht standardmäßigen Port lauscht. Der Dienst ssh bedeutet ausschließlich 22/tcp. Wenn SSH auf 2222 verschoben wurde, benötigen Sie daher --add-port=2222/tcp sowie ein SELinux-Label für diesen Port.

Warum ist mein Docker-Container erreichbar, obwohl firewalld den Port als geschlossen anzeigt?

Ein veröffentlichter Port wird durch die eigenen NAT-Regeln von Docker umgeschrieben und an den Container weitergeleitet. Das Paket wird daher nie an den Host zugestellt. Die Service- und Portlisten einer Zone gelten nur für Pakete, die an den Host zugestellt werden. Der Container antwortet aus dem Internet, während --list-all nichts anzeigt. Veröffentlichen Sie den Port stattdessen auf dem Loopback-Interface mit docker run -d -p 127.0.0.1:8080:80 nginx und schalten Sie einen Reverse Proxy davor.

Kann ich unter Rocky Linux anstelle von firewalld ufw installieren?

Zwei Firewall-Manager auf einem Server schreiben Regeln, ohne voneinander zu wissen. Welche Regeln bestehen bleiben, hängt davon ab, welcher Dienst zuletzt gestartet wurde. firewalld ist das unterstützte Werkzeug unter Rocky Linux und AlmaLinux. Es ist bereits installiert und verwendet dasselbe nftables-Backend, das auch ufw verwenden würde. Wenn Sie die Standardzone und das Flag --permanent einmal kennen, beherrschen Sie das gesamte Werkzeug.