Identification des applications IDP

Juniper Networks fournit des signatures d’application prédéfinies qui détectent les applications TCP (Transmission Control Protocol) et UDP (User Datagram Protocol) exécutées sur des ports non standard. L’identification de ces applications permet à la détection et prévention d’intrusion (IDP) d’appliquer les objets d’attaque appropriés aux applications exécutées sur des ports non standard. Elle améliore également les performances en réduisant la portée des signatures d’attaque pour les applications sans décodeur.

Le capteur IDP surveille le réseau et détecte le trafic réseau suspect et anormal en fonction de règles spécifiques définies dans les bases de règles IDP. Elle applique des objets d’attaque au trafic en fonction de protocoles ou d’applications. Les signatures d’application permettent au capteur d’identifier les applications connues et inconnues exécutées sur des ports non standard et d’appliquer les objets d’attaque appropriés.

Les signatures d’application sont disponibles dans le package de sécurité fourni par Juniper Networks. Vous téléchargez les signatures d’application prédéfinies en même temps que les mises à jour du package de sécurité. Vous ne pouvez pas créer de signatures d’application. Pour plus d’informations sur le téléchargement du package de sécurité, reportez-vous à la section Mise à jour manuelle de la base de données de signatures IDP.

Sur tous les pare-feu SRX Series de filiale, le nombre maximal d’entrées prises en charge dans la table ASC est de 100 000 entrées. Étant donné que la mémoire tampon de terrain utilisateur a une taille fixe de 1 Mo comme limitation, la table affiche un maximum de 38 837 entrées de cache.

Le nombre maximal de sessions IDP prises en charge est de 16 384 sur les appareils SRX320 et de 32 768 sur les appareils SRX345.

Le nombre maximal de sessions IDP prises en charge est de 8 000 sur le profil par défaut des équipements NFX150-C-S1 et de 16 000 sur le profil SD-WAN des équipements NFX150-C-S1. Le nombre maximal de sessions IDP prises en charge est de 8 000 sur le profil par défaut de NFX150-S1 et de 64 000 sur le profil SD-WAN des équipements NFX150-S1.

L’identification de l’application est activée par défaut uniquement si le service demandant l’identification de l’application (par exemple, IDP, AppFW, AppTrack ou AppQoS) est activé pour appeler l’identification de l’application. Si aucune de ces stratégies ou configurations n’existe, l’identification de l’application ne sera pas automatiquement déclenchée. Toutefois, lorsque vous spécifiez une application dans la règle de stratégie, IDP utilise l’application spécifiée plutôt que le résultat de l’identification de l’application. Pour obtenir des instructions sur la spécification des applications dans les règles de stratégie, consultez Exemple : Configuration d’applications et de services IDP.

Note:

L’identification des applications est activée par défaut. Pour désactiver l’identification des applications à l’aide de la CLI, reportez-vous à la section Désactivation et réactivation de l’identification des applications Junos OS.

Sur tous les pare-feu SRX Series de filiale, IDP n’autorise pas les vérifications d’en-tête pour les contextes autres que les paquets.

Le protocole IDP déployé dans des clusters de châssis actif/actif et actif/passif présente les limitations suivantes :

• Aucune inspection des sessions de basculement ou de restauration automatique.

• La table d’actions IP n’est pas synchronisée entre les nœuds.

• Le moteur de routage sur le nœud secondaire peut ne pas être en mesure d’atteindre les réseaux qui ne sont accessibles que par le biais d’un moteur de transfert de paquets.

• Le cache d’ID de session SSL n’est pas synchronisé entre les nœuds. Si une session SSL réutilise un ID de session et qu’elle est traitée sur un nœud autre que celui sur lequel l’ID de session est mis en cache, la session SSL ne peut pas être déchiffrée et sera contournée pour l’inspection IDP.

Le protocole IDP déployé dans des clusters de châssis actifs/actifs présente une limitation : pour le trafic source à liaison temporelle, si les attaques provenant d’une source (avec plusieurs destinations) ont des sessions actives réparties sur des nœuds, l’attaque peut ne pas être détectée, car le comptage des liaisons temporelles a une vue sur les nœuds locaux uniquement. La détection de ce type d’attaque nécessite une synchronisation RTO de l’état de liaison temporelle, ce qui n’est pas actuellement pris en charge.

Les objets d’attaque peuvent se lier aux applications et aux services de différentes manières :

• Les objets d’attaque peuvent se lier implicitement à une application et ne pas avoir de définition de service. Ils se lient à une application en fonction du nom d’un contexte ou d’une anomalie.

• Les objets d’attaque peuvent se lier à un service à l’aide d’un nom de service.

• Les objets d’attaque peuvent se lier à un service à l’aide de ports TCP ou UDP, de types ou de codes ICMP ou de numéros de programme RPC.

L’application ou la liaison de service spécifiée dépend de la définition complète de l’objet d’attaque ainsi que de la configuration de la stratégie IDP :

• Si vous spécifiez une application dans une définition d’objet d’attaque, le champ de service est ignoré. L’objet d’attaque se lie à l’application au lieu du service spécifié. Toutefois, si vous spécifiez un service et aucune application dans la définition de l’objet d’attaque, l’objet d’attaque est lié au service. Le Tableau 1 résume le comportement des liaisons d’application et de service avec identification des applications.

  Tableau 1 : applications et services avec identification de l’application

  Champs d’objet d’attaque	Comportement de liaison	Identification des applications
  :application (http) :service (smtp)	Se lie à l’application HTTP. Le champ de service est ignoré.	Activé
  :service (http)	Se lie à l’application HTTP.	Activé
  :service (tcp/80)	Se lie au port TCP 80.	Handicapé

  Par exemple, dans la définition suivante de l’objet d’attaque, l’objet d’attaque se lie au protocole HTTP de l’application, l’identification de l’application est activée et le champ de service SMTP est ignoré.

