FirewallFabrik

Siehe auch

FirewallFabrik (fwf) ist der Nachfolger von Firewall Builder (fwbuilder) und ein zentrales Tool für Design, Kompilierung und Deployment von Firewall-Policies auf mehreren Firewalls gleichzeitig. Das Programm ist in Python (ab 3.14) und Qt6 (PySide6) geschrieben und steht unter der GPLv2+-Lizenz. FirewallFabrik ist kein Firewall-Appliance, sondern ein Regelgenerator: Policies werden in einer grafischen Oberfläche per Drag-and-Drop erstellt, kompiliert und anschliessend per SSH/SCP auf die Ziel-Firewalls verteilt.

Unterstützte Backends:

  • iptables (Netfilter)

  • nftables

Links:

Tipp

Was ist der Unterschied zwischen der Direction-Angabe „Inbound“, „Outbound“ und „Both“? Die übersetzten Rules - hier für iptables.

any > myhost:

  • Inbound: INPUT -i eth0

  • Outbound: OUTPUT -o eth0 -d myhost

  • Both: INPUT -i eth0; OUTPUT -o eth0 -d myhost

myhost > any:

  • Inbound: INPUT -i eth0 -s myhost; FORWARD -i eth0 -s myhost

  • Outbound: OUTPUT -o eth0

  • Both: INPUT -i eth0 -s myhost; FORWARD -i eth0 -s myhost; OUTPUT -o eth0

Installation

Voraussetzung ist Python >= 3.14.

uv (empfohlen)
# einmalig starten ohne Installation
uvx --from 'firewallfabrik[gui]' fwf

# oder fest installieren
uv tool install 'firewallfabrik[gui]'
pipx
pipx install 'firewallfabrik[gui]'
pip
pip install --user 'firewallfabrik[gui]'

Das Extra [gui] installiert PySide6 für die grafische Oberfläche. Ohne [gui] stehen nur die CLI-Compiler fwf-ipt und fwf-nft zur Verfügung.

Desktop-Integration unter Linux:

cp assets/ch.linuxfabrik.firewallfabrik.desktop $HOME/.local/share/applications/
cp src/firewallfabrik/gui/ui/Icons/firewallfabrik.svg $HOME/.local/share/icons/hicolor/scalable/apps/

CLI-Tools

fwf

Grafische Oberfläche (Qt6).

fwf-ipt

Kommandozeilen-Compiler für iptables. Kompiliert eine .fwf- oder .fwb-Datei zu einem Shell-Skript mit iptables-Kommandos. Akzeptiert mehrere Firewall-Namen und ein --all-Flag, um alle iptables-Firewalls in der Datenbank in einem Durchgang zu kompilieren.

fwf-nft

Kommandozeilen-Compiler für nftables. Kompiliert eine .fwf- oder .fwb-Datei zu einem nft-Batch-File. Akzeptiert mehrere Firewall-Namen und ein --all-Flag, um alle nftables-Firewalls in der Datenbank in einem Durchgang zu kompilieren.

Dateiformat

FirewallFabrik verwendet .fwf-Dateien im YAML-Format. Diese sind menschenlesbar und eignen sich für die Versionskontrolle mit Git. Intern arbeitet FirewallFabrik mit einer SQLite-Datenbank im Arbeitsspeicher (via SQLAlchemy).

Bestehende .fwb-Dateien (Firewall Builder XML) können importiert und beim Speichern automatisch in das .fwf-Format konvertiert werden.

Objekt-Modell

Alle Regeln werden auf benannte Objekte aufgebaut (keine rohen IP-Adressen in Regeln). Objekte können über mehrere Firewalls und Regelsätze hinweg wiederverwendet werden.

Adress-Objekte

  • Firewall (mit Interfaces, Policy-/NAT-/Routing-Regelsätzen)

  • Cluster (Hochverfügbarkeit mit mehreren Member-Firewalls)

  • Host

  • Network

  • Address Range

  • IPv4/IPv6 Addresses

  • DNS Name

  • Address Table (extern ladbare Adresslisten)

  • Dynamic Groups (kriterienbasierte Gruppen, die automatisch passende Objekte enthalten)

  • Object Groups

Service-Objekte

  • TCP, UDP (mit Port-Ranges)

  • ICMP, ICMPv6

  • IP-Protokolle

  • Custom Services

  • Service Groups

Time-Objekte

