IDP-Anwendungsidentifizierung

Juniper Networks stellt vordefinierte Anwendungssignaturen bereit, die TCP- (Transmission Control Protocol) und UDP-Anwendungen (User Datagram Protocol) erkennen, die auf nicht standardmäßigen Ports ausgeführt werden. Durch die Identifizierung dieser Anwendungen kann Intrusion Detection and Prevention (IDP) geeignete Angriffsobjekte auf Anwendungen anwenden, die auf nicht standardmäßigen Ports ausgeführt werden. Außerdem wird die Leistung verbessert, indem der Umfang der Angriffssignaturen für Anwendungen ohne Decoder eingeschränkt wird.

Der IDP-Sensor überwacht das Netzwerk und erkennt verdächtigen und anomalen Netzwerkverkehr auf der Grundlage spezieller Regeln, die in IDP-Regelbasen definiert sind. Sie wendet Angriffsobjekte auf den Datenverkehr an, der auf Protokollen oder Anwendungen basiert. Anwendungssignaturen ermöglichen es dem Sensor, bekannte und unbekannte Anwendungen zu identifizieren, die auf nicht standardmäßigen Ports ausgeführt werden, und die richtigen Angriffsobjekte anzuwenden.

Anwendungssignaturen sind als Teil des Sicherheitspakets von Juniper Networks verfügbar. Sie laden vordefinierte Anwendungssignaturen zusammen mit den Sicherheitspaket-Updates herunter. Anwendungssignaturen können nicht erstellt werden. Informationen zum Herunterladen des Sicherheitspakets finden Sie unter Manuelles Aktualisieren der IDP-Signaturdatenbank – Übersicht.

Bei allen Firewalls der SRX-Serie für Zweigstellen wird maximal 100.000 Einträge in der ASC-Tabelle unterstützt. Da der Puffer für das Benutzerland eine feste Größe von 1 MB als Einschränkung hat, werden in der Tabelle maximal 38.837 Cacheeinträge angezeigt.

Die maximale Anzahl der unterstützten IDP-Sitzungen beträgt 16.384 auf SRX320-Geräten und 32.768 auf SRX345-Geräten.

Die maximale Anzahl der unterstützten IDP-Sitzungen beträgt 8000 im Standardprofil von NFX150-C-S1-Geräten und 16.000 im SD-WAN-Profil von NFX150-C-S1-Geräten. Die maximale Anzahl der unterstützten IDP-Sitzungen beträgt 8000 auf dem Standardprofil von NFX150-S1 und 64.000 auf dem SD-WAN-Profil von NFX150-S1-Geräten.

Die Anwendungsidentifizierung ist standardmäßig nur aktiviert, wenn der Dienst, der die Anwendungsidentifizierung anfordert (z. B. IDP, AppFW, AppTrack oder AppQoS), aktiviert ist, um die Anwendungsidentifizierung aufzurufen. Wenn keine dieser Richtlinien oder Konfigurationen vorhanden ist, wird die Anwendungsidentifizierung nicht automatisch ausgelöst. Wenn Sie jedoch eine Anwendung in der Richtlinienregel angeben, verwendet IDP die angegebene Anwendung und nicht das Ergebnis der Anwendungsidentifikation. Anweisungen zum Angeben von Anwendungen in Richtlinienregeln finden Sie unter Beispiel: Konfigurieren von IDP-Anwendungen und -Diensten.

Anmerkung:

Die Anwendungsidentifizierung ist standardmäßig aktiviert. Informationen zum Deaktivieren der Anwendungsidentifizierung über die CLI finden Sie unter Deaktivieren und erneutes Aktivieren der Junos OS-Anwendungsidentifizierung.

Bei allen Firewalls der SRX-Serie für Zweigstellen lässt IDP keine Header-Prüfungen für Nicht-Paketkontexte zu.

Für IDP, das sowohl in aktiven/aktiven als auch in aktiven/passiven Chassis-Clustern bereitgestellt wird, gelten die folgenden Einschränkungen:

• Keine Überprüfung von Sitzungen, für die ein Failover oder Failback ausgeführt wird.

• Die IP-Aktionstabelle wird nicht knotenübergreifend synchronisiert.

• Die Routing-Engine auf dem sekundären Knoten ist möglicherweise nicht in der Lage, Netzwerke zu erreichen, die nur über eine Packet Forwarding Engine erreichbar sind.

• Der SSL-Sitzungs-ID-Cache wird nicht knotenübergreifend synchronisiert. Wenn eine SSL-Sitzung eine Sitzungs-ID wiederverwendet und auf einem anderen Knoten als dem, auf dem die Sitzungs-ID zwischengespeichert ist, verarbeitet wird, kann die SSL-Sitzung nicht entschlüsselt werden und wird für die IDP-Prüfung umgangen.

