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. Die Identifizierung dieser Anwendungen ermöglicht Intrusion Detection and Prevention (IDP), geeignete Angriffsobjekte auf Anwendungen anzuwenden, die auf nicht standardmäßigen Ports ausgeführt werden. Es verbessert auch die Leistung, indem der Umfang der Angriffssignaturen für Anwendungen ohne Dekoder begrenzt wird.

Der IDP-Sensor überwacht das Netzwerk und erkennt verdächtigen und anomalen Netzwerkverkehr basierend auf spezifischen Regeln, die in IDP-Regelbasen definiert sind. Es wendet Angriffsobjekte basierend auf Protokollen oder Anwendungen auf den Datenverkehr an. Mithilfe von Anwendungssignaturen kann der Sensor bekannte und unbekannte Anwendungen auf nicht standardmäßigen Ports identifizieren und die richtigen Angriffsobjekte anwenden.

Anwendungssignaturen sind als Teil des Sicherheitspakets von Juniper Networks verfügbar. Sie laden vordefinierte Anwendungssignaturen zusammen mit den Updates des Sicherheitspakets herunter. Sie können keine Anwendungssignaturen erstellen. Informationen zum Herunterladen des Sicherheitspakets finden Sie unter Übersicht über die manuelle Aktualisierung der IDP-Signaturdatenbank.

Auf allen Zweigstellengeräten der SRX-Serie beträgt die maximal unterstützte Anzahl von Einträgen in der ASC-Tabelle 100.000 Einträge. Da der Benutzerlandpuffer eine feste Größe von 1 MB als Einschränkung hat, zeigt die Tabelle maximal 38.837 Cache-Einträge an.

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 im Standardprofil von NFX150-S1 und 64.000 auf SD-WAN-Profilen 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 anstelle des Anwendungsidentifizierungsergebnisses. Anweisungen zum Festlegen von Anwendungen in Richtlinienregeln finden Sie unter Beispiel: Konfigurieren von IDP-Anwendungen und -Services.

Hinweis:

Die Anwendungsidentifizierung ist standardmäßig aktiviert. Informationen zur Deaktivierung der Anwendungsidentifizierung mit der Befehlszeilenschnittstelle finden Sie unter Deaktivieren und Erneutes Deaktivieren der Junos OS-Anwendungsidentifizierung.

Auf allen Zweigstellengeräten der SRX-Serie erlaubt IDP keine Header-Überprüfungen für Kontexte, die keine Paketpakete enthalten.

IDP, die sowohl in aktiv/aktiv als auch aktiv/passiv Chassis-Clustern bereitgestellt wird, hat die folgenden Einschränkungen:

• Keine Überprüfung von Sitzungen, die über- oder zurückfallen.

• Die IP-Aktionstabelle ist nicht über Knoten hinweg 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 ist nicht über Knoten hinweg synchronisiert. Wenn eine SSL-Sitzung eine Sitzungs-ID wiederverwendet und sie zufällig auf einem anderen Knoten als dem, auf dem die Sitzungs-ID zwischengespeichert wird, 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, hat eine Einschränkung, dass der zeitgebundene Quelldatenverkehr, wenn Angriffe von einer Quelle (mit mehr als einem Ziel) aktive Sitzungen haben, die über Knoten verteilt sind, der Angriff möglicherweise nicht erkannt wird, weil die Zeitbindungszählung über eine ansicht von nur einem lokalen Knoten verfügt. 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 binden und haben keine Servicedefinition. Sie binden an eine Anwendung basierend auf dem Namen eines Kontextes 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 Servicebindung zutrifft oder nicht, hängt von der vollständigen Definition des Angriffsobjekts sowie von der IDP-Richtlinienkonfiguration ab:

