So konfigurieren Sie die SLES 15 Firewall mit firewall-cmd

Ein Dienst kann auf einem SLES 15-Server laufen und dennoch für Remote-Clients eine Zeitüberschreitung verursachen, weil die Firewall neuen eingehenden Datenverkehr blockiert. Die Lösung besteht üblicherweise darin, die aktive Firewall-Zone zu identifizieren und nur den Dienst oder Port zuzulassen, den die Anwendung benötigt. Das SLES-Befehlszeilentool für diese Aufgabe ist [Befehl einfügen] firewall-cmd.

Diese Anleitung orientiert sich an SUSEs „SLES 15 SP7 Security and Hardening Guide“ und der firewalld-Befehlsreferenz (Stand: 7. Oktober 2026). Ältere Service Packs und aktualisierte SLES 12-Systeme können abweichende Zustände oder veraltete Firewall-Konfigurationen aufweisen. Die Terminalabbildungen zeigen beispielhafte Ergebnisse und keine Messungen von einem realen Server. Ersetzen Sie Schnittstellennamen, Zonen und Dienste durch die entsprechenden Werte Ihres Hosts.

1. Überprüfen Sie, ob firewalld ausgeführt wird.

SUSE dokumentiert, dass firewalld unter SLES 15 standardmäßig installiert und aktiviert ist. YaST startet es normalerweise nach der Installation und ordnet die Schnittstellen der Standardzone zu public. Überprüfen Sie dennoch die Einstellungen des Systems, anstatt davon auszugehen, dass sich die Standardeinstellungen nicht geändert haben. Führen Sie die folgenden Befehle mit einem Konto aus, das über die entsprechenden Berechtigungen verfügt sudo:

sudo systemctl status firewalld
sudo firewall-cmd --state

Der Dienstmanager sollte melden, dass der firewalldDienst aktiv ist, und firewall-cmd --statesollte dies auch melden running. Wenn der Dienst installiert, aber gestoppt ist, starten Sie ihn und aktivieren Sie ihn beim Systemstart.

sudo systemctl enable --now firewalld

Falls firewall-cmddie Datei fehlt, prüfen Sie, ob das firewalldPaket installiert und in den aktivierten SUSE-Repositories verfügbar ist. Installieren oder ersetzen Sie Firewall-Komponenten auf einem verwalteten Server nicht ohne Weiteres.

2. Ermitteln Sie die Zone, die die Serverschnittstelle schützt.

Firewalld gruppiert Regeln in Zonen , die unterschiedliche Vertrauensstufen repräsentieren. publicZonen werden üblicherweise für Netzwerke verwendet, denen nicht vertraut wird. Ein in einer Zone geöffneter Dienst ist nicht automatisch in allen Zonen verfügbar. Daher kann eine korrekte Regel in der falschen Zone dazu führen, dass Ihre Anwendung nicht erreichbar ist.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone
sudo firewall-cmd --zone=public --list-all

Verwenden Sie die Ausgabe von „activezone“, um die Zone zu ermitteln, die der Schnittstelle zugeordnet ist, über die der Client-Datenverkehr läuft. Der Schnittstellenname kann beispielsweise „“ eth0oder ens160ein anderer Name sein. Um eine einzelne Schnittstelle zu überprüfen, führen Sie folgenden Befehl aus:

sudo firewall-cmd --get-zone-of-interface=eth0

Ersetzen Sie dies eth0durch die tatsächliche Schnittstelle. Schnittstellen, die keiner Zone explizit zugewiesen sind, werden von der Standardzone verwaltet. Ändern Sie die Standardzone nicht ohne Weiteres, da dies Auswirkungen auf davon abhängige Schnittstellen haben kann. Ermitteln Sie auf einem Remote-Server die SSH- oder andere Verwaltungszone und überprüfen Sie deren Zugriffsregel, bevor Sie die Firewall-Einstellungen neu laden. Halten Sie einen Konsolen- oder Out-of-Band-Wiederherstellungspfad bereit, falls vorhanden.

3. Wählen Sie einen benannten Dienst oder einen bestimmten Port aus.

