firewalld auf Rocky und AlmaLinux richtig konfigurieren

Was firewalld ist und warum Rocky und AlmaLinux es ausliefern

firewalld ist der Firewall-Manager, der bei Rocky Linux, AlmaLinux und den anderen Rebuilds von Red Hat Enterprise Linux (RHEL) standardmäßig installiert ist. Beide Distributionen haben diese Voreinstellung übernommen, statt selbst eine Auswahl zu treffen. Das wird verständlicher, wenn Sie wissen, wie Rocky und AlmaLinux nach der Neuausrichtung von CentOS die Arbeit von Red Hat neu aufbauten. firewalld untersucht Pakete nicht selbst. Es verwaltet eine gespeicherte Konfiguration und setzt diese Konfiguration in nftables-Regeln um. Der Befehl firewall-cmd ändert die Konfiguration, während der Server online bleibt. In dieser Anleitung gibt es zwischen den beiden Distributionen keine Unterschiede, weil die tatsächlichen Unterschiede zwischen Rocky und AlmaLinux in der Kompatibilitätszusage und im Umfang der weiterhin unterstützten CPUs liegen, nicht in der Firewall.

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

Alles Folgende sind Befehle, die Sie auf Ihrem eigenen Server ausführen. Testen Sie jede Änderung von einem zweiten Rechner aus. Eine Regel kann auf dem Server korrekt aussehen und 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 jedoch nicht. Prüfen Sie den Zustand, statt ihn vorauszusetzen.

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

firewall-cmd --state gibt running aus. Wenn der Dienst gestoppt ist, beantwortet jeder weitere Aufruf von firewall-cmd die Anfrage mit FirewallD is not running und wird mit einem Status ungleich null 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 der Eintrag, fügen Sie ihn hinzu, bevor Sie etwas anderes ändern. Wenn Sie eine 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, auf das keine Regel zutrifft, 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 eine Zeitüberschreitung eintritt.

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

Berücksichtigen Sie diese Konsequenz, bevor Sie den Befehl 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 verwaltet zwei Konfigurationen gleichzeitig. Die Laufzeitkonfiguration wird in diesem Moment vom Kernel angewendet. Die permanente Konfiguration befindet sich in /etc/firewalld/zones/public.xml und wird nach einem Reload oder Reboot wiederhergestellt.

Ein Befehl ohne --permanent ändert nur die Laufzeitkonfiguration. Die Änderung 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 das Paar jedes Mal an.

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

Sie können beide Konfigurationen auslesen. So lässt sich am schnellsten feststellen, welchen der beiden Fehler Sie gemacht haben.

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 einen Dienst enthält, der 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 Testphase nützlich.

--reload behält den Zustand der Verbindungsverfolgung bei, 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 bereits integriert. Eine Laufzeitregel 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 zugehörigen 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 vorliegt, verwendet es die Zone, der das eingehende Interface zugeordnet ist. Ist das Interface keiner Zone zugeordnet, 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 Argument --zone= arbeitet mit der Standardzone. Deshalb funktionieren alle kurzen Befehle in dieser Anleitung, ohne eine Zone anzugeben.

Das ist der Fehler, der einen Nachmittag kostet. Wenn das Interface einer anderen Zone zugeordnet 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 dort mit --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. Beim Aktivieren der Verbindung stellt er die Zone erneut her. Legen Sie die Zone daher auch dort fest, damit ein Reboot Ihre Änderungen nicht rückgängig macht. Übernehmen 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 Quelladresszuordnung hat Vorrang vor der Interface-Zuordnung. 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 Sie für intern erreichbar hielten. Verwenden Sie eine Rich Rule, wenn Sie einen einzelnen Port statt eines einzelnen Hosts freigeben möchten.

Was ist ein firewalld-Service?

Ein Service ist ein benanntes Portbü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 eine Definition vorhanden ist. Dadurch bleibt --list-all auch sechs Monate später verständlich. Pakete wie Cockpit installieren außerdem ihre eigene Service-Datei. Verwenden Sie --add-port für alles, wofür keine Definition vorhanden ist.

Wichtig ist folgende Einschränkung: Der ssh-Service bedeutet 22/tcp und nichts anderes. Wenn Sie SSH auf einen anderen Port verschoben haben, während Sie den SSH-Zugriff auf dem Server absicherten, öffnet --add-service=ssh nicht den tatsächlich verwendeten Port.

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