• Wenn Sie eine Anwendung in einer Angriffsobjektdefinition angeben, wird das Dienstfeld ignoriert. Das Angriffsobjekt ist an die Anwendung und nicht an den angegebenen Dienst gebunden. Wenn Sie jedoch einen Dienst und keine Anwendung in der Angriffsobjektdefinition angeben, wird das Angriffsobjekt an den Dienst gebunden. Tabelle 1 fasst das Verhalten von Anwendungs- und Dienstbindungen mit Anwendungsidentifizierung zusammen.

  Tabelle 1: Anwendungen und Services mit Anwendungsidentifizierung

  Angriffsobjektfelder	Bindungsverhalten	Anwendungsidentifizierung
  :application (http) :service (smtp)	Bindet an das Anwendungs-HTTP. Das Servicefeld wird ignoriert.	Aktiviert
  :service (http)	Bindet an das Anwendungs-HTTP.	Aktiviert
  :service (tcp/80)	Bindet an TCP-Port 80.	Deaktiviert

  In der folgenden Angriffsobjektdefinition bindet sich das Angriffsobjekt beispielsweise an das Anwendungs-HTTP, die Anwendungsidentifizierung ist aktiviert und das Dienstfeld 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 im Angriffsobjekt angeben, wird daher die Anwendungsidentifizierung 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	Bindet an die Anwendung oder den Dienst, die in der Angriffsobjektdefinition konfiguriert wurde.	Aktiviert für anwendungsbasierte Angriffsobjekte Deaktiviert für servicebasierte Angriffsobjekte
  Specific application	Bindet an die Anwendung, die in der Angriffsobjektdefinition angegeben ist.	Deaktiviert
  Any	Bindet an alle Anwendungen.	Deaktiviert

• Wenn Sie eine Anwendung in einer IDP-Richtlinie angeben, muss der in der Angriffsobjektdefinition und in der IDP-Richtlinie konfigurierte Anwendungstyp übereinstimmen. Die Richtlinienregel kann keine zwei verschiedenen Anwendungen angeben (eine im Angriffsobjekt und die andere in der Richtlinie).

Hinweis:

Anwendung kann nicht sein any , wenn Angriffe, die auf verschiedenen Anwendungen basieren, in der IDP-Konfiguration angegeben werden und commit fehlschlägt. Verwenden Sie stattdessen den Standard.

Während der Konfiguration von IDS-Regeln für Anwendungen ist die Option any veraltet.

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

Mit der größeren Nutzung der Anwendungsprotokollkapselung 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 besteht die Notwendigkeit, sie als zwei verschiedene Anwendungen zu identifizieren, die auf demselben Layer-7-Protokoll ausgeführt werden. Um dies zu tun, wird die aktuelle Anwendungsidentifizierungsebene in zwei Ebenen aufgeteilt: Layer-7-Anwendungen und Layer-7-Protokolle.

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

Dieses Beispiel zeigt, wie Sie die IDP-Richtlinien für die Anwendungsidentifizierung konfigurieren.

Sie können zwar keine Anwendungssignaturen mit der IDP-Signaturdatenbank erstellen, aber Sie können Sensoreinstellungen konfigurieren, um die Anzahl der Sitzungen zu begrenzen, in denen die Anwendungsidentifizierung ausgeführt wird, und auch die Speichernutzung für die Anwendungsidentifizierung einzuschränken.

Speicherlimit für eine Sitzung: Sie können die maximale Menge an Speicherbytes konfigurieren, die zum Speichern von Paketen für die Anwendungsidentifizierung für eine TCP- oder UDP-Sitzung verwendet werden kann. Sie können auch ein Limit für die globale Speichernutzung für die Anwendungsidentifizierung konfigurieren. Die Anwendungsidentifizierung wird für eine Sitzung deaktiviert, nachdem das System die angegebene Speichergrenze für die Sitzung erreicht hat. IdP passt jedoch weiterhin zu Mustern. Die passende Anwendung wird im Cache gespeichert, sodass sie in der nächsten Sitzung verwendet werden 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 der Sitzungen: Sie können die maximale Anzahl von Sitzungen konfigurieren, die gleichzeitig die Anwendungsidentifizierung ausführen können. Die Anwendungsidentifizierung ist deaktiviert, nachdem das System die angegebene Anzahl von Sitzungen erreicht hat. Sie begrenzen die Anzahl der Sitzungen, sodass Sie einen Denial-of-Service-Angriff (DOS) verhindern können, der auftritt, wenn zu viele Verbindungsanfragen überlastet sind und alle zugewiesenen Ressourcen im System ausschöpfen.

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

Tabelle 3: Maximale Anzahl der CP-Sitzungen

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

Dieses Beispiel zeigt, wie Sie Die Speichergrenzen für IDP-Anwendungsidentifizierungsdienste konfigurieren.

• Zweck
• Aktion
• Bedeutung