TCP-Sitzungen

Standardmäßig sind die Optionen TCP-SYN-Prüfung und Sequenzprüfung in allen TCP-Sitzungen aktiviert. Das Betriebssystem Junos (Junos OS) führt während TCP-Sitzungen die folgenden Vorgänge aus:

• Prüft im ersten Paket einer Sitzung auf SYN-Flags und lehnt alle TCP-Segmente mit Nicht-SYN-Flags ab, die versuchen, eine Sitzung zu initiieren.

• Validiert die TCP-Sequenznummern während der Stateful Inspection.

Mit der Funktion TCP-Sitzungsprüfung pro Richtlinie können Sie SYN- und Sequenzprüfungen für jede Richtlinie konfigurieren. Derzeit sind die TCP-Optionsflags no-sequence-check und no-syn-check auf globaler Ebene verfügbar, um das Verhalten von Service-Gateways zu steuern. Um TCP-Optionen pro Richtlinie zu unterstützen, stehen die folgenden zwei Optionen zur Verfügung:

• sequence-check-required: Der Wert sequence-check-required überschreibt den globalen Wert no-sequence-check.

• syn-check-required: Der Wert syn-check-required überschreibt den globalen Wert no-syn-check.

Um TCP-Optionen pro Richtlinie zu konfigurieren, müssen Sie die entsprechenden globalen Optionen deaktivieren. Andernfalls schlägt die Commit-Prüfung fehl. Wenn globale TCP-Optionen deaktiviert sind und der SYN-Flood-Schutz das erste Paket zulässt, steuern die TCP-Optionen pro Richtlinie, ob SYN- und/oder Sequenzprüfungen durchgeführt werden.

In diesem Beispiel wird gezeigt, wie TCP-Paketsicherheitsprüfungen für jede Richtlinie im Gerät konfiguriert werden.

In diesem Beispiel wird gezeigt, wie TCP-Paketsicherheitsprüfungen im Gerät deaktiviert werden.

Dieses Beispiel zeigt, wie die maximale Segmentgröße für alle TCP-Sitzungen für Firewalls der SRX-Serie festgelegt wird.

Wenn in einem paketvermittelten Netzwerk der Bedarf die verfügbare Kapazität übersteigt, werden die Pakete in die Warteschlange gestellt, um die überschüssigen Pakete zu speichern, bis sich die Warteschlange füllt. Dann werden die Pakete verworfen. Wenn TCP über ein solches Netzwerk arbeitet, ergreift es alle Korrekturmaßnahmen, um eine fehlerfreie End-to-End-Kommunikation aufrechtzuerhalten.

Flow-Module unterstützen bereits die Generierung von RTLOG für sitzungsbasierte Ereignisse wie Sitzungserstellung und -schließung. Firewalls der SRX-Serie unterstützen jetzt die Generierung von RTLOG für paketbasierte Ereignisse wie Paketverluste ohne Sitzung.

Firewalls der SRX-Serie unterstützen die Protokollierung von nicht synchronisierten TCP-Out-of-State-Paketen, die vom Flow-Modul verworfen werden.

Die Protokollierungsfunktion für TCP-Paketverluste außerhalb des Zustands vermeidet Paketverluste und ermöglicht die Paketwiederherstellung, indem die nicht synchronisierten Pakete für eine fehlerfreie Kommunikation protokolliert werden, und verhindert, dass die Datenbankserver nicht mehr synchronisiert werden. Diese Funktion baut auf der Funktion "Sicherheitsprotokoll" (RTLOG) auf.

Die TCP-Paketverlustprotokollierung außerhalb des Zustands unterstützt die Erfassung von TCP-Paketverlustprotokollen unter den folgenden Bedingungen:

• Session ages out– Wenn Cloud-Anwendungen auf langen TCP-Sitzungen ausgeführt werden und diese Anwendungen die TCP-Sitzungen nach Ablauf der Sitzung nicht aktualisieren, werden die TCP-Pakete verworfen. Diese Funktion unterstützt die Protokollierung dieser verworfenen TCP-Pakete.

