SUR CETTE PAGE
Stratégies IDP
La stratégie de détection et de prévention des intrusions (IDP) de Junos OS vous permet d’appliquer de manière sélective diverses techniques de détection et de prévention des attaques sur le trafic réseau passant par un équipement compatible IDP. Il vous permet de définir des règles de stratégie qui correspondent à une section du trafic en fonction d’une zone, d’un réseau et d’une application, puis de prendre des actions préventives actives ou passives sur ce trafic.
Pour plus d’informations, consultez les sujets suivants :
Présentation des stratégies IDP
Une stratégie IDP définit la façon dont votre équipement gère le trafic réseau. Elle vous permet d’appliquer diverses techniques de détection et de prévention des attaques sur le trafic qui traverse votre réseau.
Une stratégie est composée de rule bases, et chaque base de règles contient un ensemble de rules. Vous définissez des paramètres de règle, tels que les conditions de correspondance du trafic, les actions et les exigences de journalisation, puis ajoutez les règles aux bases de règles. Après avoir créé une stratégie IDP en ajoutant des règles dans une ou plusieurs bases de règles, vous pouvez sélectionner cette stratégie comme stratégie active sur votre équipement.
Junos OS vous permet de configurer et d’appliquer plusieurs stratégies IDP. À partir des versions 15.1X49-D20 et 17.3R1 de Junos OS, la validation des configurations est effectuée pour la stratégie IDP configurée en tant que stratégie active. Vous pouvez installer la même stratégie IDP sur plusieurs équipements, ou installer une stratégie IDP unique sur chaque équipement de votre réseau. Une seule stratégie ne peut contenir qu’une seule instance de n’importe quel type de base de règles.
La fonctionnalité IDP est activée par défaut. Aucune licence n’est requise. Les attaques personnalisées et les groupes d’attaques personnalisés dans les stratégies IDP peuvent également être configurés et installés même lorsqu’une base de données de licences et de signatures valide n’est pas installée sur l’équipement.
À partir de la version 18.4R1 de Junos OS, lorsqu’une nouvelle stratégie IDP est chargée, les sessions existantes sont inspectées à l’aide de la stratégie nouvellement chargée et les sessions existantes ne sont pas ignorées pour le traitement IDP.
La liste suivante décrit les modifications apportées à l’inspection IDP pour les sessions existantes après le chargement d’une nouvelle stratégie :
Signatures basées sur les paquets : l’inspection IDP se poursuit pour les attaques basées sur les paquets avec la nouvelle politique IDP.
Signatures basées sur les flux : l’inspection IDP se poursuit pour les attaques basées sur les flux de la nouvelle stratégie IDP avec un nombre de décalage final inférieur au nombre d’octets passés pour ce flux.
Signatures contextuelles : l’inspection IDP se poursuit pour les attaques basées sur le contexte créées par le détecteur après le chargement d’une nouvelle stratégie IDP, à l’exception de la nouvelle stratégie chargée avec le nouveau détecteur.
Les stratégies IDP suivantes sont prises en charge :
DMZ_Services
DNS_Services
File_Server
Getting_Started
IDP_Default
Recommandé
Web_Server
Vous pouvez effectuer les tâches suivantes pour gérer les stratégies IDP :
Créez de nouvelles stratégies IDP à partir de zéro. Voir l’exemple : Définition de règles pour une base de règles IPS IDP.
Créez une stratégie IDP à partir de l’un des modèles prédéfinis fournis par Juniper Networks (voir Comprendre les modèles de stratégies IDP prédéfinis).
Ajouter ou supprimer des règles dans une base de règles. Vous pouvez utiliser l’un des objets IDP suivants pour créer des règles :
Zone
Note:Vous pouvez configurer les adresses source-adresse et source-sauf lorsque la zone est n’importe quelle, et de même pour avoir des adresses de destination et de destination-sauf lorsque-zone est n’importe quelle.
Objets réseau disponibles dans le système de base
Objets de service prédéfinis fournis par Juniper Networks
Objets d’application personnalisés
Objets d’attaque prédéfinis fournis par Juniper Networks
Créez des objets d’attaque personnalisés (voir exemple : configuration des attaques basées sur les signatures IDP ).
Mettez à jour la base de données de signatures fournie par Juniper Networks. Cette base de données contient tous les objets prédéfinis.
Maintenez plusieurs stratégies IDP. N’importe quelle politique peut être appliquée à l’équipement.
Les stratégies IDP pour chaque système logique utilisateur sont compilées ensemble et stockées dans la mémoire du plan de données. Pour estimer la mémoire du plan de données adéquate pour une configuration, tenez compte des deux facteurs suivants :
Les stratégies IDP appliquées à chaque système logique utilisateur sont considérées comme des instances uniques, car l’ID et les zones de chaque système logique utilisateur sont différentes. Les estimations doivent tenir compte des exigences de mémoire combinées pour tous les systèmes logiques utilisateur.
À mesure que la base de données des applications augmente, les stratégies compilées nécessitent plus de mémoire. L’utilisation de la mémoire doit être maintenue en dessous de la mémoire du plan de données disponible pour permettre l’augmentation de la base de données.
Voir aussi
Comprendre la prise en charge des politiques IDP pour les stratégies unifiées
Avec la prise en charge de la politique IDP dans la politique de sécurité unifiée :
La stratégie IDP est activée à l’aide de la
set security policies from-zone <zone-name> to-zone <zone-name> policy <policy-name> then permit application-services idp-policy <idp-policy-name>commande.La stratégie IDP étant disponible dans la stratégie de sécurité unifiée, toutes les correspondances IDP seront gérées dans la stratégie unifiée, à moins que la source, la destination ou l’application ne soit définie (stratégie traditionnelle).
Vous pouvez également configurer des conditions de correspondance dans IDP pour obtenir une granularité d’inspection supplémentaire.
La configuration de l’adresse source ou de destination, de la source et de la destination à l’exception, de et vers la zone ou de l’application n’est pas nécessaire avec une stratégie unifiée, car la correspondance se produit dans la stratégie de sécurité elle-même.
L’application de couche 7 peut être modifiée pendant la durée de vie d’une session et cette modification peut entraîner la désactivation du service IDP pour la session.
La correspondance initiale des stratégies de sécurité peut entraîner une ou plusieurs correspondances de stratégies. Dans le cadre de l’intérêt de session, vérifiez que l’IDP sera activé si la stratégie IDP est présente dans l’une des règles correspondantes.
Si vous avez configuré une stratégie de sécurité traditionnelle (avec une condition correspondant à 5 tuples ou une application dynamique configurée comme aucune) et une stratégie unifiée (avec une condition de correspondance à 6 tuples), la stratégie de sécurité traditionnelle correspond au trafic d’abord, avant la stratégie unifiée.
Lorsque vous configurez une stratégie unifiée avec une application dynamique comme l’une des conditions correspondantes, la configuration élimine les étapes supplémentaires liées à la configuration des stratégies IDP. Toutes les configurations des stratégies IDP sont gérées dans la stratégie de sécurité unifiée et simplifient la configuration de la stratégie IDP pour détecter toute attaque ou intrusion pour une session donnée.
Comprendre plusieurs stratégies IDP pour des stratégies unifiées
Lorsque les équipements de sécurité sont configurés avec des stratégies unifiées, vous pouvez configurer plusieurs stratégies IDP et définir l’une de ces stratégies comme stratégie IDP par défaut
Si plusieurs stratégies IDP sont configurées pour une session et en cas de conflit de stratégie, l’équipement applique la stratégie IDP par défaut pour cette session et résout ainsi tous les conflits de stratégie.
Si vous avez configuré deux stratégies IDP ou plus dans une stratégie de sécurité unifiée, vous devez configurer la stratégie IDP par défaut.
Pour configurer la stratégie IDP comme stratégie par défaut, utilisez la set security idp default-policy policy-name commande.
La phase initiale de recherche des stratégies de sécurité, qui se produit avant l’identification d’une application dynamique, peut entraîner plusieurs correspondances potentielles de stratégies. L’IDP est activé sur la session si au moins une des stratégies de sécurité correspondantes est configurée.
Si une seule stratégie IDP est configurée dans la liste de stratégies potentielles, cette stratégie IDP est appliquée à la session.
Si plusieurs stratégies IDP sont configurées pour une session dans la liste de stratégies potentielles, l’équipement applique la stratégie IDP configurée par défaut comme la stratégie IDP.
Une fois que les applications dynamiques sont identifiées pour une session, si la stratégie IDP finale est configurée différemment de la stratégie IDP par défaut, une relookup de stratégie est effectuée et la stratégie IDP configurée pour la stratégie correspondante finale est appliquée.
Si la stratégie de sécurité correspondante finale comporte la même stratégie IDP configurée lors de la recherche initiale de stratégie de sécurité, alors cette stratégie IDP est appliquée à la session.
Si la stratégie de sécurité correspondante finale n’a pas de stratégie IDP configurée, le traitement IDP est désactivé pour la session.
Avantages de plusieurs stratégies IDP et de la configuration des stratégies IDP par défaut pour les stratégies unifiées
Offre la flexibilité nécessaire pour maintenir et utiliser plusieurs stratégies IDP.
Gère les conflits de stratégies à l’aide de la configuration de stratégie IDP par défaut.
Sélection des stratégies IDP pour les stratégies unifiées
Cette rubrique fournit des détails sur la sélection des stratégies IDP pour les stratégies unifiées.
- Sélection des stratégies IDP avec une seule politique IDP
- Sélection des stratégies IDP avec plusieurs stratégies IDP
Sélection des stratégies IDP avec une seule politique IDP
Lorsqu’une stratégie de sécurité est traitée pour une session, la correspondance initiale des stratégies de sécurité peut entraîner une ou plusieurs correspondances de stratégies. Si le cache d’application est présent, la correspondance des stratégies se traduira par une seule et même correspondance.
Dans le cadre de la vérification des intérêts de session, L’IDP est activé si une stratégie IDP est présente dans l’une des règles correspondantes.
Une fois l’identification dynamique des applications effectuée, la stratégie de sécurité effectue une relook up. Les services d’application de couche 7 (IDP) sont informés de se désactiver eux-mêmes si l’IDP n’est pas configuré sur la stratégie correspondante finale. La stratégie IDP étant disponible dans la stratégie de sécurité unifiée, toutes les correspondances IDP sont gérées dans la stratégie unifiée, à moins que la source, la destination ou l’application ne soit définie explicitement (stratégie traditionnelle). La configuration de l’adresse source ou de destination, de la source et de la destination à l’exception, de et vers la zone ou de l’application n’est pas nécessaire avec une stratégie unifiée, car la correspondance se produit dans la stratégie de sécurité elle-même. Le tableau 1 fournit un exemple de sélection de stratégies IDP dans une stratégie de sécurité.
La figure 1 et la figure 2 fournissent les détails du flux de travail pour la sélection de stratégies IDP uniques et multiples pour les stratégies unifiées.
| Stratégie de sécurité | Zone source | Adresse de | destination Zone | adresse Adresse de destination Adresse | Application dynamiqueApplications services Stratégies | deservice d’application | |
|---|---|---|---|---|---|---|---|
P1 |
Dans |
10.1.1.1 |
Sortie |
Tout |
HTTP |
IDP |
Recommandé |
P2 |
Dans |
10.1.1.1 |
Sortie |
Tout |
GMAIL |
UTM |
utm_policy_1 |
flow-first
de la politique finale
Sélection des stratégies IDP avec plusieurs stratégies IDP
Si plusieurs stratégies sont présentes dans la liste de stratégies potentielles avec différentes stratégies IDP, alors l’équipement applique la stratégie IDP configurée en tant que stratégie IDP par défaut.
Une fois que les applications dynamiques sont identifiées, si la stratégie IDP finale a des stratégies IDP configurées qui sont différentes de la stratégie IDP par défaut, la recherche de la stratégie est effectuée et la stratégie IDP configurée pour la stratégie IDP finale est appliquée.
Si la stratégie de sécurité correspondante finale n’a pas de stratégie IDP configurée, le traitement IDP est désactivé pour la session.
| Zone source des stratégies | Adresse source | Zone de | destination Adresse Adresse de destination Adresse | Application dynamique | Stratégies | de service applicatif | |
|---|---|---|---|---|---|---|---|
P1 |
Dans |
10.1.1.1 |
Sortie |
Tout |
HTTP |
IDP |
Recommandé |
P2 |
Dans |
10.1.1.1 |
Sortie |
Tout |
GMAIL |
UTM |
utm_policy_1 |
P3 |
Dans |
Tout |
Sortie |
Tout |
GMAIL |
IDP |
idpengine |
Prenons l’exemple des stratégies de sécurité configurées pour une session :
If security policy P1 and policy P3 match for a session
Les politiques IDP sont en conflit. Dans ce cas, la stratégie IDP configurée en tant que stratégie IDP par défaut est appliquée.
Après la correspondance finale des stratégies de sécurité, la recherche de la stratégie IDP est effectuée en fonction des stratégies IDP correspondantes. Si la dernière stratégie de sécurité correspondante est la stratégie P1, alors la stratégie IDP nommée recommandée est appliquée pour la session.
If security policy P1 and policy P2 match for a session
Étant donné qu’il n’y a qu’une seule stratégie IDP configurée dans les stratégies de sécurité correspondantes, la stratégie IDP nommée recommandée est appliquée à la session.
Si la stratégie de sécurité correspondante est la stratégie P1, l’inspection des sessions continue d’appliquer la stratégie IDP nommée recommandée. Si la stratégie de sécurité correspondante est la stratégie P2, l’IDP est désactivé et ignore la session.
Exemple : configuration de plusieurs stratégies IDP et d’une stratégie IDP par défaut pour les stratégies de sécurité unifiées
Pour que le trafic de transit passe par l’inspection IDP, vous configurez une stratégie de sécurité et activez les services d’application IDP sur tout le trafic que vous souhaitez inspecter.
Cet exemple montre comment configurer une stratégie de sécurité pour activer les services IDP pour la première fois sur le trafic circulant sur l’équipement.
Exigences
Avant de commencer, installez ou vérifiez une licence de fonctionnalité IDP.
Cet exemple utilise les composants matériels et logiciels suivants :
Un équipement SRX Series.
Junos OS version 18.3R1 et versions ultérieures.
Cet exemple de configuration a été testé à l’aide d’un équipement SRX1500 exécutant Junos OS version 18.3R1. Toutefois, vous pouvez utiliser la même configuration sur les équipements de la gamme SRX300, SRX550M, SRX4100, SRX4200 et SRX5000 à l’aide des dernières versions de Junos OS.
Aperçu
Dans cet exemple, vous configurez deux stratégies de sécurité pour activer les services IDP sur un équipement SRX1500 afin d’inspecter tout le trafic de la zone de confiance jusqu’à la zone de non confiance.
Dans un premier temps, vous devez télécharger et installer la base de données de signatures sur le site Web de Juniper Networks. Ensuite, téléchargez et installez les modèles de stratégie IDP prédéfinis et activez la stratégie prédéfinie « Recommandé » en tant que stratégie active.
Dans la version SRX 18.2 ci-dessous, un seul nom de stratégie IDP peut être utilisé pour toutes les règles de pare-feu et la stratégie active fonctionne dans toutes les versions de Security Director.
Depuis Junos SRX 18.2, le style de stratégie traditionnel qui consiste à n’utiliser qu’un seul nom de stratégie IDP actif pour toutes les règles de set security idp active-policy pare-feu a été obsolète.
Au lieu de cela, le style de configuration utilise le même pour les stratégies traditionnelles que pour les stratégies unifiées en se référant à la stratégie IDP est gérée dans la commande stratégies de set security policies from-zone <zone-name> to-zone <zone-name> policy <policy-name> then permit application-services idp-policy idp-policy-name sécurité.
Ensuite, vous devez créer deux stratégies de sécurité de la zone d’approbation à la zone de non confiance et spécifier les actions à entreprendre sur le trafic qui correspondent aux conditions spécifiées dans les stratégies.
Configuration
Procédure
Configuration rapide cli
La configuration rapide cli n’est pas disponible pour cet exemple, car une intervention manuelle est nécessaire pendant la configuration.
Procédure étape par étape
Créez deux stratégies de sécurité pour le trafic de la zone d’approbation à la zone de non confiance.
Note:Veuillez noter les points suivants :
L’ordre des stratégies de sécurité sur l’équipement SRX Series est important, car Junos OS effectue une recherche de stratégie à partir du haut de la liste, et lorsque l’équipement trouve une correspondance pour le trafic reçu, il arrête la recherche de stratégie.
L’équipement SRX Series vous permet d’activer le traitement IDP sur une stratégie de sécurité règle par règle, au lieu d’activer l’inspection IDP sur l’ensemble de l’équipement.
Une stratégie de sécurité identifie le trafic à envoyer au moteur IDP, puis le moteur IDP applique une inspection en fonction du contenu de ce trafic. Le trafic qui correspond à une stratégie de sécurité dans laquelle IDP n’est pas activé contourne complètement le traitement IDP. Le trafic qui correspond à une stratégie de sécurité marquée pour le traitement IDP permet d’activer la stratégie IDP configurée dans cette stratégie de sécurité particulière.
Créez une stratégie de sécurité P1 avec une application dynamique comme critère de correspondance.
[edit security policies] user@host# set from-zone trust to-zone untrust policy P1 match source-address any user@host# set from-zone trust to-zone untrust policy P1 match destination-address any user@host# set from-zone trust to-zone untrust policy P1 match application junos-defaults user@host# set from-zone trust to-zone untrust policy P1 match dynamic-application junos:HTTP
Créez une stratégie de sécurité P2 avec une application dynamique comme critère de correspondance.
[edit security policies] user@host# set from-zone trust to-zone untrust policy P2 match source-address any user@host# set from-zone trust to-zone untrust policy P2 match destination-address any user@host# set from-zone trust to-zone untrust policy P2 match application junos-defaults user@host# set from-zone trust to-zone untrust policy P2 match dynamic-application junos:GMAIL
Définissez les stratégies IDP que vous souhaitez configurer dans les stratégies de sécurité.
[edit] user@host# set security idp idp-policy recommended user@host# set security idp idp-policy idpengine
Configurez les stratégies IDP selon les étapes des règles de stratégie IDP et des bases de règles IDP, puis configurez l’une des stratégies IDP (recommandé) en tant que stratégie IDP par défaut.
[edit]user@host# set security idp default-policy recommendedConfirmez la stratégie par défaut configurée sur votre équipement.
[edit]user@host# show security idp default-policydefault-policy recommended;
Spécifiez l’action à effectuer sur le trafic qui correspond aux conditions spécifiées dans la stratégie de sécurité. L’action de la stratégie de sécurité doit être d’autoriser le flux.
[edit security policies] user@host# set from-zone trust to-zone untrust policy P1 then permit application-services idp-policy recommended user@host# set from-zone trust to-zone untrust policy P2 then permit application-services idp-policy idpengine
Dans les versions SRX 18.3 et ultérieures, les stratégies de sécurité peuvent utiliser une stratégie IDP différente, ce qui permet de traiter des règles IDP uniques pour chaque stratégie de sécurité. Lorsque plusieurs règles IDP sont utilisées sur des stratégies de sécurité, une stratégie IDP par défaut doit être configurée.
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show security policies commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@host# show security policies
from-zone trust to-zone untrust {
policy P1 {
match {
source-address any;
destination-address any;
application junos-http;
}
then {
permit {
application-services {
idp-policy recommended;
}
}
}
}
}
from-zone trust to-zone untrust {
policy P2 {
match {
source-address any;
destination-address any;
application junos : GMAIL;
}
then {
permit {
application-services {
idp-policy idpengine;
}
}
}
}
}
Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.
Vérification
Vérification de la configuration IDP
But
Vérifiez que la configuration IDP fonctionne correctement.
Action
Depuis le mode opérationnel, saisissez la show security idp status commande.
user@host> show security idp status detail
PIC : FPC 0 PIC 0:
State of IDP: Default, Up since: 2013-01-22 02:51:15 GMT-8 (2w0d 20:30 ago)
Packets/second: 0 Peak: 0 @ 2013-02-05 23:06:20 GMT-8
KBits/second : 0 Peak: 0 @ 2013-02-05 23:06:20 GMT-8
Latency (microseconds): [min: 0] [max: 0] [avg: 0]
Packet Statistics:
[ICMP: 0] [TCP: 0] [UDP: 0] [Other: 0]
Flow Statistics:
ICMP: [Current: 0] [Max: 0 @ 2013-02-05 23:06:20 GMT-8]
TCP: [Current: 0] [Max: 0 @ 2013-02-05 23:06:20 GMT-8]
UDP: [Current: 0] [Max: 0 @ 2013-02-05 23:06:20 GMT-8]
Other: [Current: 0] [Max: 0 @ 2013-02-05 23:06:20 GMT-8]
Session Statistics:
[ICMP: 0] [TCP: 0] [UDP: 0] [Other: 0]
ID Name Sessions Memory Detector
0 Recommended 0 2233 12.6.160121210
Sens
L’exemple de sortie montre la stratégie IDP prédéfinie recommandée en tant que stratégie active.
Exemple : activation d’IDP dans une stratégie de sécurité traditionnelle
Depuis Junos SRX 18.2, le style de stratégie traditionnel qui consiste à n’utiliser qu’un seul nom de stratégie IDP actif pour toutes les règles de set security idp active-policy pare-feu a été obsolète.
Au lieu de cela, le style de configuration utilise le même pour les stratégies traditionnelles que pour les stratégies unifiées en se référant à la stratégie IDP est gérée dans la commande stratégies de set security policies from-zone <zone-name> to-zone <zone-name> policy <policy-name> then permit application-services idp-policy idp-policy-name sécurité.
Cet exemple montre comment configurer deux stratégies de sécurité pour activer les services IDP sur tout le trafic HTTP et HTTPS circulant dans les deux sens sur un équipement de sécurité. Ce type de configuration peut être utilisé pour surveiller le trafic vers et depuis une zone sécurisée d’un réseau interne comme mesure de sécurité supplémentaire pour les communications confidentielles.
Dans cet exemple, Zone2 il s’agit d’une partie du réseau interne.
Exigences
Avant de commencer :
Configurez les interfaces réseau.
Créez des zones de sécurité. Voir l’exemple : création de zones de sécurité.
Configurez les applications. Voir l’exemple : configuration des applications et des services IDP.
Configuration des stratégies IDP. Consultez les règles de stratégie IDP et les bases de règles IDP.
Aperçu
Pour que le trafic de transit passe par l’inspection IDP, vous configurez une stratégie de sécurité et activez les services d’application IDP sur tout le trafic que vous souhaitez inspecter. Les stratégies de sécurité contiennent des règles définissant les types de trafic autorisés sur le réseau et la manière dont le trafic est traité à l’intérieur du réseau. L’activation d’IDP dans une stratégie de sécurité oriente le trafic qui correspond aux critères spécifiés à vérifier par rapport aux bases de règles IDP.
L’IDP est activé par défaut. Aucune licence n’est requise. Les attaques personnalisées et les groupes d’attaques personnalisés dans les stratégies IDP peuvent être configurées et installées même lorsqu’aucune base de données de licences et de signatures valide n’est installée sur l’équipement.
Pour permettre au trafic de transit de passer sans inspection IDP, spécifiez une permit action pour la règle sans activer les services d’application IDP. Le trafic correspondant aux conditions de cette règle passe par l’équipement sans inspection IDP.
Cet exemple montre comment configurer deux stratégies, idp-app-policy-1 et idp-app-policy-2, pour activer les services IDP sur tout le trafic HTTP et HTTPS circulant dans les deux sens sur l’équipement. La stratégie idp-app-policy-1 dirige tout le trafic HTTP et HTTPS circulant de la zone1 vers la zone2 configurée précédemment pour être vérifié par rapport aux bases de règles IDP. La stratégie idp-app-policy-2 dirige tout le trafic HTTP et HTTPS circulant de la zone2 vers la zone1 pour être vérifié par rapport aux bases de règles IDP.
L’action définie dans la stratégie de sécurité doit être permit. Vous ne pouvez pas activer l’IDP pour le trafic que l’équipement refuse ou refuse.
Si vous avez configuré une stratégie de sécurité traditionnelle (avec une condition correspondant à 5 tuples ou une application dynamique configurée comme aucune) et une stratégie unifiée (avec une condition de correspondance de 6 tuple), la stratégie de sécurité traditionnelle correspond au trafic d’abord, avant la stratégie unifiée.
Lorsque vous configurez une stratégie unifiée avec une application dynamique comme l’une des conditions correspondantes, la configuration élimine les étapes supplémentaires de configuration, d’adresse source et de destination, de destination source à l’exception, de et vers les zones ou de l’application. Toutes les configurations des stratégies IDP sont gérées dans la stratégie de sécurité unifiée et simplifient la configuration de la stratégie IDP pour détecter toute attaque ou intrusion pour une session donnée. La configuration de l’adresse source ou de destination, de la source et de la destination à l’exception, de et vers la zone ou de l’application n’est pas nécessaire avec une stratégie unifiée, car la correspondance se produit dans la stratégie de sécurité elle-même.
Configuration
Procédure
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à la configuration de votre réseau, copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie, puis entrez commit à partir du mode de configuration.
set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 match source-address any set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 match destination-address any set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 match application junos-http set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 match application junos-https set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 then permit application-services idp set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 match source-address any set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 match destination-address any set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 match application junos-http set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 match application junos-https set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 then permit application-services idp
Procédure étape par étape
Dans l’exemple suivant, vous devez parcourir différents niveaux de la hiérarchie de configuration. Pour obtenir des instructions sur la façon d’y parvenir, reportez-vous à la section Utilisation de l’éditeur CLI en mode de configuration dans le guide de l’utilisateur CLI.
Pour activer les services IDP sur tout le trafic HTTP et HTTPS circulant dans les deux sens sur l’équipement :
Créez une stratégie de sécurité pour le trafic circulant de la zone1 vers la zone2 identifié comme étant le trafic applicatif junos-http ou junos-https.
user@host# set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 match source-address any user@host# set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 match destination-address any user@host# set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 match application junos-http user@host# set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 match application junos-https
Spécifiez l’action à effectuer sur le trafic de la zone1 vers la zone 2 qui correspond aux conditions spécifiées dans la stratégie.
user@host# set security policies from-zone Zone1 to-zone Zone2 policy idp-app-policy-1 then permit application-services idp
Créez une autre stratégie de sécurité pour le trafic circulant dans la direction opposée identifié comme étant le trafic applicatif junos-http ou junos-https.
user@host# set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 match source-address any user@host# set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 match destination-address any user@host# set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 match application junos-http user@host# set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 match application junos-https
Spécifiez l’action à effectuer sur le trafic qui correspond aux conditions spécifiées dans cette stratégie.
user@host# set security policies from-zone Zone2 to-zone Zone1 policy idp-app-policy-2 then permit application-services idp
Configurez la stratégie active.
user@host# set security idp active-policy recommended
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show security policies commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de configuration de cet exemple pour la corriger.
[edit]
user@host# show security policies
from-zone Zone1 to-zone Zone2 {
policy idp-app-policy-1 {
match {
source-address any;
destination-address any;
application [junos-http junos-https];
}
then {
permit {
application-services {
idp;
}
}
}
}
}
from-zone Zone2 to-zone Zone1 {
policy idp-app-policy-2 {
match {
source-address any;
destination-address any;
application [junos-http junos-https];
}
then {
permit {
application-services {
idp;
}
}
}
}
}
Si vous avez fini de configurer l’équipement, saisissez commit à partir du mode de configuration.
Vérification de la compilation des stratégies IDP et de l’état de charge
But
Affichez les fichiers journaux IDP pour vérifier l’état de la charge et de la compilation des stratégies IDP. Lorsque vous activez une stratégie IDP, vous pouvez consulter les journaux IDP et vérifier si la stratégie est chargée et compilée correctement.
Action
Pour suivre la charge et la progression de la compilation d’une stratégie IDP, configurez l’un ou les deux éléments suivants dans l’interface cli :
Vous pouvez configurer un fichier journal, qui sera situé dans
/var/log/, et définir des indicateurs d’option de trace pour enregistrer ces opérations :user@host# set security idp traceoptions file idpd user@host# set security idp traceoptions flag all
Vous pouvez configurer votre équipement pour qu’il enregistre les messages de journal du système dans un fichier du
/var/logrépertoire :user@host# set system syslog file messages any any
Une fois la configuration engagée dans l’interface cli, saisissez l’une des commandes suivantes à partir de l’invite de shell dans le shell de niveau UNIX :
Exemple de sortie
nom-commande
user@host> start shell user@host% tail -f /var/log/idpd Aug 3 15:46:42 chiron clear-log[2655]: logfile cleared Aug 3 15:47:12 idpd_config_read: called: check: 0 Aug 3 15:47:12 idpd commit in progres ... Aug 3 15:47:13 Entering enable processing. Aug 3 15:47:13 Enable value (default) Aug 3 15:47:13 IDP processing default. Aug 3 15:47:13 idp config knob set to (2) Aug 3 15:47:13 Warning: active policy configured but no application package installed, attack may not be detected! Aug 3 15:47:13 idpd_need_policy_compile:480 Active policy path /var/db/idpd/sets/idpengine.set Aug 3 15:47:13 Active Policy (idpengine) rule base configuration is changed so need to recompile active policy Aug 3 15:47:13 Compiling policy idpengine.... Aug 3 15:47:13 Apply policy configuration, policy ops bitmask = 41 Aug 3 15:47:13 Starting policy(idpengine) compile with compress dfa... Aug 3 15:47:35 policy compilation memory estimate: 82040 Aug 3 15:47:35 ...Passed Aug 3 15:47:35 Starting policy package... Aug 3 15:47:36 ...Policy Packaging Passed Aug 3 15:47:36 [get_secupdate_cb_status] state = 0x1 Aug 3 15:47:36 idpd_policy_apply_config idpd_policy_set_config() Aug 3 15:47:36 Reading sensor config... Aug 3 15:47:36 sensor/idp node does not exist, apply defaults Aug 3 15:47:36 sensor conf saved Aug 3 15:47:36 idpd_dev_add_ipc_connection called... Aug 3 15:47:36 idpd_dev_add_ipc_connection: done. Aug 3 15:47:36 idpd_policy_apply_config: IDP state (2) being set Aug 3 15:47:36 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:36 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:36 Apply policy configuration, policy ops bitmask = 4 Aug 3 15:47:36 Starting policy load... Aug 3 15:47:36 Loading policy(/var/db/idpd/bins/idpengine.bin.gz.v + /var/db/idpd/sec-repository/installed-detector/libidp-detector.so.tgz.v + /var/db/idpd/bins/compressed_ai.bin)... Aug 3 15:47:36 idpd_dev_add_ipc_connection called... Aug 3 15:47:36 idpd_dev_add_ipc_connection: done. Aug 3 15:47:37 idpd_policy_load: creating temp tar directory '/var/db/idpd//bins/52b58e5' Aug 3 15:47:37 sc_policy_unpack_tgz: running addver cmd '/usr/bin/addver -r /var/db/idpd/sec-repository/installed-detector/libidp-detector.so.tgz.v /var/db/idpd//bins/52b58e5/__temp.tgz > /var/log/idpd.addver' Aug 3 15:47:38 sc_policy_unpack_tgz: running tar cmd '/usr/bin/tar -C /var/db/idpd//bins/52b58e5 -xzf /var/db/idpd//bins/52b58e5/__temp.tgz' Aug 3 15:47:40 idpd_policy_load: running cp cmd 'cp /var/db/idpd//bins/52b58e5/detector4.so /var/db/idpd//bins/detector.so' Aug 3 15:47:43 idpd_policy_load: running chmod cmd 'chmod 755 /var/db/idpd//bins/detector.so' Aug 3 15:47:44 idpd_policy_load: running rm cmd 'rm -fr /var/db/idpd//bins/52b58e5' Aug 3 15:47:45 idpd_policy_load: detector version: 10.3.160100209 Aug 3 15:47:45 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:45 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:45 idp_policy_loader_command: sc_klibs_subs_policy_pre_compile() returned 0 (EOK) Aug 3 15:47:45 idpd_policy_load: IDP_LOADER_POLICY_PRE_COMPILE returned EAGAIN, retrying... after (5) secs Aug 3 15:47:50 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:50 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:50 idp_policy_loader_command: sc_klibs_subs_policy_pre_compile() returned 0 (EOK) Aug 3 15:47:50 idpd_policy_load: idp policy parser pre compile succeeded, after (1) retries Aug 3 15:47:50 idpd_policy_load: policy parser compile subs s0 name /var/db/idpd/bins/idpengine.bin.gz.v.1 buf 0x0 size 0zones 0xee34c7 z_size 136 detector /var/db/idpd//bins/detector.so ai_buf 0x0 ai_size 0 ai /var/db/idpd/bins/compressed_ai.bin Aug 3 15:47:50 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:50 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:50 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:50 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:50 idpd_policy_load: idp policy parser compile succeeded Aug 3 15:47:50 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:50 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:50 idpd_policy_load: idp policy pre-install succeeded Aug 3 15:47:50 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:50 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:50 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:50 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:50 idpd_policy_load: idp policy install succeeded Aug 3 15:47:50 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:50 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:50 idpd_policy_load: idp policy post-install succeeded Aug 3 15:47:51 IDP policy[/var/db/idpd/bins/idpengine.bin.gz.v] and detector[/var/db/idpd/sec-repository/installed-detector/libidp-detector.so.tgz.v] loaded successfully. Aug 3 15:47:51 Applying sensor configuration Aug 3 15:47:51 idpd_dev_add_ipc_connection called... Aug 3 15:47:51 idpd_dev_add_ipc_connection: done. Aug 3 15:47:51 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:51 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:51 idpd_comm_server_get_event:545: evGetNext got event. Aug 3 15:47:51 idpd_comm_server_get_event:553: evDispatch OK Aug 3 15:47:51 ...idpd commit end Aug 3 15:47:51 Returning from commit mode, status = 0. Aug 3 15:47:51 [get_secupdate_cb_status] state = 0x1 Aug 3 15:47:51 Got signal SIGCHLD....
Exemple de sortie
nom-commande
user@host> start shell user@host% tail -f /var/log/messages Aug 3 15:46:56 chiron mgd[2444]: UI_COMMIT_PROGRESS: Commit operation in progress: no commit script changes Aug 3 15:46:56 chiron mgd[2444]: UI_COMMIT_PROGRESS: Commit operation in progress: no transient commit script changes Aug 3 15:46:56 chiron mgd[2444]: UI_COMMIT_PROGRESS: Commit operation in progress: finished loading commit script changes Aug 3 15:46:56 chiron mgd[2444]: UI_COMMIT_PROGRESS: Commit operation in progress: exporting juniper.conf ..... Aug 3 15:47:51 chiron idpd[2678]: IDP_POLICY_LOAD_SUCCEEDED: IDP policy[/var/db/idpd/bins/idpengine.bin.gz.v] and detector[/var/db/idpd/sec-repository/installed-detector/libidp-detector.so.tgz.v] loaded successfully(Regular load). Aug 3 15:47:51 chiron idpd[2678]: IDP_COMMIT_COMPLETED: IDP policy commit is complete. ...... Aug 3 15:47:51 chiron chiron sc_set_flow_max_sessions: max sessions set 16384
Sens
Affiche des messages de journal indiquant les procédures qui s’exécutent en arrière-plan après avoir passé la set security idp active-policy commande. Cet exemple de sortie montre que la compilation des stratégies, la configuration des capteurs et la charge des stratégies sont réussies.