Wiederkehrende Zeitfenster (Tageszeit, Wochentag) für zeitbasierte Regeln.

Regelwerk

Jede Firewall besitzt drei Typen von Regelsätzen:

Access Policy

Filterregeln für Traffic. Regel-Elemente: Source, Destination, Service, Interface, Direction (Inbound/Outbound/Both), Time. Aktionen: Accept, Deny, Reject, Accounting, Queue, Custom, Branch (Sprung in anderen Regelsatz), Continue. First-Match-Prinzip.

NAT

Adress- und Port-Übersetzung: SNAT, DNAT, Masquerade, Redirect, Load Balancing, SDNAT, NONAT.

Routing

Statische Routen mit ECMP-Unterstützung (Equal Cost Multi Path).

Die Regelverarbeitung unterstützt Negation, IPv4/IPv6-Dual-Stack (ein Regelsatz generiert beide Konfigurationen), Rule Shadowing Detection (Erkennung von Regeln, die nie matchen) und Logging pro Regel.

Custom Services

Beispiel: es soll die Regel iptables -I INPUT -m geoip ! --src-cc CH -j DROP abgebildet werden, also das xtables GeoIP-Modul verwendet und Traffic ausserhalb der Schweiz geblockt werden.

  • Service > Custom > Add

  • Name: „IP from CH“

  • Code String: -m geoip --src-cc CH

Connection Tracking

Connection Tracking ist ein stateful Firewalling-Mechanismus, der Pakete, die zu einer erlaubten Verbindung gehören, ohne eine explizite Regel durch die Firewall lässt, z.B. TCP ACK-Pakete. Solche Pakete werden als RELATED markiert und können somit generell durchgelassen werden. In FirewallFabrik geschieht dies über die „Firewall Settings“ > „Accept ESTABLISHED and RELATED packets before the first rule“.

Das Connection Tracking kann durch Helper-Module erweitert werden, z.B. für FTP. Ab Kernel v4.7+ (also RHEL8+) werden aus Sicherheitsgründen die Helper-Module nicht mehr automatisch aktiviert:

sysctl net.netfilter.nf_conntrack_helper
# net.netfilter.nf_conntrack_helper = 0
# 0 => disabled
# 1 => enabled

Die Module müssen nun explizit für einen Port aktiviert werden:

iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp

FirewallFabrik unterstützt das Einrichten von raw Regeln leider nicht direkt. Das obige Kommando kann aber per „Firewall Settings > „Prolog/Epilog“ als Prolog ausgeführt werden. Wichtig ist dabei, dass „Insert prolog script“ auf „after policy reset“ steht.

Alternativ kann auch das alte Verhalten, d.h. die automatische Aktivierung der Helfer-Module, wieder aktiviert werden:

echo 'net.netfilter.nf_conntrack_helper = 1' >> /etc/sysctl.conf
sysctl -p

Kompilierung und Deployment

Kompilierung

Der Compiler übersetzt die grafisch erstellten Policies in ausführbare Shell-Skripte (.fw). Die Ausgabe ist idempotent - das Skript kann gefahrlos mehrfach angewendet werden, da es zuerst alle Regeln flusht und dann neu aufbaut. Die GUI kompiliert mehrere Firewalls parallel (bis zur Anzahl CPU-Kerne), die CLI-Compiler laden die Datenbank einmal und kompilieren sequenziell.

Einzelne Regeln können mit der Taste X direkt im Editor testweise kompiliert werden, um die generierten Kommandos zu prüfen.

Deployment

  • Automatisch: SSH/SCP über die eingebaute Installer-Funktion (unterstützt Sudo, Key-basierte Authentifizierung, alternative SSH-Ports, Batch-Installation auf mehrere Firewalls)

  • Manuell: generiertes .fw-Skript per SCP kopieren und per SSH ausführen

  • CI/CD: generierte Skripte lassen sich in Ansible, GitLab CI, GitHub Actions o.ä. integrieren

Installer via Non-Root User mit Sudo

Falls man die Firewalls nicht direkt mit dem root-User verteilen will oder kann, genügt auch ein Standard-Benutzer, solange dieser sudo ohne Passwort verwenden darf.

Dazu muss in der jeweiligen Firewall unter Firewall Settings im Tab Installer folgendes gesetzt sein:

  • Directory on the firewall where script should be installed: /tmp

  • A command that installer should execute on the firewall in order to activate the policy: sudo mv /tmp/fwf.sh /etc/fwf.sh && sudo chown root:root /etc/fwf.sh && if command -v restorecon 1> /dev/null; then sudo restorecon -F /etc/fwf.sh; fi && sudo /etc/fwf.sh