• Unsynchronized first packets due to attacks or asymmetric routes– Wenn Sie SRX-Serie Firewalls an zwei Standorten bereitstellen und das Routing manchmal asymmetrischen Datenverkehr erzwingt, wird das Synchronisationspaket (SYN) an einem Standort gesehen, aber die Synchronisationsbestätigungspakete (SYN_ACK) werden an einem anderen Standort gesehen.

  Dies bedeutet, dass die Firewall der SRX-Serie ein TCP-ACK-Paket erkennt, für das kein übereinstimmender Statustabelleneintrag vorliegt. Dies kann auftreten, weil die Verbindung für einen bestimmten Zeitraum inaktiv war oder die Verbindungstabellen geleert wurden (z. B. aufgrund einer Richtlinieninstallation oder eines Neustarts).

  Die SYN_ACK Pakete, die in diesem Fall an einem anderen Standort angezeigt werden, wurden von der SRX-Serie Firewall abgelehnt, aber nicht protokolliert. Diese Funktion unterstützt die Protokollierung der abgelehnten SYN_ACK Pakete.

• Other out-of-state conditions (like TCP sequence check fail and synchronization packet received in FIN state)– Wenn eine Firewall der SRX-Serie einen Sequenzfehler erkennt, sich das Gerät im TCP-Vier-Wege-Schließzustand befindet, aber SYN-Pakete empfängt, oder wenn ein dreifacher Handshake-Fehler auftritt, verwirft die Firewall der SRX-Serie die TCP-Pakete und diese verworfenen Pakete werden protokolliert.

• Grundlegendes zur Protokollierung von TCP-Paketverlusten außerhalb des Zustands
• Unterstützte TCP Out-of-State-Protokollierungsfunktionen

Wenn Daten von einem Host zum anderen gesendet werden, werden sie als eine Reihe von Paketen übertragen. Die Leistung wird verbessert und Netzwerkressourcen werden geschont, wenn Pakete der größten Größe den Pfad vom Quellknoten zum Zielknoten passieren können, ohne an einer Verbindung im Datenpfad fragmentiert zu werden. Wenn ein Paket in kleinere Pakete fragmentiert werden muss, um eine Verbindung im Pfad zu übertragen, weil das Paket größer ist als das der maximalen Übertragungseinheit (MTU), die für diese Verbindung festgelegt wurde, muss jedes der resultierenden Fragmente zusätzlich zur Nutzlast oder den Daten Paket-Header-Informationen enthalten. Der erhöhte Overhead kann den Durchsatz verringern und die Netzwerkleistung beeinträchtigen. Außerdem müssen die Paketfragmente am Zielknoten wieder zusammengesetzt werden, was zusätzliche Netzwerkressourcen verbraucht.

Andererseits werden Netzwerkressourcen verschwendet, wenn ein Host Pakete sendet, die viel kleiner als die Pfad-MTU (Path Maximum Transmission Unit) sind, was zu einem suboptimalen Durchsatz führt. Der Pfad-MTU-Erkennungsprozess ermittelt die optimale MTU-Größe für Fragmente, die den Datenpfad vom Quellknoten zum Zielknoten für eine Sitzung übertragen. Die optimale Paketgröße ist also die der Pfad-MTU. Fragmentierung tritt auf, wenn die Größe eines Pakets die Pfad-MTU überschreitet.

Wenn Services auf Anwendungsebene auf der Firewall der SRX-Serie konfiguriert sind, müssen die Paketfragmente an der Eingangsschnittstelle wieder zusammengesetzt werden, bevor die Services angewendet und der Inhalt überprüft werden können. Diese wieder zusammengesetzten Paketfragmente müssen erneut zerlegt werden, bevor die Daten über die Ausgangsschnittstelle übertragen werden. Normalerweise bestimmt die MTU-Größe der Ausgangsschnittstelle die Größe der Fragmente, die von der Firewall der SRX-Serie zur nächsten Verbindung übertragen werden. Es könnte sein, dass die Ausgangs-MTU auf der Firewall der SRX-Serie größer ist als die Pfad-MTU, was wiederum zu einer Paket-Fragmentierung im Datenpfad führen würde, was die Performance verringert oder einen Paketverlust verursachen würde. Paketfragmente müssen klein genug sein, um jede Verbindung auf dem Pfad von der Quelle zum Ziel zu durchlaufen.