IDP, das in Aktiv/Aktiv-Chassis-Clustern bereitgestellt wird, weist eine Einschränkung auf, die besagt, dass der Angriff bei Angriffen von einer Quelle (mit mehr als einem Ziel) mit aktiven Sitzungen, die über Knoten verteilt sind, möglicherweise nicht erkannt wird, da die zeitgebundene Zählung eine Ansicht nur für lokale Knoten aufweist. Die Erkennung dieser Art von Angriffen erfordert eine RTO-Synchronisierung des Zeitbindungszustands, der derzeit nicht unterstützt wird.

Angriffsobjekte können auf unterschiedliche Weise an Anwendungen und Services gebunden werden:

• Angriffsobjekte können implizit an eine Anwendung gebunden werden und verfügen nicht über eine Dienstdefinition. Sie binden sich an eine Anwendung basierend auf dem Namen eines Kontexts oder einer Anomalie.

• Angriffsobjekte können über einen Dienstnamen an einen Dienst gebunden werden.

• Angriffsobjekte können über TCP- oder UDP-Ports, ICMP-Typen oder -Codes oder RPC-Programmnummern an einen Dienst gebunden werden.

Ob die angegebene Anwendungs- oder Dienstbindung zutrifft oder nicht, hängt von der vollständigen Definition des Angriffsobjekts sowie der Konfiguration der IDP-Richtlinie ab:

• Wenn Sie eine Anwendung in einer Angriffsobjektdefinition angeben, wird das Servicefeld ignoriert. Das Angriffsobjekt bindet sich an die Anwendung und nicht an den angegebenen Dienst. Wenn Sie jedoch einen Dienst und keine Anwendung in der Definition des Angriffsobjekts angeben, wird das Angriffsobjekt an den Dienst gebunden. Tabelle 1 fasst das Verhalten von Anwendungs- und Dienstbindungen mit Anwendungsidentifikation zusammen.

  Tabelle 1: Anwendungen und Dienste mit Anwendungsidentifikation

  Felder für Angriffsobjekte	Bindungsverhalten	Anwendungsidentifizierung
  :application (http) :service (smtp)	Stellt eine Bindung an die HTTP-Anwendung her. Das Servicefeld wird ignoriert.	Ermöglichte
  :service (http)	Stellt eine Bindung an die HTTP-Anwendung her.	Ermöglichte
  :service (tcp/80)	Stellt eine Bindung an TCP-Port 80 her.	Arbeitsunfähig

  In der folgenden Angriffsobjektdefinition bindet das Angriffsobjekt beispielsweise an die Anwendung HTTP, die Anwendungsidentifikation ist aktiviert, und das Servicefeld SMTP wird ignoriert.

• Wenn ein Angriffsobjekt auf servicespezifischen Kontexten (z. B. http-url) und Anomalien (z. B. tftp_file_name_too_long) basiert, werden sowohl Anwendungs- als auch Servicefelder ignoriert. Servicekontexte und Anomalien implizieren Anwendung; Wenn Sie diese also im Angriffsobjekt angeben, wird die Anwendungsidentifikation angewendet.

• Wenn Sie eine bestimmte Anwendung in einer Richtlinie konfigurieren, überschreiben Sie die in einem Angriffsobjekt angegebene Anwendungsbindung. Tabelle 2 fasst die Bindung mit der Anwendungskonfiguration in der IDP-Richtlinie zusammen.

  Tabelle 2: Anwendungskonfiguration in einer IDP-Richtlinie

  Anwendungstyp in der Richtlinie	Bindungsverhalten	Anwendungsidentifizierung
  Default	Stellt eine Bindung an die Anwendung oder den Dienst her, die bzw. der in der Definition des Angriffsobjekts konfiguriert ist.	Aktiviert für anwendungsbasierte Angriffsobjekte Deaktiviert für servicebasierte Angriffsobjekte
  Specific application	Stellt eine Bindung an die Anwendung her, die in der Definition des Angriffsobjekts angegeben ist.	Arbeitsunfähig
  Any	Bindet an alle Anwendungen.	Arbeitsunfähig

• Wenn Sie eine Anwendung in einer IDP-Richtlinie angeben, muss der in der Definition des Angriffsobjekts und in der IDP-Richtlinie konfigurierte Anwendungstyp übereinstimmen. Die Richtlinienregel kann nicht zwei verschiedene Anwendungen angeben (eine im Angriffsobjekt und die andere in der Richtlinie).

Anmerkung:

Anwendung kann nicht sein any , wenn Angriffe, die auf verschiedenen Anwendungen basieren, in der IDP-Konfiguration angegeben sind und der Commit fehlschlägt. Verwenden Sie stattdessen die Standardeinstellung.

Bei der Konfiguration von IDS-Regeln für die Anwendung ist die Option any veraltet.

Wenn jedoch Anwendungs any - und benutzerdefinierte Angriffsgruppen in der IDP-Konfiguration verwendet werden, wird der Commit erfolgreich durchgeführt. Daher erkennt die Commit-Prüfung solche Fälle nicht.

