Firewall

Firewall (SIF): Hinweis zur Einstellung “Vollständige IPv4-Filterung” für “unvollständige” TCP-Sessions

1. Vorbemerkungen

• Im Standardfall werden TCP-Sessions von der Firewall (SIF) grundsätzlich auf Vollständigkeit (SYN/SYN-ACK/ACK) geprüft. Unvollständige TCP-Sessions werden automatisch geblockt.
• Im Spezialfall mit identischem Ein- und Ausgangsinterface soll dieses Blockieren unvollständiger TCP-Sessions ausnahmsweise verhindert werden.
• Im Beispiel wird ein bintec Router RS353jw mit Software-Version 10.2.6 verwendet; die Konfiguration erfolgt mittels GUI bzw. Telnet-Konsole.
• Andere Geräte der bintec Router-Serien und der be.IP-Serie mit vergleichbaren Software-Versionen sind teilweise identisch bzw. analog zu konfigurieren.
• Exportieren Sie Ihre aktive Konfiguration in eine externe Datei, bevor Sie mit Änderungen an der Konfiguration beginnen.

In bestimmten Anwendungsfällen kann es vorkommen, dass der Traffic einer TCP-Session den Router nur in der einen (Session-)Übertragungsrichtung nutzt (sog. “Zweiwege-Routing”/”Kreis-Routing”) und Ein- und Ausgangsinterface identisch sind. Somit wäre die TCP-Session aus Firewall-Sicht unvollständig und würde normalerweise blockiert. Im vorliegenden Beispiel soll daher das Blockieren solcher besonderen TCP-Sessions verhindert werden.

Achtung:
Das Blockieren unvollständiger TCP-Sessions ist eine Sicherheitsfunktion – das (teilweise) Abschalten dieser Funktion reduziert die Sicherheit.

2. Maßnahme zur Zulassung bestimmter unvollständiger TCP-Sessions

Um bei aktiver Firewall ausnahmsweise ganz bestimmte (s.o.) unvollständige TCP-Sessions zuzulassen, ist im GUI-Menü Firewall, Richtlinien, Optionen die Option “Vollständige IPv4-Filterung” zu deaktivieren. Die grundsätzliche Funktion dieser Einstellung wird in Benutzerhandbuch und Online-Hilfe folgendermaßen beschrieben:

“Vollständige IPv4-Filterung: Bei TCP-Sessions überwacht die SIF im ersten Schritt, ob eine Session korrekt und vollständig aufgebaut wird. Im zweiten Schritt erfolgt die eigentliche Filterung. Für diesen “Normalfall” ist die Standardeinstellung Vollständige IPv4-Filterung Aktivieren vorgesehen. Wenn bei zweiseitiger Kommunikation eine Richtung des Datenverkehrs über den Router läuft, die Datenpakete der entgegengesetzten Richtung aber einen anderen Weg nehmen, wird der Datenverkehr vom Router nicht zugelassen, weil die Session aus Sicht der SIF unvollständig ist. Dies gilt auch, wenn es eine Regel gibt, die denselben Datenverkehr bei vollständiger Session durchlassen würde. Um den Datenverkehr bei solchen unvollständigen Sessions durchzulassen, müssen Sie Vollständige IPv4-Filterung deaktivieren.”

Dabei gilt folgende Einschränkung:
Dieses ausnahmsweise Durchlassen unvollständiger TCP-Sessions wirkt nur auf TCP-Traffic, bei dem (aus Router-Sicht) Aus- und Eingangs-Interface identisch sind und erfolgt ohne Beachtung evtl. dafür konfigurierter Firewall-Regeln.

Statt der oben genannten Firewall-Option “Vollständige IPv4-Filterung” kann in der MIB-Tabelle “ipSif” auch die Variable “ipSifInterfaceFilter” deaktiviert werden. Deren Konfiguration erfolgt in der GUI-Ansicht “SNMP-Browser” oder auf der Kommmandozeile (“SNMP-Shell”) von Telnet-, SSH- oder serieller Konsole.

Die HTML MIB-Reference 10.2.3 gibt folgende Erläuterung zu dieser Variablen “InterfaceFilter”:
“Enable or disable filtering on same Interface packets. Enumerations: enable (1) disable (2)”.

3. Vorgehensweise auf der SNMP-Shell

Deaktivierung der Variablen “ipSifInterfaceFilter” auf der Kommmandozeile (“SNMP-Shell”) von Telnet-, SSH- oder serieller Konsole:

rs353jw_ks:> ipSifInterfaceFilter
ipSifInterfaceFilter( rw):        enable
rs353jw_ks:ipSif> ipSifInterfaceFilter=disable
ipSifInterfaceFilter( rw):        disable
rs353jw_ks:ipSif>

4. Alternative Vorgehensweise in der GUI-Ansicht “SNMP-Browser”

Alternativ zu obigem ist die Variable “ipSifInterfaceFilter” auch in der GUI-Ansicht “SNMP-Browser” unter “ip”, “ipSif”, “Edit” deaktiverbar.

Deaktivierung der Variablen “ipSifInterfaceFilter” in der GUI-Ansicht “SNMP-Browser” unter “ip”, “ipSif”, “Edit” mit Beispielwerten:

Bild 1: Variable “ipSifInterfaceFilter” im GUI-SNMP-Browser unter “ip”, “ipSif”, Edit (hier den abschließenden Klick auf “OK” nicht vergessen!)

5. Einstellung in der GUI-Ansicht “Standard”

Alternativ zu obigem ist die Option “Vollständige IPv4-Filterung” in der GUI-Ansicht “Standard” unter “Firewall”, “Richtlinien”, “Optionen” deaktiverbar.