• Si un objet d’attaque est basé sur des contextes spécifiques au service (par exemple, http-url) et des anomalies (par exemple, tftp_file_name_too_long), les champs d’application et de service sont ignorés. Les contextes de service et les anomalies impliquent une application ; Ainsi, lorsque vous les spécifiez dans l’objet d’attaque, l’identification de l’application est appliquée.

• Si vous configurez une application spécifique dans une stratégie, vous remplacez la liaison d’application spécifiée dans un objet d’attaque. Le Tableau 2 récapitule la liaison avec la configuration de l’application dans la stratégie IDP.

  Tableau 2 : configuration de l’application dans une stratégie IDP

  Type d’application dans la stratégie	Comportement de liaison	Identification des applications
  Default	Se lie à l’application ou au service configuré dans la définition de l’objet d’attaque.	Activé pour les objets d’attaque basés sur les applications Désactivé pour les objets d’attaque basés sur des services
  Specific application	Se lie à l’application spécifiée dans la définition de l’objet d’attaque.	Handicapé
  Any	Se lie à toutes les applications.	Handicapé

• Si vous spécifiez une application dans une stratégie IDP, le type d’application configuré dans la définition de l’objet d’attaque et dans la stratégie IDP doit correspondre. La règle de stratégie ne peut pas spécifier deux applications différentes (l’une dans l’objet d’attaque et l’autre dans la stratégie).

Note:

L’application ne peut pas l’être any lorsque des attaques basées sur différentes applications sont spécifiées dans la configuration IDP et que la validation échoue. Utilisez plutôt la valeur par défaut.

Lors de la configuration des règles IDS pour l’application, l’option any est déconseillée.

Toutefois, lorsque l’application est any et que des groupes d’attaques personnalisés sont utilisés dans la configuration IDP, la validation est validée. Ainsi, la vérification de validation ne détecte pas de tels cas.

L’encapsulation de protocole d’application étant de plus en plus utilisée, il devient nécessaire de prendre en charge l’identification de plusieurs applications différentes s’exécutant sur les mêmes protocoles de couche 7. Par exemple, des applications telles que Facebook et Yahoo Messenger peuvent toutes deux s’exécuter sur HTTP, mais il est nécessaire de les identifier comme deux applications différentes s’exécutant sur le même protocole de couche 7. Pour ce faire, la couche d’identification des applications actuelle est divisée en deux couches : les applications de couche 7 et les protocoles de couche 7.

Des signatures d’application prédéfinies incluses ont été créées pour détecter les applications de couche 7, tandis que les signatures de protocole de couche 7 existantes fonctionnent toujours de la même manière. Ces signatures d’application prédéfinies peuvent être utilisées dans les objets d’attaque.

Cet exemple montre comment configurer les stratégies IDP pour l’identification des applications.

Bien que vous ne puissiez pas créer de signatures d’application avec la base de données de signatures IDP, vous pouvez configurer les paramètres du capteur pour limiter le nombre de sessions exécutant l’identification des applications, ainsi que l’utilisation de la mémoire pour l’identification des applications.

Limite de mémoire pour une session : vous pouvez configurer la quantité maximale d’octets de mémoire pouvant être utilisés pour enregistrer les paquets destinés à l’identification de l’application pour une session TCP ou UDP. Vous pouvez également configurer une limite d’utilisation globale de la mémoire pour l’identification des applications. L’identification des applications est désactivée pour une session une fois que le système a atteint la limite de mémoire spécifiée pour la session. Cependant, IDP continue de suivre les tendances. L’application correspondante est enregistrée dans le cache afin que la session suivante puisse l’utiliser. Cela protège le système contre les attaquants qui tentent de contourner l’identification des applications en envoyant délibérément de gros paquets client-serveur.

• Nombre de sessions : vous pouvez configurer le nombre maximal de sessions pouvant exécuter l’identification des applications en même temps. L’identification des applications est désactivée une fois que le système a atteint le nombre de sessions spécifié. Vous limitez le nombre de sessions afin d’éviter une attaque par déni de service (DOS), qui se produit lorsque trop de demandes de connexion submergent et épuisent toutes les ressources allouées sur le système.

Le Tableau 3 indique la capacité d’un point central (CP) numéros de session pour les équipements SRX3400, SRX3600, SRX5600 et SRX5800.

Tableau 3 : Nombre maximal de sessions CP

Équipements SRX Series	Nombre maximal de sessions	Point central (CP)
SRX3400	2,25 millions	CP en mode combo
SRX3600	2,25 millions	CP en mode combo
SRX5600	9 millions 2,25 millions	CP complet CP en mode combo
SRX5800	10 millions 2,25 millions	CP complet CP en mode combo

Cet exemple montre comment configurer les limites de mémoire pour les services d’identification d’application IDP.

• But
• Action
• Signification

Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version. D’autres plates-formes peuvent être prises en charge.

Utilisez le tableau suivant pour consulter des informations supplémentaires sur la plate-forme.

Pare-feu SRX Series	Nombre maximal de sessions	Point central (CP)
SRX5600	9 millions 2,25 millions	CP complet CP en mode combo
SRX5800	10 millions 2,25 millions	CP complet CP en mode combo

Utilisez l’explorateur de fonctionnalités pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.

Utilisez le tableau suivant pour passer en revue les comportements spécifiques à votre plateforme.

Plateforme	Différence
Pare-feu SRX Series	Le pare-feu SRX320 qui prend en charge IDP AppID prend en charge un maximum de 16 384 sessions IDP. Pare-feu SRX345 qui prend en charge IDP AppID prend en charge un maximum de 32 768 sessions IDP.