Ein firewalld -Dienst ist eine benannte Definition, die einen oder mehrere Ports und Protokolle umfassen kann. Es ist in der Regel einfacher, einen bekannten Dienst anhand seines Namens zuzulassen, als sich seine Portnummer zu merken. Überprüfen Sie die Liste der installierten Dienste und prüfen Sie eine Definition, bevor Sie sie verwenden.

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

Bei einem Webserver httpdeckt der vordefinierte Dienst typischerweise TCP-Port 80 ab; httpsfür TLS-Webverkehr gibt es einen separaten Dienst. Die SLES-Dokumentation beschreibt dieselbe dienstbasierte Methode anhand von Beispielen wie DHCP. Verwenden Sie den Dienst, den Ihre Anwendung tatsächlich benötigt, und überprüfen Sie die Dienstdefinition lokal, wenn Sie sich unsicher sind.

Wenn kein vordefinierter Dienst passt, öffnen Sie nur den benötigten Port und das Protokoll. Beispielsweise kann eine Anwendung, die auf TCP-Port 8443 lauscht, zugelassen werden --add-port=8443/tcp. Das Öffnen eines Ports in der Firewall startet keine Anwendung, bindet sie nicht an das Netzwerk und macht sie auch nicht sicherer; stellen Sie sicher, dass der Dienst selbst so konfiguriert ist, dass er auf der vorgesehenen Adresse lauscht.

Testen Sie zuerst eine temporäre Regel.

Für einen kurzen Test wenden Sie eine Regel auf die Laufzeitkonfiguration an. Laufzeitänderungen werden sofort wirksam, gehen jedoch nach einem Neustart der Firewall oder des Dienstes verloren, sofern Sie sie nicht zusätzlich dauerhaft speichern. Firewalld unterstützt zeitlich begrenzte Regeln, die nützlich sind, wenn ein Test automatisch ablaufen soll.

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

Verwenden Sie für einen einmaligen Porttest --add-port=8443/tcp --timeout=5manstelle von --add-service=http. Wählen Sie die Zone aus, die tatsächlich die Serverschnittstelle enthält; kopieren Sie nicht, publicwenn Ihr Host eine andere Zone verwendet.

4. Speichern Sie die Regel und laden Sie firewalld neu.

Wenn Sie eine Regel beibehalten möchten, fügen Sie sie der permanenten Konfiguration hinzu. Das folgende Beispiel erlaubt HTTP in der öffentlichen Zone:

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

Für HTTPS wiederholen Sie den permanenten Befehl mit --add-service=https. Für einen benutzerdefinierten Anwendungsport verwenden Sie einen Befehl wie beispielsweise:

sudo firewall-cmd --permanent --zone=public --add-port=8443/tcp
sudo firewall-cmd --reload

Diese Beispiele ändern zunächst die permanente Konfiguration und laden sie anschließend neu, damit die neue Regel aktiv wird. Beim Neuladen werden auch die Laufzeiteinstellungen durch die permanente Konfiguration ersetzt. Änderungen, die nur zur Laufzeit vorgenommen wurden, können daher verworfen werden. Überprüfen Sie vor dem Neuladen eines Produktivsystems wichtige Laufzeit- und permanente Regeln, insbesondere den Fernadministrationszugriff.

Es gibt auch einen Workflow, der die Laufzeit in den Vordergrund stellt: Testen Sie eine Regel zur Laufzeit, bestätigen Sie die Funktionsfähigkeit des Dienstes und fügen Sie dann dieselbe Regel erneut hinzu --permanentund laden Sie die Anwendung neu. Vermeiden Sie es, diese Methode --runtime-to-permanentals Abkürzung zu verwenden, es sei denn, Sie möchten alle aktuellen Laufzeitregeln speichern, einschließlich temporärer Änderungen, die von anderen Administratoren oder Software vorgenommen wurden.

Wie lässt sich überprüfen, ob die Änderung funktioniert hat?

Überprüfen Sie sowohl die aktive Laufzeitregel als auch die gespeicherte Regel. Führen Sie für einen HTTP-Dienst in der öffentlichen Zone folgenden Befehl aus:

