FirewallD in a nutshell 101

Mit FirewallD gibt es in einigen Linux-Distributionen eine neue Standard-Firewall, die sich von vorherigen Schnittstellen unterscheidet. Dieser Artikel beschäftigt sich mit dem grundgelegenen Konzept und Praxisbeispielen.

Der auffälligste Unterschied dürfte sein, dass die Firewall nun Änderungen in Echtzeit ohne Unterbrechung aktiver Verbindungen unterstützt. Dabei integriert sich FirewallD nahtlos in D-Bus, was es Anwendungen und Services erleichtert, Firewall-Konfigurationen auszulesen und zu steuern. Darüber hinaus sind zahlreiche vordefinierte Zonen und Services vorhanden, was eine schnelle Konfiguration ermöglicht.

Mithilfe des –timeout-Schalter können Firewall-Regeln zeitlich limitiert werden. So kann beispielsweise eine Regel erstellt werden, die für eine Installation temporär einen Dienst erlaubt. Mithilfe des Lockdown-Modus können nur bestimmte Anwendungen zur Steuerung der Firewall (per D-Bus) berechtigt werden. Gegenüber vorherigen Alternativen integriert sich FirewallD nahtlos in Puppet und bietet auch einen XML-Export zur Weitergabe von Firewall-Konfigurationen (zugegebenermaßen wären mir hier JSON oder YAML jedoch lieber).

FirewallD steht für verschiedene Plattformen zur Verfügung, unter anderem:

  • RHEL 7 bzw. darauf basierende Ableger (CentOS, Scientific Linux)
  • Fedora 18 und neuer
  • SUSE Linux Enterprise Server 15
  • optional für Ubuntu 14.04, Debian 8, openSUSE 42.2 und neuer

Prinzipiell gibt es mit firewall-config auch ein grafisches Konfigurationswerkzeug, ich beschränke mich im folgenden Artikel jedoch auf das Kommandozeilen-Werkzeug firewall-cmd.

Zonen

Unter einer Zone versteht FirewallD ein Level, welches erlaubte Dienste, Ports und anderes Verhalten (beispielsweise Standard-Aktionen bei nicht gestatteten Zugriffen) definiert. Es gibt zahlreiche Vorkonfigurationen, die oftmals direkt übernommen werden können.

Eine Liste verfügbarer Zonen kann wie folgt eingesehen werden:

# firewall-cmd --get-zones
block dmz drop external home internal public trusted work

Einige der verfügbaren Zonen weisen ähnliche Charakteristika auf – ein Vergleich:

Zone Standard-Aktion Charakteristiska Aktivierte Dienste
block REJECT Nur Antworten ausgehender Anfragen erlaubt keine
drop DROP Nur ausgehender Verkehr erlaubt
dmz keine Lediglich definierte Ausnahmen zulässig ssh
external
public ssh, dhcpv6-client
home ssh, mdns, samba-client, dhcpv6-client
internal
work ssh, dhcpv6-client
trusted ACCEPT Alle Zugriffe erlaubt alle

Zwischen REJECT und DROP gibt es seitens des Kernels einen großen Unterschied. Während bei einem REJECT die Gegenstelle erfährt, dass der Port nicht erreichbar ist, resultiert ein DROP in einem Timeout. DROP wird gerne in öffentlichen Netzen (z.B. DMZ) verwendet, um Port-Scanning zu erschweren.

Aktive Zonen lassen sich mit dem folgenden Kommando auflisten:

# firewall-cmd --get-active-zones
public
  interfaces: ens33

Alternativ kann auch die zugewiesene Zone pro Netzwerkkarte aufgelistet werden:

# firewall-cmd --get-zone-of-interface=ens33
public

Jede Zone hat zahlreiche Eigenschaften, wie beispielsweise aktivierte Dienste und geöffnete Ports:

