OPNsense/Firewall/Regeln - Beschreibung

Beschreibung

Anhang

Siehe auch

Links

Weblinks

TMP

Regeln

OPNsense enthält einen zustandsorientierten Paketfilter, mit dem Sie den Datenverkehr von und zu bestimmten Netzwerken einschränken oder zulassen sowie die Weiterleitung des Datenverkehrs beeinflussen können (siehe auch „Multi-WAN“ unter „Richtlinienbasiertes Routing“).

Im Abschnitt „Regeln“ werden alle für Ihr Netzwerk geltenden Richtlinien nach Schnittstellen gruppiert angezeigt.

Übersicht

Unsere Übersicht zeigt alle Regeln, die für die ausgewählte Schnittstelle (Gruppe) oder den Floating-Abschnitt gelten. Zu jeder Regel werden einige Details angezeigt, und Sie können gegebenenfalls Aktionen ausführen, z. B. verschieben, bearbeiten, kopieren, löschen.

Nachfolgend finden Sie einige Highlights zu diesem Bildschirm.Schnittstellenname

Der Name der Schnittstelle ist Teil der normalen Menü-Breadcrumb-Navigation.

Kategorie

Wenn in den Regeln Kategorien verwendet werden, können Sie hier auswählen, welche angezeigt werden sollen.

Prüfung umschalten

Hier können Sie zwischen der Prüfungs- und der Regelansicht umschalten. Im Prüfungsmodus werden Statistiken zur Regel angezeigt (z. B. Paket-Zähler, Anzahl der aktiven Zustände usw.).

Automatische Regeln ein-/ausblenden

Einige Regeln werden automatisch generiert. Hier können Sie umschalten, um die Details anzuzeigen. Wenn eine Lupe angezeigt wird, können Sie auch zu ihrer Quelle navigieren (der Einstellung, die diese Regel steuert).

Automatische Regeln

Der Inhalt der automatischen Regeln

Benutzerdefinierte Regeln

Alle vom Benutzer definierten Regeln

Grundlagen

Bevor Sie Regeln erstellen, sollten Sie einige Grundlagen kennen, die für alle Regeln gelten.

Zustände

Standardmäßig sind Regeln auf „zustandsbehaftet“ gesetzt (Sie können dies ändern, aber das hat Konsequenzen), was bedeutet, dass der Zustand einer Verbindung in einem lokalen Wörterbuch gespeichert wird, das bei Eintreffen des nächsten Pakets aufgelöst wird. Das hat zur Folge, dass die Firewall bei Vorhandensein eines Zustands nicht alle Regeln erneut verarbeiten muss, um die anzuwendende Aktion zu bestimmen, was enorme Leistungsvorteile mit sich bringt.

Ein weiterer Vorteil der zustandsbehafteten Paketfilterung besteht darin, dass Sie nur den Datenverkehr in einer Richtung zulassen müssen, um verwandte Pakete für denselben Fluss automatisch zurückzulassen. Das folgende Diagramm zeigt eine TCP-Verbindung von einem Client zu einem Server für HTTPS-Datenverkehr. Wenn keine zustandsbehafteten Regeln verwendet werden, sollte sowohl dem Client als auch dem Server die Übertragung von Datenverkehr an den Port 443 des Servers (in der Regel ein Port >=1024) gestattet sein.

Die Verwendung von Zuständen kann auch die Sicherheit verbessern, insbesondere bei TCP-Datenverkehr, da auch die Sequenznummern und Zeitstempel der Pakete überprüft werden, um den Datenverkehr durchzulassen, wodurch es viel schwieriger ist, Datenverkehr zu fälschen.

Hinweis

Wenn Sie Regeln ändern, ist es manchmal erforderlich, die Zustände zurückzusetzen, um sicherzustellen, dass die neuen Richtlinien für den bestehenden Datenverkehr verwendet werden. Sie können dies unter Firewall ‣ Diagnose ‣ Zustände tun.

Hin