Bei einer RHEL-Neuinstallation gibt es eine zweite Sperre für diesen Zugriff. SELinux (Security-Enhanced Linux) versieht Portnummern mit Labels. sshd darf nicht an einen Port außerhalb dieser Labels gebunden werden. Der Dienst startet dann nicht, und im Log steht error: Bind to port 2222 on 0.0.0.0 failed: Permission denied.. Weisen Sie dem Port zuerst das richtige Label zu.

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

Wie sehe ich, was derzeit geöffnet ist?

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, was firewalld für aktiv hält. Der dritte Befehl liest die Regeln, die tatsächlich im Kernel vorhanden sind, und zwar aus der Tabelle, die firewalld verwaltet. Beide Angaben sollten übereinstimmen.

Das ist jedoch 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 alles, was über das Loopback-Interface eingeht. Daher ist curl http://localhost:8080 unabhängig von Ihren Regeln erfolgreich. Der Test zeigt, dass der Dienst erreichbar ist. Ü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 nun http https zusammen mit den zuvor angezeigten Einträgen auflisten. Wenn die Website weiterhin nicht antwortet, liegt das Problem möglicherweise nicht an der Firewall. Eine Regel lässt ein Paket passieren. Ein Prozess muss jedoch weiterhin auf diesem 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 dagegen nur auf Loopback-Verbindungen. Keine Firewall-Regel macht ihn von außen erreichbar. Ports und lauschende Sockets unter Linux erklärt 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, und in dieser Richtung wirkt sie sich noch stärker aus. Entfernen Sie einen Dienst nur aus der Laufzeitkonfiguration, wirkt der Port zunächst geschlossen. Beim nächsten Reload oder Reboot wird er 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.

Beim Entfernen eines Eintrags, der nicht vorhanden war, wird Warning: NOT_ENABLED: http ausgegeben. Der Befehl endet trotzdem mit dem Exit-Code 0. Beim zweimaligen Hinzufügen desselben Eintrags 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 kennt und überhaupt nichts geändert wurde.

Wenn --list-all cockpit anzeigt und Sie die Cockpit-Webkonsole nicht auf Port 9090 verwenden, entfernen Sie den Eintrag. Jeder offene Port gehört zu einem Dienst, den Sie aktuell halten müssen. Für die Dienste, die Sie behalten, kann dnf-automatic die Sicherheitsupdates zeitgesteuert installieren, sodass diese Aufgabe nicht davon abhängt, dass Sie daran denken. Die Installation eines Patches bedeutet jedoch nicht, dass der Dienst ihn bereits verwendet. needs-restarting zeigt, welche Dienste noch die alten Bibliotheken verwenden, sobald diese Updates installiert sind.

Einen Port auf eine Quelladresse beschränken

Rich Rules sind die ausführliche Syntax. Sie wird benötigt, wenn ein einfacher Servicename die gewünschte Regel nicht ausdrücken kann. Um SSH auf eine Büroadresse zu beschränken, sind zwei Befehle erforderlich. 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. Sie ist keine nummerierte Liste, die beim ersten Treffer endet. Die Rich Rule erlaubt Verbindungen von einer Adresse. Sie verweigert keine anderen Verbindungen. Solange ssh weiterhin in der services:-Zeile steht, erreicht das gesamte Internet weiterhin Port 22. Die Rich Rule ändert dann nichts Messbares. Entfernen Sie den allgemeinen Eintrag. Andernfalls ist die engere Regel wirkungslos.

Bei einem Port ohne Servicename geben Sie den Port stattdessen direkt 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 störendes Netzwerk zu verwerfen und dabei einen Eintrag zu protokollieren, setzen Sie das Log-Element vor die Aktion. Dies ist die von der Rich-Rule-Syntax erwartete Reihenfolge.

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 einzelne Adresse beschränken, stellen Sie sicher, dass diese Adresse stabil ist. Bei einem Heimanschluss mit wechselnder IP-Adresse werden Sie an dem Tag ausgesperrt, an dem sie sich ändert. Testen Sie daher zuvor den Konsolenzugriff Ihres Providers und stellen Sie sicher, dass er funktioniert.

ufw-Befehle und ihre firewall-cmd-Entsprechungen

Gleiche Aufgaben, anderes Werkzeug. Auf jede --permanent-Zeile muss eine sudo firewall-cmd --reload-Zeile folgen. Genau das kann eine solche Liste nicht zeigen.