sudo firewall-cmd --zone=public --query-service=http
sudo firewall-cmd --permanent --zone=public --list-services
sudo firewall-cmd --check-config

Die Abfrage sollte ein Ergebnis liefern yes, die Liste der permanenten Dienste sollte den Eintrag enthalten http, und die Konfigurationsprüfung sollte erfolgreich abgeschlossen werden. Verwenden Sie für eine Portregel die entsprechenden Befehle `--port` --query-port=8443/tcpund --list-ports`--port`. Testen Sie außerdem von einem separaten Client aus, der den Server erreichen kann. Eine lokale Firewall-Abfrage bestätigt das Vorhandensein der Regel, nicht aber die Korrektheit von DNS, Routing, Upstream-Firewalls oder dem Anwendungslistener.

Häufige Probleme und sichere Lösungen

• Die Regel ist vorhanden, aber die Verbindungen schlagen weiterhin fehl: Stellen Sie sicher, dass sie der Zone hinzugefügt wurde, die mit der Client-Schnittstelle verbunden ist. Überprüfen Sie anschließend, ob die Anwendung auf der erwarteten Adresse und dem erwarteten Port lauscht, und prüfen Sie die vorgelagerte Netzwerk-Firewall.
• Die Regel funktionierte bis zum nächsten Seitenaufruf: Sie wurde wahrscheinlich nur zur Laufzeit hinzugefügt. Fügen Sie sie erneut hinzu, --permanentladen Sie die Seite neu und überprüfen Sie anschließend beide Konfigurationen.
• Der SSH-Zugriff ist gefährdet: Überprüfen Sie vor dem Neuladen die Dienste der aktiven Zone sowie die permanenten Dienste. Falls SSH erforderlich ist und fehlt, fügen Sie den sshDienst vor dem Neuladen dauerhaft zur entsprechenden Zone hinzu. Schließen Sie Ihre aktuelle Remote-Sitzung erst, nachdem Sie eine zweite Verbindung getestet haben.
• Sie migrieren von einer älteren SUSE-Version: SLES 15 hat SuSEfirewall2 durch firewalld ersetzt. SUSE weist darauf hin, dass ältere Firewall-Profile nur eingeschränkt abwärtskompatibel sind. Lesen Sie daher unbedingt den Migrationsleitfaden, anstatt davon auszugehen, dass alle älteren Regeln übersetzt wurden.
• Es scheint einen Regelkonflikt zu geben: firewalld ist für die Verwaltung der Firewall-Regeln des Hosts zuständig. SUSE warnt davor, dieselben Regeln separat mit Tools wie z. B. zu ändern iptables, da dies die aktive Konfiguration durcheinanderbringen kann.

Um einen unnötigen permanenten Dienst oder Port zu entfernen, verwenden Sie die entsprechende --remove-serviceOption --remove-portmit --permanent, laden Sie die Seite anschließend neu und überprüfen Sie die Einstellungen erneut. Entfernen Sie beispielsweise HTTP aus der öffentlichen Zone mit , sudo firewall-cmd --permanent --zone=public --remove-service=httpgefolgt von sudo firewall-cmd --reload.

Führen Sie vor dem Fertigstellen einen Selbsttest durch.

• firewalldläuft und startet beim Hochfahren des Servers.
• Sie haben die aktive Zone für die Schnittstelle identifiziert, die Datenverkehr empfängt.
• In dieser Zone ist nur der Dienst oder Port zugelassen, den die Anwendung benötigt.
• Die Fernadministration ist sowohl vor als auch nach dem Neustart weiterhin möglich.
• Die Regel erscheint in Laufzeit- und permanenten Abfragen, und die Konfigurationsprüfung ist erfolgreich.
• Ein Verbindungstest von einem anderen Host bestätigt, dass die Anwendung erreichbar ist.

Für versionsspezifische Details siehe den SUSE SLES 15 SP7 Firewall-Leitfaden , das firewall-cmd-Handbuch und die firewalld-Hinweise zur Laufzeit- und permanenten Konfiguration sowie zum Öffnen eines Ports oder Dienstes .