IDP Identifizieren von Anwendungen

Juniper Networks bietet vordefinierte Anwendungssignaturen, die Transmission Control Protocol (TCP)- und User Datagram Protocol (UDP)-Anwendungen erkennen, die auf nicht standardmäßigen Ports ausgeführt werden. Durch die Identifizierung dieser Anwendungen Intrusion Detection and Prevention (IDP), entsprechende Angriffsobjekte auf Anwendungen auf nicht standardmäßigen Ports anzuwenden. Sie verbessert außerdem die Leistung, indem die Reichweite von Angriffssignaturen für Anwendungen ohne Decoder verringert wird.

Der IDP-Sensor überwacht das Netzwerk und erkennt verdächtigen und anomalen Netzwerkdatenverkehr basierend auf bestimmten Regeln, die in bestimmten Regeldatenbanken IDP werden. Es wendet Angriffsobjekte auf Datenverkehr basierend auf Protokollen oder Anwendungen an. Mit Anwendungssignaturen kann der Sensor bekannte und unbekannte Anwendungen identifizieren, die auf nicht standardmäßigen Ports ausgeführt werden, und die richtigen Angriffsobjekte anwenden.

Anwendungssignaturen sind als Teil des von ihnen bereitgestellten Sicherheitspakets Juniper Networks. Sie laden vordefinierte Anwendungssignaturen zusammen mit den Sicherheitspaket-Updates herunter. Anwendungssignaturen können nicht erstellt werden. Informationen zum Herunterladen des Sicherheitspakets finden Sie unter Aktualisierung der Signaturdatenbank IDP Manueller Überblick.

Auf allen Geräten der SRX-Serie für Zweigstellen beträgt die maximale Anzahl von Einträgen in der ASC-Tabelle 100.000 Einträge. Da der Landpuffer des Benutzers eine feste Größe von 1 MB als Einschränkung hat, wird in der Tabelle maximal 38.837 Cache-Einträge angezeigt.

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

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

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

Hinweis:

Die Anwendungsidentifikation ist standardmäßig aktiviert. Um die Anwendungsidentifikation mit der CLI deaktivieren und erneuten abschalten, Junos OS Anwendungsidentifikation .

Auf allen Geräten der SRX-Serie für Zweigstellen IDP header-Prüfungen für nicht paketgeedeckte Kontexte nicht zu.

IDP werden sowohl in Aktiv/Aktiv- als auch Aktiv/Passiv-Chassis-Clustern bereitgestellt, hat folgende Einschränkungen:

• Keine Prüfung von Sitzungen, die ausfallen oder ausfallen.

• Die IP-Aktionstabelle wird nicht zwischen Knoten synchronisiert.

• Der Routing-Engine auf dem sekundären Knoten kann möglicherweise keine Netzwerke erreichen, die nur über eine bestimmte Packet Forwarding Engine.

• Der SSL-Sitzungs-ID-Cache wird nicht zwischen Knoten synchronisiert. Wenn eine SSL-Sitzung eine Sitzungs-ID wiederverwendet und auf einem anderen Knoten als dem, auf dem die Sitzungs-ID gespeichert ist, verarbeitet wird, kann die SSL-Sitzung nicht entschlüsselt und zur Prüfung der IDP werden.

IDP, die in Aktiv/Aktiv-Chassis-Clustern bereitgestellt werden, hat eine Einschränkung für den zeitvermittelten Scope-Quelldatenverkehr. Wenn bei Angriffen einer Quelle (mit mehr als einem Ziel) aktive Sitzungen über mehrere Knoten verteilt werden, kann der Angriff möglicherweise nicht erkannt werden, da die Zeitbindung eine Ansicht auf einen lokalen Knoten zählt. Die Erkennung dieser Art von Angriff erfordert eine RTO-Synchronisierung des Zeitbindungsstatus, der derzeit nicht unterstützt wird.

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

• Angriffsobjekte können implizit an eine Anwendung gebunden werden, die keine Dienstdefinition hat. Sie binden an eine Anwendung, die auf dem Namen eines Kontextes oder einer Anomalie basiert.

• Angriffsobjekte können unter Verwendung eines Dienstnamens an einen Service gebunden sein.

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

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

• Wenn Sie eine Anwendung in einer Angriffsobjektdefinition angeben, wird das Servicefeld ignoriert. Das Angriffsobjekt ist an die Anwendung und nicht an den angegebenen Service gebunden. Wenn Sie jedoch einen Service und keine Anwendung in der Definition des Angriffsobjekts angeben, ist das Angriffsobjekt an den Service gebunden. Tabelle 1 fasst das Verhalten der Anwendungs- und Dienstbindung mit Anwendungsidentifizierung zusammen.

  Tabelle 1: Anwendungen und Services mit Anwendungsidentifikation

  Angriffsobjekt-Felder	Bindungsverhalten	Identifizieren von Anwendungen
  :application (http) :service (smtp)	Bindet an die Http-Anwendung. Das Servicefeld wird ignoriert.	Aktiviert
  :service (http)	Bindet an die Http-Anwendung.	Aktiviert
  :service (tcp/80)	Bindet an TCP-Port 80.	Deaktiviert

  In der folgenden Definition des Angriffsobjekts ist das Angriffsobjekt beispielsweise an die Anwendung HTTPgebunden. Die Anwendungsidentifikation wird 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 Service-Felder ignoriert. Servicekontexte und -anomalien bedeuten eine Anwendung; Wenn Sie diese im Angriffsobjekt angeben, wird die Anwendungsidentifizierung angewendet.