Um Zustände zu speichern, muss das System Speicher reservieren. Standardmäßig sind 10 % des Systemspeichers für Zustände reserviert. Dies kann unter Firewall ‣ Einstellungen ‣ Maximale Firewall-Zustände konfiguriert werden. (Der Hilfetext zeigt die Standardanzahl der Zustände auf Ihrer Plattform an.

Zustände können auch sehr praktisch sein, um jederzeit die aktivsten Benutzer Ihrer Firewall zu finden. Zu diesem Zweck haben wir einen benutzerfreundlichen „Sitzungsbrowser“ hinzugefügt. Sie finden ihn unter Firewall ‣ Diagnostik ‣ Sitzungen.

Tipp

Zustände spielen auch eine wichtige Rolle beim Schutz von Diensten vor (verteilten) Denial-of-Service-Angriffen (DDOS). Relevante Themen finden Sie in unserer Dokumentation unter „synproxy“-Zustände, Verbindungsbeschränkungen und syncookies.

Aktion

Regeln können auf drei verschiedene Aktionstypen festgelegt werden:* Pass –> Datenverkehr zulassen

Block –> Datenverkehr ablehnen und den Client nicht darüber informieren, dass er abgelehnt wurde (was in der Regel für nicht vertrauenswürdige Netzwerke ratsam ist)
Reject –> Datenverkehr ablehnen und den Client darüber informieren. (Nur TCP und UDP unterstützen die Ablehnung von Paketen, was im Falle von TCP bedeutet, dass ein RST zurückgegeben wird, für UDP wird ICMP UNREACHABLE zurückgegeben).

Für interne Netzwerke kann es sinnvoll sein, „Ablehnen“ zu verwenden, damit der Client nicht auf eine Zeitüberschreitung warten muss, wenn der Zugriff nicht erlaubt ist. Wenn Sie Pakete aus nicht vertrauenswürdigen Netzwerken empfangen, möchten Sie in der Regel nicht zurückkommunizieren, wenn der Datenverkehr nicht erlaubt ist.

Verarbeitungsreihenfolge

Firewall-Regeln werden nacheinander pro Abschnitt verarbeitet, wobei zuerst der Abschnitt „Floating-Regeln“ ausgewertet wird, gefolgt von allen Regeln, die zu Schnittstellengruppen gehören, und schließlich allen Schnittstellenregeln.

Interne (automatische) Regeln werden in der Regel zuerst registriert.

Regeln können entweder auf „quick“ gesetzt oder nicht auf „quick“ gesetzt werden, wobei „quick“ die Standardeinstellung ist. Wenn „quick“ gesetzt ist, wird die Regel nach dem Prinzip „first match“ behandelt, d. h., die erste Regel, die auf das Paket zutrifft, hat Vorrang vor den nachfolgenden Regeln.

Wenn „quick“ nicht gesetzt ist, gewinnt die letzte Übereinstimmung. Dies kann für Regeln nützlich sein, die das Standardverhalten definieren. Unsere Standard-Ablehnungsregel nutzt diese Eigenschaft beispielsweise (wenn keine Regel zutrifft, wird der Datenverkehr abgelehnt).

Hinweis

Intern werden Regeln anhand einer Priorität registriert, Floating verwendet 200000, Gruppen verwenden 300000 und Schnittstellenregeln landen bei 400000 in Kombination mit der Reihenfolge, in der sie erscheinen. Automatische Regeln werden in der Regel mit einer höheren Priorität (niedrigere Zahl) registriert.

Warnung

NAT-Regeln werden immer vor Filterregeln verarbeitet! Wenn Sie beispielsweise eine NAT: Portweiterleitungsregel ohne zugehörige Regel definieren, d. h. die Filterregelzuordnung auf Pass gesetzt ist, hat dies zur Folge, dass keine anderen Regeln angewendet werden!

Tipp

Die Schnittstelle sollte alle verwendeten Regeln anzeigen. Im Zweifelsfall können Sie jederzeit die Rohausgabe des Regelsatzes in /tmp/rules.debug überprüfen.

Regelfolge

Die Reihenfolge, in der die Regeln angezeigt und verarbeitet werden, kann pro Abschnitt angepasst werden:* Wählen Sie eine oder mehrere Regeln über das Kontrollkästchen links neben der Regel aus.

Verwenden Sie die Pfeiltaste im Aktionsmenü rechts neben einer Regel, um ausgewählte Regeln vor die Regel zu verschieben, bei der die Aktionstaste gedrückt wird.
Oder Sie können die Pfeiltaste oben in der Kopfzeile verwenden, um die ausgewählten Regeln an das Ende zu verschieben.

Richtung

Der Datenverkehr kann in der Richtung in[coming] oder out[going] abgeglichen werden. Standardmäßig wird nach der eingehenden Richtung gefiltert. In diesem Fall würden Sie die Richtlinie auf der Schnittstelle festlegen, von der der Datenverkehr stammt.

Wenn Sie beispielsweise den https-Datenverkehr von jedem Host im Internet zulassen möchten, würden Sie normalerweise eine Richtlinie auf der WAN-Schnittstelle festlegen, die den Port 443 für den betreffenden Host zulässt.

Hinweis

Datenverkehr, der die Firewall verlässt, wird standardmäßig akzeptiert (unter Verwendung einer Nicht-Schnellregel). Wenn Gateway erzwingen unter Firewall ‣ Einstellungen ‣ Erweitert nicht aktiviert ist, wird auch das verbundene Gateway erzwungen.

Einstellungen

Der Datenverkehr, der durch Ihre Firewall fließt, kann mithilfe von Regeln, die Richtlinien definieren, zugelassen oder abgelehnt werden. In diesem Abschnitt der Dokumentation werden die verschiedenen Einstellungen nach ihrer Verwendung gruppiert beschrieben.

Beschreibende Einstellungen

Einige Einstellungen helfen dabei, Regeln zu identifizieren, ohne den Datenverkehr zu beeinflussen.

Kategorie

Die Kategorie, zu der diese Regel gehört, kann als Filter in der Übersicht verwendet werden.

Beschreibung

Beschreibender Text

Grundeinstellungen

Nachfolgend finden Sie die am häufigsten verwendeten Einstellungen:

Aktion

Die auszuführende Aktion.

Deaktiviert

Deaktiviert eine Regel, ohne sie zu entfernen. Dies kann zu Testzwecken und zur einfachen Aktivierung seltener verwendeter Richtlinien praktisch sein.

Schnittstelle

Schnittstelle(n), auf die diese Regel angewendet wird. Sie können Regeln einfach zwischen Schnittstellen kopieren und dieses Feld auf die neue Zielschnittstelle ändern. (Denken Sie daran, die Reihenfolge vor dem Anwenden zu überprüfen.

TCP/IP-Version

Gilt diese Regel für IPv4, IPv6 oder beides?

Protokoll

Zu verwendendes Protokoll, am häufigsten werden TCP und UDP verwendet.

Quelle

Quellnetzwerk oder -adresse. Wenn Sie IPv4 und IPv6 in einer Regel kombinieren, können Sie Aliase verwenden, die beide Adressfamilien enthalten. Sie können mehrere Quellen pro Regel auswählen.

Quelle / Umkehren

Quellenauswahl umkehren (z. B. nicht 192.168.0.0/24). Sie können nur einzelne Quellen umkehren.

Ziel

Zielnetzwerk oder -adresse, wie bei der Quelle können Sie auch hier Aliase verwenden. Sie können mehrere Ziele pro Regel auswählen.

Ziel / Umkehren

Wenn der Filter umgekehrt werden soll, können Sie dieses Kontrollkästchen markieren. Sie können nur einzelne Ziele umkehren.

Zielportbereich

Für TCP und/oder UDP können Sie einen Dienst nach Name (http, https) oder Nummer (Bereich) auswählen, Sie können hier auch Aliase verwenden, um die Verwaltung zu vereinfachen.

Protokoll

Erstellt einen Protokolleintrag, wenn diese Regel gilt. Mit Firewall ‣ Protokolldateien ‣ Live-Ansicht können Sie überwachen, ob Ihre Regel gilt.

Tipp

Die Verwendung aussagekräftiger Namen erleichtert die Identifizierung des Datenverkehrs in der Live-Protokollansicht.

Tipp

Mit der Schaltfläche „Auge“ in der rechten oberen Ecke des Bildschirms können Sie Statistiken zur betreffenden Regel anzeigen (Anzahl der Auswertungen, Anzahl der aktiven Zustände und Datenverkehrszähler).

Tipp

Sie können mehrere Quellen oder Ziele pro Regel auswählen, beachten Sie jedoch, dass ein verschachtelter Alias möglicherweise die bessere Wahl ist. Diese Funktion ist besonders nützlich, wenn Sie Sicherheitszonen erstellen möchten.

Traffic Shaping (QoS)

Wenn eine Firewall-Regel hinsichtlich der Anzahl der Pakete, die sie im Laufe der Zeit verarbeiten darf, eingeschränkt werden muss, kann die Regel mit dem Traffic Shaper kombiniert werden.

Der Prozess der Formung wird im Abschnitt Traffic Shaping unserer Dokumentation erläutert. Nachfolgend finden Sie die relevanten Eigenschaften für die Firewall-Regel.

Traffic Shaping/Regelrichtung

Pakete, die dieser Regel entsprechen, werden in die konfigurierte Warteschlange oder Pipe geleitet.

Traffic Shaping/umgekehrte Richtung

Pakete, die in die entgegengesetzte Richtung passen, werden in die konfigurierte Warteschlange oder Pipe geleitet.

Tipp

Filterregeln sind flexibler als die im Abschnitt „Shaper“ selbst angegebenen, da sie auch mit Aliasen kombiniert werden können. Obwohl diese Funktion noch recht neu ist, lohnt es sich auf jeden Fall, sie sich anzusehen, wenn Sie einen Traffic Shaper benötigen.

Weniger häufig verwendet

Einige Einstellungen sollten in der Regel auf den Standardwerten belassen werden, können aber auch in der normalen Regelkonfiguration festgelegt werden.

Quellportbereich

Bei TCP und/oder UDP können Sie auch nach dem vom Client verwendeten Quellport (Bereich) filtern. Da Sie den Quellport in den meisten Fällen nicht beeinflussen können, wird diese Einstellung in der Regel auf dem Standardwert belassen (any).

Quick

Wenn ein Paket einer Regel entspricht, die quick angibt, gewinnt die erste übereinstimmende Regel. Wenn quick nicht gesetzt ist, gewinnt die letzte übereinstimmende Regel. Wenn Sie sich nicht sicher sind, verwenden Sie am besten quick-Regeln und interpretieren Sie den Regelsatz von oben nach unten.

Richtung

Richtung des Datenverkehrs, siehe auch Richtung.

Hochverfügbarkeit

Die folgenden Optionen werden speziell für HA-Konfigurationen verwendet.

Keine XMLRPC-Synchronisierung

Deaktivieren Sie die Konfigurationssynchronisierung für diese Regel, wenn die Synchronisierung der Firewall-Regeln unter System ‣ Hochverfügbarkeit ‣ Einstellungen

Zustandstyp / KEIN pfsync

Verhindern Sie, dass durch diese Regel erstellte Zustände mit dem anderen Knoten synchronisiert werden.

Zeitplan

Regeln können auch so geplant werden, dass sie an bestimmten Tagen oder in bestimmten Zeiträumen aktiv sind. Sie können Zeitpläne unter Firewall ‣ Erweitert ‣ Zeitpläne erstellen und einen davon in der Regel auswählen.

Richtlinienbasiertes Routing

Diese Funktion kann verwendet werden, um Datenverkehr anhand von detaillierteren Filtern als statische Routen (OSI-Schicht 4 gegenüber OSI-Schicht 3) an ein anderes Gateway weiterzuleiten, und kann zum Aufbau von Multi-WAN-Szenarien mit Gateway-Gruppen verwendet werden.

Weitere Informationen zu Multi-WAN finden Sie im Kapitel „Multi-WAN“.

Gateway

Wenn ein Gateway angegeben ist, verwenden Pakete das richtlinienbasierte Routing unter Verwendung des angegebenen Gateways oder der angegebenen Gateway-Gruppe. Normalerweise wird diese Option auf der empfangenden Schnittstelle (z. B. LAN) festgelegt, die dann das hier angegebene Gateway auswählt. (Die Standard-Routing-Regeln werden dabei ignoriert.) Nur Pakete, die in die gleiche Richtung wie die Regel fließen, sind von diesem Parameter betroffen, die entgegengesetzte Richtung (Antworten) ist von dieser Option nicht betroffen.

Antwort

Standardmäßig wird der Datenverkehr immer an das mit der Schnittstelle verbundene Gateway gesendet. Wenn Sie aus irgendeinem Grund nicht möchten, dass der Datenverkehr an dieses Gateway weitergeleitet wird, können Sie dieses Verhalten hier deaktivieren oder ein alternatives Ziel festlegen.

Hinweis

Wenn Sie das richtlinienbasierte Routing verwenden, vergessen Sie nicht, lokalen Datenverkehr auszuschließen, der nicht weitergeleitet werden soll. Dazu können Sie eine Regel mit einer höheren Priorität erstellen und ein Standard Gateway

Unserer Erfahrung nach kann die Paketaufzeichnungsfunktion (Schnittstellen ‣ Diagnose ‣ Paketaufzeichnung) ein wertvolles Werkzeug sein, um zu überprüfen, ob der Datenverkehr wirklich in die erwartete Richtung fließt. Wählen Sie einfach einen zu überwachenden Host aus und versuchen Sie, einige Pakete auszutauschen. Wenn Sie alle Schnittstellen auswählen, können Sie leicht erkennen, wohin der Datenverkehr fließt.

Verbindungslimits

Die erweiterten Optionen enthalten einige Einstellungen, um die Verwendung einer Regel zu beschränken oder bestimmte Zeitlimits für sie festzulegen. Die meisten allgemeinen (Standard-)Einstellungen für diese Optionen finden Sie unter Firewall ‣ Einstellungen ‣ Erweitert

Maximale Zustände

Begrenzt die Anzahl der gleichzeitigen Zustände, die die Regel erstellen kann. Wenn dieses Limit erreicht ist, werden weitere Pakete, die einen Zustand erstellen würden, erst dann mit dieser Regel abgeglichen, wenn die bestehenden Zustände abgelaufen sind.

Maximale Quellknoten

Begrenzt die maximale Anzahl von Quelladressen, die gleichzeitig Einträge in der Zustandstabelle haben können.

Maximal etabliert

Begrenzt die maximale Anzahl gleichzeitiger TCP-Verbindungen, die den 3-Wege-Handshake abgeschlossen haben, die ein einzelner Host herstellen kann.

Max. Quellzustände

Begrenzt die maximale Anzahl gleichzeitiger Zustandseinträge, die eine einzelne Quelladresse mit dieser Regel erstellen kann.

Max. neue Verbindungen

Begrenzt die Rate neuer Verbindungen über einen bestimmten Zeitraum. Die Verbindungsrate ist ein Näherungswert, der als gleitender Durchschnitt berechnet wird. (Anzahl der Verbindungen / Sekunden) Gilt nur für TCP-Verbindungen.

Zustandszeitlimit

Status-Timeout in Sekunden (gilt nur für TCP)

Erweitert

Einige weniger häufig verwendete Optionen sind unten definiert.

Quell-Betriebssystem

Betriebssysteme können anhand einiger TCP-Felder der ursprünglichen Verbindung identifiziert werden. Diese Fingerabdrücke können auch zum Abgleichen des Datenverkehrs verwendet werden. (Ausführlichere Informationen finden Sie in der pf.os-Manpage.

Zulässige Optionen

Standardmäßig blockiert die Firewall IPv4-Pakete mit IP-Optionen oder IPv6-Pakete mit gesetzten Routing-Erweiterungs-Headern. Wenn Sie eine Anwendung haben, die solche Pakete benötigt (z. B. Multicast oder IGMP), können Sie diese Option aktivieren.

TCP-Flags

Wenn bestimmte TCP-Flags gesetzt oder zurückgesetzt werden müssen, können Sie diese hier angeben.

Priorität festlegen

Paketen, die dieser Regel entsprechen, wird eine bestimmte Warteschlangenpriorität zugewiesen. Wenn das Paket über eine VLAN-Schnittstelle übertragen wird, wird die Warteschlangenpriorität als Prioritätscode in den 802.1Q-VLAN-Header geschrieben. Wenn zwei Prioritäten angegeben sind, werden Pakete mit einem TOS von „lowdelay“ und TCP-ACKs ohne Datenpayload der zweiten Priorität zugewiesen.

Priorität abgleichen

Nur Pakete abgleichen, denen die angegebene Warteschlangenpriorität zugewiesen ist.

Lokales Tag setzen

Pakete, die dieser Regel entsprechen, werden mit der angegebenen Zeichenfolge getaggt. Das Tag fungiert als interne Markierung, mit der diese Pakete später identifiziert werden können. Dies kann beispielsweise verwendet werden, um Vertrauen zwischen Schnittstellen herzustellen und um festzustellen, ob Pakete durch Übersetzungsregeln verarbeitet wurden. Tags sind „sticky“, d. h., das Paket wird auch dann getaggt, wenn die Regel nicht die letzte übereinstimmende Regel ist. Weitere Übereinstimmungsregeln können das Tag durch ein neues ersetzen, entfernen jedoch kein zuvor angewendetes Tag. Ein Paket erhält immer nur ein Tag gleichzeitig.

Lokales Tag abgleichen

Pakete abgleichen, die zuvor (mit „Lokales Tag setzen“) getaggt wurden.

Status

Beeinflusst den verwendeten Statusverfolgungsmechanismus. Die folgenden Optionen sind verfügbar. Im Zweifelsfall ist es in der Regel am besten, die Standardeinstellung beizubehalten. Status beibehalten* Status beibehalten ‣ wird für die statusorientierte Verbindungsverfolgung verwendet.

Sloppy state ‣ funktioniert wie „keep state“, überprüft jedoch keine Sequenznummern. Verwenden Sie diese Option, wenn die Firewall nicht alle Pakete sieht.
Synproxy state ‣ leitet eingehende TCP-Verbindungen weiter, um Server vor gefälschten TCP-SYN-Floods zu schützen. Diese Option umfasst die Funktionen von „keep state“ und „modulate state“ kombiniert.
None ‣ Verwendet keine Statusmechanismen zur Nachverfolgung.

Fehlerbehebung

Beim Erstellen Ihres Regelsatzes können Fehler auftreten. Es ist daher immer gut zu wissen, wo Sie nach Anzeichen für ein Problem suchen müssen. Einer der häufigsten Fehler ist, dass der Datenverkehr nicht mit der Regel übereinstimmt und/oder die Reihenfolge der Regeln aus irgendeinem Grund nicht sinnvoll ist.

Mit der Schaltfläche „Überprüfen“ kann man leicht sehen, ob eine Regel ausgewertet wurde und der Datenverkehr diese Regel passiert hat. Es ist auch möglich, direkt zu den zugehörigen Zuständen zu springen, um zu sehen, ob Ihr Host wie erwartet in der Liste enthalten ist.

Ein weiteres wertvolles Tool ist der Live-Log-Viewer. Um ihn zu verwenden, stellen Sie sicher, dass Sie Ihrer Regel eine leicht lesbare Beschreibung geben und die Option „Protokoll“ aktivieren.

Wenn Sie Source Routing (richtlinienbasiertes Routing) verwenden, kann die Fehlersuche manchmal etwas komplizierter sein. Da die normale System-Routing-Tabelle möglicherweise nicht gilt, ist es hilfreich zu wissen, welchem Fluss der Datenverkehr tatsächlich gefolgt ist. In diesem Fall ist die Paketerfassung ein nützliches Tool.

Häufige Probleme in diesem Bereich sind Rückverkehr, der eine andere Schnittstelle als diejenige verwendet, über die er eingegangen ist, da der Datenverkehr auf seinem Weg nach außen der normalen Routing-Tabelle folgt (Reply-to-Problem), oder Datenverkehr, der aufgrund einer Überauswahl die falsche Schnittstelle verlässt (Übereinstimmung mit internem Datenverkehr und Erzwingen eines Gateways).

Es ist auch ratsam, die verwendeten Netzmasken zu überprüfen, da es leicht zu Fehlern kommen kann, wenn man einen Host abgleichen möchte, aber ein Subnetz angibt (z. B. 192.168.1.1/32 vs. 192.168.1.1/24 entspricht in Wirklichkeit 192.168.1.x)

Zu guter Letzt sollten Sie daran denken, dass Regeln in der Reihenfolge ihrer Angabe abgeglichen werden und die Standardrichtlinie (für eingehenden Datenverkehr) block lautet, sofern nichts anderes angegeben ist. Da wir den Datenverkehr auf inbound abgleichen, sollten Sie unbedingt Regeln für den Ursprung des Datenverkehrs hinzufügen (z. B. lan für Datenverkehr, der Ihr Netzwerk verlässt; der Rückverkehr sollte normalerweise durch den Status zugelassen werden).

API-Zugriff

Der teilweise API-Zugriff wird im Firewall-API-Referenzhandbuch näher beschrieben.