Deaktivierung der Option “Vollständige IPv4-Filterung” im GUI Menü unter “Firewall”, “Richtlinien”, “Optionen” mit Beispielwerten:

Bild 2: Option “Vollständige IPv4-Filterung” im GUI-Menu unter “Firewall”, “Richtlinien”, “Optionen” (hier den abschließenden Klick auf “OK” nicht vergessen!)

6. Kontrolle des Firewall-Verhaltens für “unvollständige” TCP-Sessions

Eine einfache Kontrolle des Verhaltens ermöglichen die Syslog-Meldungen, z.B. am Prompt der Telnet-Konsole mittels Kommando “debug all&”. Nachfolgend vier Beispiele mit einer “unvollständigen” Telnet-Session und einer Firewall-Regel (SIF: 2), die “normalen” Telnet-Traffic (telnet:6) erlauben würde.

1. Mit “Vollständige IPv4-Filterung” = “Aktiviert” und unterschiedlichen Ein- und Ausgangs-Interfaces (1000000=en1-0 bzw. 1400000=en1-4):

rs353jw_ks:> ipSifInterfaceFilter
ipSifInterfaceFilter( rw):        enable
rs353jw_ks:ipSif> debug all&
13:41:05 DEBUG/INET: new session, 192.168.2.22:64249->192.168.4.117:23 prot: 6 parent: false
13:41:05 DEBUG/INET: SIF: 2 Accept Quell-IP[1000000:192.168.2.22:64249] -> Ziel-IP[1040000:192.168.4.117:23] telnet:6
13:41:05 DEBUG/INET: destroy session, 192.168.2.22:64249->192.168.4.117:23 prot: 6
rs353jw_ks:ipSif>

Man sieht: Sofort nach dem “Accept” von SIF-Regel “2” erfolgt die “destroy”-Meldung, die angestrebte TCP-Session kommt nicht zustande.

2. Mit “Vollständige IPv4-Filterung” = “Aktiviert” und gleichem Ein- und Ausgangs-Interface (1000000=en1-0):

rs353jw_ks:> ipSifInterfaceFilter
ipSifInterfaceFilter( rw):        enable
rs353jw_ks:ipSif> debug all&
13:43:35 DEBUG/INET: new session, 192.168.2.22:64252->192.168.4.117:23 prot: 6 parent: false
13:43:35 DEBUG/INET: SIF: 2 Accept Quell-IP[1000000:192.168.2.22:64252] -> Ziel-IP[1000000:192.168.4.117:23] telnet:6
13:43:35 DEBUG/INET: destroy session, 192.168.2.22:64252->192.168.4.117:23 prot: 6
rs353jw_ks:ipSif>

Auch hier: Sofort nach dem “Accept” von SIF-Regel “2” erfolgt die “destroy”-Meldung, die angestrebte TCP-Session kommt nicht zustande.

3. Mit “Vollständige IPv4-Filterung” = “Deaktiviert” und unterschiedlichen Ein- und Ausgangs-Interfaces (1000000=en1-0 bzw. 1400000=en1-4):

rs353jw_ks:> ipSifInterfaceFilter
ipSifInterfaceFilter( rw):        disable
rs353jw_ks:ipSif> debug all&
14:46:34 DEBUG/INET: new session, 192.168.2.22:64809->192.168.4.117:23 prot: 6 parent: false
14:46:34 DEBUG/INET: SIF: 2 Accept Quell-IP[1000000:192.168.2.22:64809] -> Ziel-IP[1040000:192.168.4.117:23] telnet:6
14:46:34 DEBUG/INET: destroy session, 192.168.2.22:64809->192.168.4.117:23 prot: 6
rs353jw_ks:ipSif>

Man sieht: Sofort nach dem “Accept” von SIF-Regel “2” erfolgt die “destroy”-Meldung, die angestrebte TCP-Session kommt nicht zustande.

4. Mit “Vollständige IPv4-Filterung” = “Deaktiviert” und gleichem Ein- und Ausgangs-Interface (en1-0):

rs353jw_ks:> ipSifInterfaceFilter
ipSifInterfaceFilter( rw):        disable
rs353jw_ks:ipSif> debug all&
14:48:31 DEBUG/INET: new session, 192.168.2.22:64823->192.168.4.117:23 prot: 6 parent: false
14:48:31 DEBUG/INET: destroy session, 192.168.2.22:64823->192.168.4.117:23 prot: 6
rs353jw_ks:ipSif> 

Nur hier: Sofort nach dem “new session” und ohne ein “Accept” von SIF-Regel “2” erfolgt die “destroy”-Meldung. Die angestrebte TCP-Session kommt in diesem Fall zustande. Die fehlende Meldung mit „Accept“ von SIF-Regel „2“ zeigt, dass die vorhandene Firewall-Regel in diesem Fall nicht beachtet wird.

Zusammenfassung der vier Beispiele:
Im Fall einer “unvollständigen” (Telnet-)TCP-Session kommt die angestrebte (Telnet-)TCP-Session nur mit
“Vollständige IPv4-Filterung” = “Deaktiviert” und nur bei gleichem Ein- und Ausgangs-Interface zustande.

7. Abschlußbemerkung

Vergessen Sie nicht Ihre gewünschte Einstellung bootfest zu speichern und Ihre aktiven Konfigurationen regelmäßig in externe Dateien zu exportieren.

8. Basis

Erstellt: 23.4.2019
Stand: 7.5.2019
Produkt: bintec Router-Serien und be.IP-Serie
Release: 10.2.6
kst15/2019