• Wenn Sie eine bestimmte Anwendung in einer Richtlinie konfigurieren, überschreiben Sie die für ein Angriffsobjekt angegebene Anwendungsbindung. Tabelle 2 fasst die Anbindung mit der Anwendungskonfiguration in der IDP zusammen.

  Tabelle 2: Anwendungskonfiguration in einer IDP Richtlinie

  Anwendungstyp in der Richtlinie	Bindungsverhalten	Identifizieren von Anwendungen
  Default	Bindet sich an die Anwendung oder den Service, die in der Definition des Angriffsobjekts konfiguriert sind.	Für anwendungsbasierte Angriffsobjekte aktiviert Deaktiviert für servicebasierte Angriffsobjekte
  Specific application	Bindet an die in der Definition des Angriffsobjekts angegebene Anwendung.	Deaktiviert
  Any	Bindet an alle Anwendungen.	Deaktiviert

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

Hinweis:

Die Anwendung kann nicht sein, wenn Angriffe auf der Basis unterschiedlicher any Anwendungen in der Konfiguration IDP commit ausfallen. Verwenden Sie stattdessen Standard.

Während die Konfiguration IDS-Regeln für die Anwendung ist die Option any nicht mehr erhältlich.

Wenn es sich jedoch um eine Anwendung handelt und benutzerdefinierte Angriffsgruppen in einer Konfigurationskonfiguration IDP any werden, wird "commit" erfolgreich durchgeführt. Eine Commit-Prüfung erkennt solche Fälle also nicht.

Im Zusammenhang mit der stärkeren Nutzung der Anwendungsprotokollkapselung ist es notwendig, die Identifizierung mehrerer verschiedener Anwendungen zu unterstützen, die auf denselben Layer-7-Protokollen ausgeführt werden. Anwendungen wie Facebook und Yahoo Chat können zum Beispiel beide über HTTP ausgeführt werden. Es ist jedoch notwendig, sie als zwei unterschiedliche Anwendungen zu identifizieren, die auf demselben Layer-7-Protokoll ausgeführt werden. Hierzu ist die aktuelle Anwendungsidentifizierungsebene in zwei Ebenen aufgeteilt: Layer-7-Anwendungen und Layer-7-Protokolle.

Die hier enthaltenen vordefinierten 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 Richtlinien IDP zur Anwendungsidentifizierung konfiguriert werden.

Obwohl Sie mit IDP der Signaturdatenbank keine Anwendungssignaturen erstellen können, können Sie Sensoreinstellungen konfigurieren, um die Anzahl der Sitzungen, in denen die Anwendungsidentifikation ausgeführt wird, zu begrenzen und die Speichernutzung für die Anwendungsidentifikation zu begrenzen.

Speicherbegrenzung für eine Sitzung: Sie können die maximale Anzahl an Speicherbytes konfigurieren, die zum Speichern von Paketen zur Anwendungsidentifikation für eine TCP- oder UDP-Sitzung verwendet werden können. Sie können auch eine Begrenzung der globalen Speicherauslastung zur Anwendungsidentifizierung konfigurieren. Die Anwendungsidentifikation ist für eine Sitzung deaktiviert, nachdem das System die angegebene Speicherbegrenzung für die Sitzung erreicht hat. Diese IDP sich jedoch weiterhin an die Muster an. Die angezeigte Anwendung wird im Cache gespeichert, damit die nächste Sitzung sie verwenden kann. Dies schützt das System vor Angreifern, die versuchen, die Anwendungsidentifizierung zu umgehen, indem sie gezielt große Client-to-Server-Pakete senden.

• Anzahl von Sitzungen: Sie können die maximale Anzahl von Sitzungen konfigurieren, die gleichzeitig mit der Anwendungsidentifizierung ausgeführt werden kann. Die Anwendungsidentifikation ist deaktiviert, nachdem das System die angegebene Anzahl von Sitzungen erreicht hat. Sie begrenzen die Anzahl der Sitzungen, um einen Denial-of-Service (DOS)-Angriff zu verhindern, der entsteht, wenn zu viele Verbindungsanfragen überlastet werden und alle zugewiesenen Ressourcen im System überlastet werden.

Tabelle 3 enthält die Kapazität einer central Point (CP)-Sitzungsnummern für SRX3400, SRX3600, SRX5600 und SRX5800 Geräten.

Anzahl von CP-Sitzungen

Tabelle 3: Maximale

Geräte der SRX-Serie	Maximale Anzahl Sitzungen	Central Point (CP)
SRX3400	2,25 Millionen	Combo-Modus CP
SRX3600	2,25 Millionen	Combo-Modus CP
SRX5600	9 Millionen 2,25 Millionen	Vollständige CP Combo-Modus CP
SRX5800	10 Millionen 2,25 Millionen	Vollständige CP Combo-Modus CP

In diesem Beispiel wird gezeigt, wie Sie die Speicherbeschränkungen für Anwendungen IDP identifizierungsdienste konfigurieren.

• Zweck
• Aktion
• Bedeutung