Mit der zunehmenden Verwendung der Kapselung von Anwendungsprotokollen entsteht die Notwendigkeit, die Identifizierung mehrerer verschiedener Anwendungen zu unterstützen, die auf denselben Layer-7-Protokollen ausgeführt werden. Beispielsweise können Anwendungen wie Facebook und Yahoo Messenger beide über HTTP ausgeführt werden, aber es ist notwendig, sie als zwei verschiedene Anwendungen zu identifizieren, die auf demselben Layer-7-Protokoll ausgeführt werden. Zu diesem Zweck wird die aktuelle Anwendungsidentifikationsschicht in zwei Schichten aufgeteilt: Layer-7-Anwendungen und Layer-7-Protokolle.

Integrierte vordefinierte Anwendungssignaturen wurden erstellt, um die Layer-7-Anwendungen zu erkennen, während die vorhandenen Layer-7-Protokollsignaturen weiterhin auf die gleiche Weise funktionieren. Diese vordefinierten Anwendungssignaturen können in Angriffsobjekten verwendet werden.

In diesem Beispiel wird gezeigt, wie die IDP-Richtlinien für die Anwendungsidentifizierung konfiguriert werden.

Obwohl Sie mit der IDP-Signaturdatenbank keine Anwendungssignaturen erstellen können, können Sie die Sensoreinstellungen so konfigurieren, dass die Anzahl der Sitzungen, in denen die Anwendungsidentifizierung ausgeführt wird, sowie die Speicherauslastung für die Anwendungsidentifikation begrenzt wird.

Speicherlimit für eine Sitzung: Sie können die maximale Anzahl von Speicherbytes konfigurieren, die zum Speichern von Paketen zur Anwendungsidentifikation für eine TCP- oder UDP-Sitzung verwendet werden können. Sie können auch einen Grenzwert für die globale Speichernutzung zur Anwendungsidentifikation konfigurieren. Die Anwendungsidentifizierung wird für eine Sitzung deaktiviert, nachdem das System das angegebene Speicherlimit für die Sitzung erreicht hat. IDP stimmt jedoch weiterhin mit Mustern überein. Die übereinstimmende Anwendung wird im Cache gespeichert, damit sie in der nächsten Sitzung verwendet werden kann. Dies schützt das System vor Angreifern, die versuchen, die Anwendungsidentifizierung zu umgehen, indem sie absichtlich große Client-zu-Server-Pakete senden.

• Anzahl der Sitzungen: Sie können die maximale Anzahl von Sitzungen konfigurieren, die gleichzeitig die Anwendungsidentifizierung ausführen können. Die Anwendungsidentifizierung wird deaktiviert, nachdem das System die angegebene Anzahl von Sitzungen erreicht hat. Sie begrenzen die Anzahl der Sitzungen, um einen Denial-of-Service-Angriff (DOS) zu verhindern, der auftritt, wenn zu viele Verbindungsanforderungen alle zugeordneten Ressourcen auf dem System überfordern und erschöpfen.

Tabelle 3 gibt die Kapazität der Sitzungsnummern eines zentralen Punktes (CP) für SRX3400-, SRX3600-, SRX5600- und SRX5800 Geräte an.

Tabelle 3: Maximale Anzahl von CP-Sitzungen

Geräte der SRX-Serie	Maximale Anzahl an Sitzungen	Zentralstelle (CP)
SRX3400	2,25 Millionen	Combo-Modus CP
SRX3600	2,25 Millionen	Combo-Modus CP
SRX5600	9 Millionen 2,25 Millionen	Volle CP Combo-Modus CP
SRX5800	10 Millionen 2,25 Millionen	Volle CP Combo-Modus CP

In diesem Beispiel wird gezeigt, wie Arbeitsspeichergrenzwerte für IDP-Anwendungsidentifikationsdienste konfiguriert werden.

• Zweck
• Aktion
• Bedeutung

Verwenden Sie Funktionen entdecken, um die Plattform- und Releaseunterstützung für bestimmte Funktionen zu bestätigen. Möglicherweise werden weitere Plattformen unterstützt.

Verwenden Sie die folgende Tabelle, um zusätzliche Plattforminformationen zu überprüfen.

Firewall der SRX-Serie Maximale	Anzahl an Sitzungen	Central Point (CP)
SRX5600	9 Millionen 2,25 Millionen	Volle CP Combo-Modus CP
SRX5800	10 Millionen 2,25 Millionen	Volle CP Combo-Modus CP

Verwenden Sie Funktionen entdecken, um die Plattform- und Releaseunterstützung für bestimmte Funktionen zu bestätigen.

Verwenden Sie die folgende Tabelle, um plattformspezifische Verhaltensweisen für Ihre Plattform zu überprüfen.

Bahnsteig	Unterschied
Firewalls der SRX-Serie	SRX320-Firewall, die IDP AppID unterstützt, unterstützt maximal 16.384 IDP-Sitzungen. Firewall SRX345, die IDP unterstützt AppID unterstützt maximal 32.768 IDP-Sitzungen.