# firewall-cmd --info-zone home
home (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens33
  sources: 
  services: ssh mdns samba-client dhcpv6-client
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

Das Ändern einer Zone gelingt mit dem folgenden Aufruf:

# firewall-cmd --set-default-zone=home
success

Runtime und Permanent

FirewallD unterstützt prinzipiell zwei Modi: runtime und permanent. Beim Starten der Firewall wird die permanente Konfiguration aus dem Dateisystem ausgelesen. Vordefinierte Vorlagen befinden sich im Ordner /usr/lib/firewalld – angepasste Vorlagen und eigene Konfigurationen werden unterhalb /etc/firewalld gespeichert. Sofern nicht anders angegeben, werden alle Änderungen der Firewall zur Laufzeit geändert – Abhilfe schafft das Verwenden des –permanent Schalters.

Das bedeutet, soll eine Konfiguration in Echtzeit und in der permanenten Konfiguration geändert werden, muss der Befehl zweimal ausgeführt werden:

# firewall-cmd --set-default-zone=home
# firewall-cmd --set-default-zone=home --permanent

Alternativ kann die permanente Konfiguration angepasst und die Firewall neugeladen werden. Eine Option ist das folgende Kommando:

# firewall-cmd --reload

Dieses Kommando lädt die Firewall-Regeln erneut in den Kernel, behält aber etwaige Status-Informationen bei. Das hat den Vorteil, dass bereits offene Verbindungen nicht unterbrochen werden.

Als Alternative hierzu existiert der nächste Schalter:

# firewall-cmd --complete-reload

Dieser bewirkt, dass auch die Firewall-Kernelmodule (netfilter) komplett neugeladen werden. Das führt zu Abbrüchen aktiver Verbindungen und sollte nur dann angewandt werden, wenn die erste Option nicht zuverlässig funktioniert.

Services

FirewallD bringt zahlreiche vordefinierte Dienste mit – die vollständige Liste wird mit diesem Kommando aufgerufen:

# firewall-cmd --get-services
RH-Satellite-6 amanda-client amanda-k5-client ...

Nähere Infos zu definierten Services werden mit dem –info-service Schalter angezeigt:

# firewall-cmd --info-service RH-Satellite-6
RH-Satellite-6
  ports: 80/tcp 443/tcp 5646-5647/tcp 5671/tcp 8140/tcp 8080/tcp 9090/tcp
  protocols:
  source-ports:
  modules:
  destination:

Um einen Dienst einer Zone hinzuzufügen, wird der –add-service Parameter benötigt:

# firewall-cmd --zone=home --add-service=ssh

Analog dazu existiert auch ein gegenteiliger Schalter:

# firewall-cmd --zone=public --remove-service=http

Ports

Neben Services können auch einzelnen Ports freigegeben werden – beispielsweise wie folgt:

# firewall-cmd --zone=home --add-port=6667/tcp

Nach übernommener Konfiguration können geöffnete Ports mit dem –list-ports Schalter aufgelistet werden:

# firewall-cmd --zone=home --list-ports
6667/tcp

Analog dazu existiert auch wieder ein Parameter zum Entfernen der Freigabe:

# firewall-cmd --zone=home --remove-port=6667/tcp --permanent

Fazit

Unter Enterprise Linux lassen sich mit FirewallD Regeln einfacher verteilen, als mit system-config-firewall-tui. Ein weiterer Vorteil für mich ist die Möglichkeit, Firewall-Regeln ohne Unterbrechung aktiver Verbindungen durchzuführen. Vorlagen lassen sich lesbarer verteilen – ich hoffe noch auf eine YAML- oder JSON-Unterstützung.

Der zweite Teil dieser Artikel-Serie wird sich um eigene Services, Zonen und NIC-Zuordnungen drehen.

2 Kommentare Schreibe einen Kommentar

  1. Nur eine Frage:

    Welche Lösung hattest Du vorher, die laufende Verbindungen beinträchtigt hat, wenn sich Regeln geändert haben ? 🙂

    iptables macht sowas nur, wenn man die falsche Regel eingepflegt hat 😉

Schreibe einen Kommentar