• 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 zu der 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 stille 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. „Diese Regel an die erste Stelle setzen“ hat hier daher keine Bedeutung. Wenn sich zwei firewalld-Einträge scheinbar widersprechen, gewinnt die allgemeine Allow-Regel, weil in der Regelmenge keine Deny-Regel vorhanden ist. Den allgemeinen Eintrag müssen Sie selbst entfernen.

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

Weil ein veröffentlichter Container-Port den Teil der Firewall, den Ihre Zone steuert, nie erreicht. docker run -d -p 8080:80 nginx weist Docker an, eigene NAT- (Network Address Translation) und Weiterleitungsregeln zu schreiben. Ein an Port 8080 eintreffendes Paket wird umgeschrieben und an den Container weitergeleitet. Es wird daher weitergeleitet und nicht an den Host zugestellt. Die Zeilen services: und ports: in Ihrer Zone steuern Pakete, die an den Host zugestellt werden. Dockers Regeln 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, was 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. Von außerhalb ist er nicht erreichbar. Ubuntu-Nutzer stoßen auf dasselbe Problem, das in warum Docker-Container Ports direkt an ufw vorbei veröffentlicht beschrieben wird. Rootful Podman, das Rocky und AlmaLinux in den Basis-Repositories bereitstellen, veröffentlicht Ports ebenfalls über NAT. Testen Sie daher von einem anderen Rechner, statt der Zonenliste zu vertrauen. Diese Überschneidung ist auch der Grund, warum die Installation von Docker Engine auf diesen Distributionen einige Schritte erfordert, die in einer Ubuntu-Anleitung nicht erwähnt werden. Dazu gehört zunächst, dass Podman bereits den Befehl docker belegt.

Einen Reboot überstehen und die auftretenden 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 auf die Liste, die Sie in den ersten zehn Minuten auf einem neuen VPS durcharbeiten, zusammen mit SSH-Schlüsseln und Updates.

Rohe 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 dann für sämtlichen Netzwerkverkehr offen. firewall-cmd --list-all zeigt weiterhin Ihre beabsichtigte Konfiguration an, weil firewalld seinen eigenen Zustand meldet und nicht den Zustand des Kernels. 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 zusätzlich zu firewalld installieren, schreiben zwei Programme Regeln, ohne voneinander zu wissen. Welches Programm sich durchsetzt, hängt davon ab, welcher Dienst zuletzt gestartet wurde. Verwenden Sie nur einen Firewall-Manager. Auf Rocky und AlmaLinux wird firewalld von der Distribution unterstützt.

Die Provider-Firewall vor dem Server. Viele VPS-Panels verfügen über eine separate Netzwerk-Firewall. Wenn --list-all einen Port als offen anzeigt, eine Verbindung von außen aber weiterhin fehlschlägt, prüfen Sie zuerst das Panel, bevor Sie etwas am Server ändern. Das gilt auch umgekehrt: Eine offene Regel im Panel bewirkt nichts, wenn firewalld das Paket ablehnt.

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

Sechs Befehle decken die meisten Fälle ab: --list-all zum Anzeigen des Status, --permanent --add-service oder --add-port zum Öffnen eines Ports oder Dienstes, --permanent --remove-service zum Schließen, --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 nicht geändert wurde. Fügen Sie --permanent hinzu und führen Sie anschließend sudo firewall-cmd --reload aus. Um Regeln zu speichern, die Sie bereits manuell hinzugefügt haben, führen Sie sudo firewall-cmd --runtime-to-permanent aus. Dadurch wird der aktuelle Regelsatz in die gespeicherte Datei übernommen.

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

Weil --permanent die Datei schreibt und die laufende Firewall 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 Laufzeitliste fehlt, ist der Reload erforderlich.

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

Verwenden Sie --add-service, wenn für den von Ihnen betriebenen Dienst ein Name vorhanden ist. Dadurch wird die Absicht eindeutig 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 an einem nicht standardmäßigen Port lauscht. Der Dienst ssh erlaubt nur 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 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 nur auf der Loopback-Adresse mit docker run -d -p 127.0.0.1:8080:80 nginx und setzen Sie einen Reverse Proxy davor.

Kann ich ufw anstelle von firewalld auf Rocky Linux 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 auf Rocky Linux und AlmaLinux. Es ist bereits installiert und verwendet dasselbe nftables-Backend wie ufw. Wenn Sie die Standardzone und das Flag --permanent einmal kennen, beherrschen Sie das gesamte Werkzeug.