# OPNsense Firewall Rules: Methodik, Syntax & Security-Hardening

TL;DR / Management Summary Firewall-Regeln sind das Gesetzbuch Ihres Netzwerks. Ein Senior Admin arbeitet nach dem Prinzip Default Deny: Alles, was nicht explizit erlaubt ist, wird blockiert. In OPNsense gilt das First Match Wins Prinzip – die Liste wird von oben nach unten abgearbeitet. Der erste Treffer entscheidet. Wir nutzen Aliase (Artikel 555), um Regeln lesbar zu halten, und protokollieren kritische Verweigerungen für das Incident-Response-Management.

# 1. Einführung & Regel-Logik

Wie die Firewall ‘liest’.

Eine Regel besteht aus:

• Action: Pass (Erlauben), Block (Verwerfen ohne Rückmeldung), Reject (Verwerfen mit Fehlermeldung).
• Interface: Wo kommt das Paket an? (Regeln werden am Eingangs-Interface definiert).
• Direction: In (Standard) oder Out.
• Protocol: TCP, UDP, ICMP oder Any.
• Source / Destination: Wer spricht mit wem?

# 2. Best Practices für das Regelwerk

Ordnung ist das halbe Hardening.

# 1. Das ‘First Match’ Prinzip nutzen

Platzieren Sie spezifische Regeln (z.B. “Admin-PC darf SSH auf den Switch”) über generischen Regeln (“LAN darf alles”).

# 2. Kommentare sind Pflicht

Nutzen Sie das “Description” Feld für Ticket-Nummern oder den Zweck der Regel (z.B. [REQ-123] Allow Backup to NAS).

# 3. Loggen mit Augenmaß

Aktivieren Sie das Logging (“Log packets that are handled by this rule”) nur für:

• Block-Regeln (um Angriffe zu sehen).
• Sehr kritische Allow-Regeln (Audit-Trail).
• Vermeiden: Logging für Standard-Web-Traffic (flutet die Disk).

# 3. Deep Dive: Inbound vs. Outbound Regeln

Die Richtung entscheidet.

In OPNsense werden Regeln standardmäßig auf dem Interface gesetzt, auf dem der Traffic eintrifft (Incoming).

• LAN Interface: Hier regeln wir, was der User im LAN darf (z.B. Internet-Zugriff).
• WAN Interface: Hier regeln wir, was aus dem Internet reinkommt (Standard: Alles Block).

# 4. Day-2 Operations: Regel-Gruppierung

Wartbarkeit für Teams.

# Floating Rules

Spezielle Regeln, die für mehrere Interfaces gleichzeitig gelten oder die Richtung “Out” beeinflussen können.

• Anwendungsfall: Globales Blockieren von bestimmten IP-Listen (z.B. Geo-IP) über alle WANs und VPNs hinweg.

# Interface Groups

Fassen Sie z.B. alle Gäste-VLANs in einer Gruppe zusammen, um eine einzige Regel für alle zu schreiben.

# 5. Troubleshooting & “War Stories”

Wenn der Zugriff verweigert wird.

# Top 3 Fehlerbilder

1. Symptom: Regel ist aktiv, aber der Traffic wird trotzdem geblockt.

   • Ursache: Eine Regel weiter oben in der Liste matcht bereits (z.B. eine generische Block-Regel).
   • Lösung: Firewall -> Diagnostics -> Live View öffnen und nach der Ziel-IP filtern. Dort sehen Sie exakt, welche Regel-ID den Drop verursacht.

2. Symptom: Änderungen an einer Regel werden nicht sofort übernommen.

   • Ursache: Bestehende Verbindungen (States) bleiben offen, bis sie ablaufen.
   • Lösung: States manuell löschen unter Firewall -> Diagnostics -> States.

3. Symptom: “Anti-Lockout Rule” wurde gelöscht.

   • Lösung: OPNsense hat eine versteckte Regel, die Zugriff auf die GUI via LAN immer erlaubt. Falls diese manuell deaktiviert wurde -> Konsole Option 8: pfctl -d.

# “War Story”: Die “Any-Any” Falle

Ein Admin sollte temporär Zugriff für einen neuen Dienst erlauben und erstellte eine Regel Source: Any, Dest: Any, Port: Any. Er vergaß sie zu löschen. Das Ergebnis: Monate später drang Malware über einen IoT-Sensor ins Netz ein und konnte ungehindert den gesamten Datenbank-Server scannen, da die “Any-Any” Regel jegliche Segmentierung aushebelte. Lehre: Nutzen Sie bei temporären Regeln immer das Ablaufdatum (Schedule) oder markieren Sie diese im Namen mit [TEMP].

# 6. Monitoring & Reporting

Audit des Regelwerks.

# Rule Usage Statistics

Unter Firewall -> Rules -> [Interface] sehen Sie kleine Zähler neben den Regeln.

• Admin-Task: Wenn eine Regel nach 6 Monaten 0 Pakete verarbeitet hat -> Löschen! Ein schlankes Regelwerk ist sicherer und schneller.

# 7. Fazit & Empfehlung

Regel-Design ist ein Handwerk.

• Empfehlung: Bauen Sie Ihre Regeln nach dem Schema “Block-Exceptions-Allow” auf.
• Sicherheit: Nutzen Sie Reject für interne LANs (damit Applikationen sofort einen Fehler bekommen und nicht hängen) und Block für das WAN (um keine Infos an Scanner preiszugeben).

# Anhang: Cheatsheet

# Referenzen

• OPNsense Docs: Firewall Rules
• PfSense/OPNsense Rule Processing Order
• Better Firewall Rule Management (Guide)