FirewallFabrik als Systemd-Service

/etc/systemd/system/fwf.service
[Unit]
Description=FirewallFabrik
After=default.target openvpn-server@server.service fail2ban.service

[Service]
Type=oneshot
ExecStart=/etc/fwf.sh start
ExecStop=/etc/fwf.sh stop
ExecReload=/etc/fwf.sh start
RemainAfterExit=yes

[Install]
WantedBy=default.target

Pro- und Epilog für OpenVPN und Fail2ban

Wenn FirewallFabrik gestartet wird, die OpenVPN-Schnittstelle tun0 verwendet, aber noch nicht bereit ist, wird der Start des .fw-Skriptes fehlschlagen. Es wird daher empfohlen, im Prolog zu warten, bis das Interface verfügbar ist.

Andere Probleme treten im Zusammenspiel mit Fail2Ban auf: Die Chains und Regeln von Fail2Ban werden beim (Re-)Start von FirewallFabrik gelöscht. Daher muss Fail2Ban im Prolog gestoppt und im Epilog wieder gestartet werden.

Die folgenden Skripte können auf allen Servern eingerichtet werden, da zuerst geprüft wird, ob OpenVPN oder Fail2Ban vorhanden und aktiv ist.

Bemerkung

Unter Debian ist /bin/sh ein Link zu dash, das heisst, die Skripte müssen zwingend POSIX kompatibel sein. Erweitere Features wie if [[ ... ]] funktionieren in den Prolog- und Epilog-Skripten daher nicht. Unter RHEL zeigt /bin/sh dagegen auf bash.

Prolog
### Wait for OpenVPN interface ###
# returns 1 either if the service is disabled, or if it does not exist
if systemctl is-enabled openvpn-server@server.service > /dev/null 2>&1; then
    log 'Enabled OpenVPN Server found, waiting for the OpenVPN interface'
    device="tun0"
    timeout=60
    found=0

    while [ $timeout -gt 0 ]; do
        if ip link show $device > /dev/null 2>&1; then
            found=1
            break
        else
            timeout=$((timeout-=1))
            sleep 1
        fi
    done

    if [ "$found" -eq 0 ]; then
        log "Cannot find $device! Trying to run the fwf script regardless..."
    else
        log "Found $device! Continuing with the fwf script..."
    fi
fi


### Kill fail2ban ###
stopped_fail2ban=0
if systemctl is-active fail2ban.service > /dev/null 2>&1; then
    stopped_fail2ban=1
    systemctl stop --signal SIGKILL fail2ban
    log "fail2ban.service killed, continuing with fwf script..."
else
    log "fail2ban not running, continuing with fwf script..."
fi
Epilog
if [ "$stopped_fail2ban" -eq 1 ]; then
    log "Restarting fail2ban.service"
    systemctl restart fail2ban
fi

Log-Dateien auf DENY untersuchen

grep DENY /var/log/messages* | grep -Ev '(FIN|SYN|RST|ACK)'

Dead Man’s Switch

Wenn man Firewalls auf Systeme verteilt, auf die man keinen physischen (oder virtuellen Hypervisor-)Zugriff hat, will man unbedingt vermeiden, sich selbst auszusperren. Zu diesem Zweck kann man einen Job auf dem Host erstellen, der die Firewall nach z.B. 10 Minuten wieder deaktiviert. Falls das Deployment und der Zugriff erfolgreich waren, kann der Job entfernt werden. Falls es Probleme gibt, müssen einfach die 10 Minuten abgewartet werden.

dnf install at nftables
systemctl enable --now atd.service

echo /usr/sbin/nft flush ruleset | at now +10 minutes
# job 2 at Wed Aug 13 12:03:00 2025

# remember the job id and deploy the firewall

# if the access works, remove the job
atrm 2
# double-check the at queue
atq

Migration von Firewall Builder

  1. Bestehende .fwb-Datei in FirewallFabrik öffnen.

  2. Die Datei wird automatisch importiert und in das interne Format konvertiert.

  3. Beim Speichern wird eine .fwf-Datei (YAML) erzeugt.

  4. Alle Objekte, Regeln und Firewall-Definitionen werden übernommen.

Built on 2026-03-09