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) qui s’exécutent 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 s’exécutant sur des ports non standard. Il améliore également les performances en réduisant la portée des signatures d’attaque pour les applications sans 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’applications permettent au capteur d’identifier les applications connues et inconnues qui s’exécutent sur des ports non standard et d’appliquer les objets d’attaque appropriés.

Les signatures d’applications sont disponibles dans le cadre du package de sécurité fourni par Juniper Networks. Vous téléchargez les signatures d’application prédéfinies avec 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é, consultez Mettre à jour manuellement la base de données de signatures IDP.

AppID n’est activé par défaut que si le service demandeur, tel que IDP, AppFW, AppTrack ou AppQoS, est configuré pour l’appeler. AppID ne se déclenche pas automatiquement s’il n’existe aucune stratégie ou configuration. 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 d’applications dans les règles de stratégie, consultez Exemple : configuration d’applications et de services IDP.

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

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

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

• Pas d’inspection des sessions qui basculent ou restaurent.

• 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 accessibles uniquement via 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 ignorée pour l’inspection par l’IDP.

L’IDP dans les clusters de châssis actif/actif a une limitation. Pour le trafic source d’étendue lié au temps, les attaques provenant d’une source avec plusieurs destinations peuvent ne pas être détectées. Les sessions actives distribuées entre les nœuds causent ce problème car le comptage de liaison temporelle a une vue de nœud local uniquement. La détection de ce type d’attaque nécessite une synchronisation RTO de l’état de liaison temporelle qui n’est pas prise en charge actuellement.

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 non de la liaison d’application ou 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 d’IDP :

• Si vous spécifiez une application dans une définition d’objet d’attaque, le champ 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’applications et de services avec identification des applications.

  Tableau 1 : Applications et services avec identification des applications

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

  Par exemple, dans la définition d’objet d’attaque suivante, l’objet d’attaque se lie au 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 application et 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 écrasez la liaison d’application spécifiée dans un objet d’attaque. Le Tableau 2 résume la liaison avec la configuration de l’application dans la stratégie d’IDP.

  Tableau 2 : configuration des applications dans une stratégie d’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 des applications Désactivé pour les objets d’attaque basés sur les services
  Specific application	Se lie à l’application spécifiée dans la définition de l’objet d’attaque.	Désactivé
  Any	Se lie à toutes les applications.	Désactivé

• Si vous spécifiez une application dans une stratégie d’IDP, le type d’application configuré dans la définition de l’objet d’attaque et dans la stratégie d’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).

L’application ne peut pas ê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.

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

L’encapsulation des protocoles applicatifs é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 fonctionner via HTTP, mais il est nécessaire de les identifier comme deux applications différentes fonctionnant 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 des 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 AppID et limiter l’utilisation de la mémoire pour AppID.

Limite de mémoire pour une session : vous pouvez configurer la quantité maximale d’octets de mémoire qui peut être utilisée pour enregistrer des paquets pour AppID pour une session TCP ou UDP. Vous pouvez également configurer une limite d’utilisation globale de la mémoire pour l’identification des applications. AppID est désactivé pour une session lorsque le système a atteint la limite de mémoire spécifiée pour la session. Cependant, l’IDP continue de correspondre aux schémas. 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 AppID en envoyant délibérément de gros paquets client-serveur.

• Nombre de sessions : vous pouvez configurer le nombre maximal de sessions qui peuvent exécuter AppID en même temps. AppID est désactivé lorsque le système atteint le nombre de sessions spécifié. Vous limitez le nombre de sessions afin de pouvoir empêcher une attaque par déni de service (DOS), qui se produit lorsqu’un trop grand nombre de demandes de connexion submergent et épuisent toutes les ressources allouées sur le système.

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

Voir la section Informations supplémentaires sur la plate-forme pour plus d’informations sur la capacité des numéros de session de point central (CP).

Cet exemple montre comment configurer les limites de mémoire pour les services IDP AppID.

• Objet
• Mesures à prendre
• Signification

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

Utilisez le tableau suivant pour consulter les informations supplémentaires sur la plateforme.

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

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