Standardmäßig verwendet die Firewall der SRX-Serie die für die Ausgangsschnittstelle konfigurierte MTU-Größe, um die Größe der von ihr übertragenen Paketfragmente zu bestimmen. Wenn Sie jedoch die Funktion zum Beibehalten der Eigenschaften eingehender Fragmente aktivieren, erkennt die Firewall der SRX-Serie die Größe eingehender Paketfragmente und speichert sie.

Um die Wahrscheinlichkeit einer Paket-Fragmentierung im Datenpfad zu verringern, verfolgt die Firewall der SRX-Serie die Ausgangs-MTU für diesen Datenstrom und passt sie an. Es identifiziert die maximale Größe aller eingehenden Fragmente. Es verwendet diese Informationen in Verbindung mit der vorhandenen MTU der Ausgangsschnittstelle, um die richtige MTU-Größe für fragmentierte Pakete zu bestimmen, die über die Ausgangsschnittstelle gesendet werden. Die Firewall der SRX-Serie vergleicht die beiden Zahlen. Es nimmt die kleinere Zahl und verwendet sie für die MTU-Größe der Ausgangsschnittstelle.

Konfigurieren Sie das Gerät mit dem set security flow preserve-incoming-frag-size Befehl, um die Funktion zu aktivieren, die die Größe der eingehenden Paketfragmente berücksichtigt.

Tabelle 1 fasst zusammen, wie die Ausgangs-MTU-Größe der SRX-Serie bestimmt wird.

Die folgenden beiden Überlegungen wirken sich auf die Fragmentgröße aus:

• Bei streambasierten Anwendungen wie Content Sicherheit und ALG könnten die Anwendungen selbst Pakete ändern oder neu zusammensetzen, selbst wenn keine Fragmente empfangen wurden. In diesem Fall wird die vorhandene Ausgangsschnittstelle MTU verwendet.

• Wenn ein Pfad-MTU-Erkennungspaket an eine Sitzung übermittelt wird, wird der Pfad-MTU für diese Sitzung auf den durch das Pfad-MTU-Paket festgelegten Wert zurückgesetzt.

Der TCP-Proxy-Kurzschluss ist auf Ihrem Gerät standardmäßig aktiviert. Er wird automatisch ausgelöst, wenn keine Benutzer (L7-Richtliniendurchsetzungs-Plugins/erweiterte Anwendungsdienste) an der Verwendung des TCP-Proxys für die Sitzung interessiert sind. Nach erfolgreicher TCP-Sitzungseinrichtung und Richtliniendurchsetzung versetzt das Gerät die Sitzung in einen Kurzschlusszustand, sodass nachfolgende Datenpakete direkt zwischen Client und Server fließen können.

Während der anfänglichen Handshake-Phase behält das Gerät das vollständige TCP-Proxyverhalten bei und verwaltet unabhängig voneinander TCP-Status, Sequenznummern und Bestätigungen für beide Seiten der Verbindung. Sobald die Sitzung als legitim und stabil verifiziert wurde, leitet das Gerät keine Sequenznummern mehr weiter und überträgt sie nicht mehr erneut für den Datenverkehr. Stattdessen leitet es Pakete direkt weiter, während die Sitzung weiterhin auf Richtlinienkonformität und Sicherheitsverletzungen überwacht wird.

Der TCP-Proxy-Kurzschluss eignet sich für Bereitstellungen, die eine starke TCP-Sicherheit und -Validierung ohne den langfristigen Leistungs-Overhead eines vollständigen TCP-Proxys erfordern. Sie ist besonders effektiv in Umgebungen mit hohem Durchsatz, wie Datencentern, Service Provider-Edges, und großen Unternehmensnetzwerken.