SUR CETTE PAGE
Comprendre notre approche pour traiter les vulnérabilités connues et inconnues
Présentation des objets et groupes d’objets d’attaque IDP prédéfinis
Liste des conditions de test IDP pour un protocole spécifique
Exemple : Signature composée pour détecter l’exploitation d’une vulnérabilité HTTP
Exemple : Utilisation de paramètres de liaison temporelle pour détecter une attaque par force brute
Référence : Numéros de protocole d’objet d’attaque personnalisés
Exemple : Configuration d’attaques basées sur des signatures IDP
Comprendre les attaques basées sur les anomalies du protocole IDP
Exemple : configuration d’attaques basées sur des anomalies de protocole IDP
Attaques d’objets et de groupes d’objets pour les stratégies IDP
Cette rubrique explique les détails sur les objets et les groupes d’attaques IDP. Il explique comment créer, modifier et utiliser des objets et des groupes d’attaques pour protéger les réseaux contre diverses menaces et vulnérabilités. Cela garantit que des mesures de sécurité robustes sont en place.
Les objets d’attaque, les objets de signatures d’application et les objets de service sont utilisés pour définir les règles de stratégie IDP. En réponse aux nouvelles vulnérabilités, Juniper Networks fournit périodiquement un fichier contenant les mises à jour de la base de données d’attaques sur le site Web de Juniper. Vous pouvez télécharger ce fichier pour protéger votre réseau contre les nouvelles menaces. Ces objets et groupes d’attaques sont conçus pour détecter les schémas d’attaque connus et les anomalies de protocole au sein du trafic réseau. Vous pouvez configurer des objets et des groupes d’attaques en tant que conditions de correspondance dans les règles de stratégie IDP.
Pour plus d’informations, consultez les rubriques suivantes :
Comprendre notre approche pour traiter les vulnérabilités connues et inconnues
Cette rubrique comprend les sections suivantes :
Vulnérabilités connues
Les vulnérabilités connues sont celles documentées au sein de la communauté de la sécurité Internet. La communauté de la sécurité Internet comprend plusieurs organisations de sécurité, des analystes de sécurité et des forums de sécurité. La communauté de sécurité découvre et analyse en permanence de nouvelles attaques et échange ces informations sur Internet. De cette façon, ils peuvent localiser, identifier et vraiment comprendre une attaque.
Certains avis de sécurité contiennent le code d’attaque en question. Vous pouvez utiliser les informations et le code de l’attaque pour capturer des informations sur les paquets et les contextes de service. Vous pouvez utiliser ces informations pour créer un objet d’attaque par signature personnalisé.
Malheureusement, la plupart des avis n’affichent pas le code de l’attaque avec la description de l’attaque. Si vous ne parvenez pas à obtenir le code d’attaque, lisez attentivement l’avis et essayez de reconstituer les bases du paquet d’attaque.
N’oubliez pas d’isoler le code acquis à partir de sources inconnues.
Les organisations suivantes sont actives dans la communauté de la sécurité et constituent une bonne ressource pour trouver des informations sur les attaques :
NVD : base de données nationale sur les vulnérabilités (http://nvd.nist.gov). Référentiel de données de gestion des vulnérabilités du gouvernement des États-Unis représenté à l’aide du protocole SCAP (Security Content Automation Protocol).
SANS : administrateur système, audit, réseau, institut de sécurité (www.sans.org). Un organisme de recherche, de certification et d’éducation en matière de sécurité de l’information qui fournit des alertes de sécurité. Héberge également l’Internet Storm Center (ISC) à http://www.incidents.org.
CVE : vulnérabilités et expositions courantes (http://cve.mitre.org). Une liste standardisée des vulnérabilités et autres risques liés à la sécurité de l’information.
BugTraq (http://securityfocus.com/archive/1). Une liste de diffusion modérée hébergée par Security Focus qui discute et annonce les vulnérabilités de sécurité informatique.
Centre de coordination CERT (http://www.cert.org). Organisme d’alerte de sécurité financé par le gouvernement fédéral qui fournit des avis de sécurité.
Sécurité tempête de paquets (http://packetstormsecurity.nl). Organisation à but non lucratif de professionnels de la sécurité qui fournit des informations de sécurité par le biais d’actualités, de conseils, de forums et de codes d’attaque.
Metasploit (http://www.metasploit.com). Metasploit fournit des informations utiles pour effectuer des tests d’intrusion, développer des signatures IDS et rechercher des exploits.
FrSIRT — Equipe de Réponse aux Incidents de Sécurité (http://www.frsirt.com). FrSIRT est un organisme indépendant de recherche en sécurité qui fournit des conseils de sécurité et des services d’alerte et de notification des vulnérabilités en temps réel.
ISS : systèmes de sécurité Internet (http://www.iss.net). Une société de sécurité Internet qui fournit des alertes et des niveaux de menace Internet.
Vulnérabilités inconnues
Les vulnérabilités inconnues sont celles qui n’ont pas été documentées dans les avis de la communauté sur la sécurité Internet. Dans ce cas, les journaux d’événements de sécurité IDP Series Profiler, pare-feu ou IDP générés dans votre environnement de production vous alertent en cas d’activité suspecte et de trafic anormal. Dans votre environnement de production, vous utiliserez des outils de journalisation des paquets pour capturer les paquets et les informations de contexte de service que vous pourrez ensuite analyser et tester dans votre laboratoire.
Test d’un objet d’attaque personnalisé
Nous vous recommandons d’utiliser le workflow suivant pour tester un objet d’attaque personnalisé. Notez que la procédure suivante comporte des étapes générales et est destinée aux utilisateurs experts familiarisés avec ces tâches.
Pour tester un objet d’attaque personnalisé :
- Créez une stratégie de sécurité et une nouvelle règle de base de règles IDP qui inclut uniquement l’objet d’attaque personnalisé à tester. Activez la journalisation et la journalisation des paquets.
- Envoyez la stratégie à l’équipement de laboratoire IDP Series.
- À partir de l’ordinateur de l’attaquant, reproduisez l’attaque qui cible l’ordinateur de la victime.
- Utilisez la visionneuse de journaux de Security Director pour voir si le trafic généré génère des journaux comme prévu.
Si votre test échoue, consultez l’avis d’attaque, la RFC de protocole et le code d’attaque ou les captures de paquets pour identifier des informations supplémentaires qui peuvent vous aider à affiner vos paramètres. Le problème le plus fréquent qui nécessite un réglage est la syntaxe de l’expression DFA.
Création d’un objet d’attaque signature
Un objet d’attaque de signature est un modèle que vous souhaitez que le système détecte. Vous utilisez une expression DFA pour représenter le modèle. Toutes les autres propriétés de signature que vous pouvez définir (telles que le contexte du service ou du protocole, la direction et d’autres contraintes) sont fournies afin que vous puissiez optimiser les performances du système lors de la détection du modèle et éliminer les faux positifs. En général, vous souhaitez régler les paramètres d’un objet d’attaque de signature afin que le système le recherche dans tous les contextes où il peut se produire et dans aucun autre contexte.
Pour configurer un objet d’attaque de signature :
Présentation des objets et groupes d’objets d’attaque IDP prédéfinis
Le package de sécurité pour la détection et la prévention des intrusions (IDP) contient une base de données d’objets d’attaque IDP prédéfinis et de groupes d’objets d’attaque IDP que vous pouvez utiliser dans les stratégies IDP pour faire correspondre le trafic contre des attaques connues et inconnues. Juniper Networks met régulièrement à jour les objets et groupes d’attaques prédéfinis en fonction des modèles d’attaque nouvellement découverts.
Les mises à jour de la base de données des objets d’attaque peuvent inclure :
Nouvelles descriptions ou sévérités pour les objets d’attaque existants
Nouveaux objets d’attaque
Suppression des objets d’attaque obsolètes
Cette rubrique comprend les sections suivantes :
Objets d’attaque prédéfinis
Les objets d’attaque prédéfinis sont répertoriés par ordre alphabétique. Ces objets d’attaque ont des noms uniques qui vous aident à identifier l’attaque. La première partie du nom indique le groupe auquel appartient l’objet d’attaque. Par exemple:
FTP:USER:ROOT: appartient auFTP:USERgroupe. Il détecte les tentatives de connexion à un serveur FTP à l’aide durootcompte.HTTP:HOTMAIL:FILE-UPLOAD: appartient auHTTP:HOTMAILgroupe. Il détecte les fichiers joints aux e-mails envoyés via le serviceHotmailde messagerie Web .
Groupes d’objets d’attaque prédéfinis
La liste des groupes d’attaque prédéfinis affiche les objets d’attaque dans les catégories décrites ci-dessous. Une liste de recommandations d’objets d’attaque que Juniper Networks considère comme des menaces sérieuses est également disponible. Les objets d’attaque recommandés sont classés dans les catégories suivantes :
Groupe d’objets d’attaque |
Description |
|---|---|
Type d’attaque |
Regroupe les objets d’attaque par type (anomalie ou signature). À l’intérieur de chaque type, les objets d’attaque sont regroupés par gravité. |
Catégorie |
Regroupe les objets d’attaque en fonction de catégories prédéfinies. Au sein de chaque catégorie, les objets d’attaque sont regroupés par gravité. |
Système d’exploitation |
Regroupe les objets d’attaque en fonction du système d’exploitation auquel ils s’appliquent : BSD, Linux, Solaris ou Windows. Au sein de chaque système d’exploitation, les objets d’attaque sont regroupés par services et par gravité. |
Sévérité |
Regroupe les objets d’attaque en fonction de la gravité attribuée à l’attaque. IDP dispose de cinq niveaux de gravité : Critique, Majeur, Mineur, Avertissement, Info. À l’intérieur de chaque gravité, les objets d’attaque sont regroupés par catégorie. |
Web Services |
Regroupe les objets attaqués par des services Web courants. Ces services sont regroupés par niveaux de gravité : Avertissement, Critique, Majeur, Mineur, Info. |
Divers |
Regroupe les objets d’attaque par niveau de performance. Les objets d’attaque affectant les performances IDP à un certain niveau sont regroupés dans cette catégorie. |
Réponse |
Regroupe les objets d’attaque dans le trafic circulant dans la direction du serveur vers le client. |
Comprendre les objets d’attaque personnalisés
Vous pouvez créer des objets d’attaque personnalisés pour détecter de nouvelles attaques ou personnaliser des objets d’attaque prédéfinis pour répondre aux besoins uniques de votre réseau.
Pour configurer un objet d’attaque personnalisé, spécifiez un nom unique pour celui-ci, puis spécifiez des informations supplémentaires, telles qu’une description générale et des mots-clés, ce qui peut vous aider à localiser et à gérer plus facilement l’objet d’attaque.
Certaines propriétés des définitions d’objet d’attaque sont communes à tous les types d’attaques, telles que le nom de l’attaque, la description, le niveau de gravité, la liaison de service ou d’application, la liaison temporelle, l’action recommandée et la liaison de protocole ou de port. Certains champs sont spécifiques à un type d’attaque et ne sont disponibles que pour cette définition d’attaque spécifique.
La fonctionnalité IDP est activée par défaut, aucune licence n’est requise. Il est également possible de configurer et d’installer des attaques personnalisées et des groupes d’attaques personnalisés dans les stratégies IDP, même si aucune licence valide ni base de données de signatures n’est installée sur l’appareil.
Cette rubrique comprend les sections suivantes :
- Nom de l’attaque
- Sévérité
- Liaisons de service et d’application
- Liaisons de protocole et de port
- Liaisons temporelles
- Propriétés de l’attaque (attaques signatures)
- Propriétés de l’attaque (attaques par anomalies de protocole)
- Propriétés d’attaque (attaques combinées ou en chaîne)
Nom de l’attaque
Spécifiez un nom alphanumérique pour l’objet. Vous pouvez inclure le protocole utilisé par l’attaque dans le nom de l’attaque.
À partir de la version 15.1X49-D140 de Junos OS, le nombre maximal de caractères autorisés pour un nom d’objet d’attaque personnalisé est de 60. Vous pouvez valider l’instruction à l’aide de la set security idp custom-attack commande.
Sévérité
Spécifie la brutalité de l’attaque sur votre réseau. Les catégories de gravité, par ordre croissant de brutalité, sont info, avertissement, mineur, majeur, critique. Les attaques critiques sont les plus dangereuses : elles visent généralement à faire planter votre serveur ou à prendre le contrôle de votre réseau. Les attaques informationnelles sont les moins dangereuses et sont généralement utilisées par les administrateurs réseau pour découvrir des failles dans leurs propres systèmes de sécurité.
Liaisons de service et d’application
Le champ de liaison de service ou d’application spécifie le service utilisé par l’attaque pour pénétrer dans votre réseau.
Spécifiez la liaison de service ou de protocole dans une attaque personnalisée. Si vous spécifiez les deux, la liaison de service est prioritaire.
any: indiquezanysi vous n’êtes pas sûr du service correct et si vous souhaitez faire correspondre la signature dans tous les services. Étant donné que certaines attaques utilisent plusieurs services pour attaquer votre réseau, vous souhaiterez peut-être sélectionner laAnyliaison de service pour détecter l’attaque, quel que soit le service choisi par l’attaque pour une connexion.service: la plupart des attaques utilisent un service spécifique pour attaquer votre réseau. Vous pouvez sélectionner le service spécifique utilisé pour perpétrer l’attaque comme liaison de service.Pour obtenir la liste des services, des liaisons de service et des contextes, reportez-vous à la section Présentation des objets d’attaque personnalisés IDP Contextes de service
Liaisons de protocole et de port
Les liaisons de protocole ou de port vous permettent de spécifier le protocole qu’une attaque utilise pour pénétrer dans votre réseau. Vous pouvez spécifier le nom du protocole réseau ou le numéro de protocole.
Spécifiez la liaison de service ou de protocole dans une attaque personnalisée. Si vous spécifiez les deux, la liaison de service est prioritaire.
IP : vous pouvez spécifier n’importe quel protocole de couche réseau pris en charge à l’aide de numéros de protocole. Le Tableau 11 répertorie les numéros de protocole des différents protocoles.
Tableau 11 : protocoles pris en charge et numéros de protocoles Nom du protocole
Numéro de protocole
IGMP
2
IP-IP
4
EGP
8
CHIOT
12
PQ
29
L’IPV6
41
ROUTAGE
43
FRAGMENT
44
RSVP
46
GRE
47
ESP
50
AH
51
L’ICMPV6
58
AUCUN
59
DSTOPTS
60
MTP
92
L’ENCAP
98
PIM
103
COMP
108
CRU
255
ICMP, TCP et UDP : les attaques qui n’utilisent pas un service spécifique peuvent utiliser des ports spécifiques pour attaquer votre réseau. Certaines attaques TCP et UDP utilisent des ports standard pour pénétrer dans votre réseau et établir une connexion.
RPC : le protocole d’appel de procédure à distance (RPC) est utilisé par les applications de traitement distribué pour gérer l’interaction entre les processus à distance. Lorsqu’un client fait un appel de procédure à distance à un serveur RPC, le serveur répond avec un programme à distance ; Chaque programme distant utilise un numéro de programme différent. Pour détecter les attaques qui utilisent RPC, configurez la liaison de service en tant que RPC et spécifiez l’ID de programme RPC.
Le Tableau 12 présente des exemples de formats pour les protocoles clés.
Nom du protocole |
Numéro de protocole |
Description |
|---|---|---|
ICMP |
|
Spécifiez le nom du protocole. |
IP |
|
Spécifiez le numéro de protocole de la couche réseau. |
Le RPC |
|
Spécifiez le numéro du programme RPC. |
TCP ou UDP |
|
La spécification du port est facultative pour les protocoles TCP et UDP. Par exemple, vous pouvez spécifier l’un des éléments suivants :
|
Liaisons temporelles
Utilisez des liaisons temporelles pour configurer les attributs d’heure de l’objet d’attaque personnalisé de liaison temporelle. Les attributs de temps contrôlent la façon dont l’objet d’attaque identifie les attaques qui se répètent un certain nombre de fois. En configurant la portée et le nombre d’attaques, vous pouvez détecter une séquence de ces mêmes attaques sur une période donnée entre les sessions.
À partir de Junos OS version 18.4R1, vous pouvez configurer l’intervalle de temps maximal entre deux instances d’une attaque personnalisée à liaison temporelle et la plage de l’intervalle de temps maximal est comprise entre 0 minute et 0 seconde et 60 minutes et 0 seconde. Dans les versions de Junos OS antérieures à la version 18.4R1, l’intervalle de temps maximal entre deux instances d’une attaque par liaison temporelle est de 60 secondes pour que le nombre de déclencheurs d’attaque atteigne le nombre configuré dans la liaison temporelle. L’instruction interval interval-value est introduite au niveau de la [edit security idp custom-attack attack-name time-binding] hiérarchie pour configurer une liaison temporelle personnalisée.
Portée
Spécifiez la portée dans laquelle le nombre d’attaques se produit :
Source : spécifiez cette option pour détecter les attaques à partir de l’adresse source le nombre spécifié de fois, quelle que soit l’adresse de destination. Cela signifie que pour une attaque donnée, une valeur seuil est conservée pour chaque attaque à partir de l’adresse source. L’adresse de destination est ignorée. Par exemple, des anomalies sont détectées à partir de deux paires différentes (
ip-a,) et (,ip-aip-c) qui ont la même adresseip-asource mais des adressesip-bde destination différentes etip-cip-b. Ensuite, le nombre de correspondances pourip-ales incréments jusqu’à2. Supposons que la valeur seuil ou count soit également définie sur 2, la signature déclenche l’événement d’attaque.Destination : spécifiez cette option pour détecter les attaques envoyées à l’adresse de destination le nombre spécifié de fois, quelle que soit l’adresse source. Cela signifie que pour une attaque donnée, une valeur seuil est conservée pour chaque attaque à partir de l’adresse de destination. L’adresse source est ignorée. Par exemple, si des anomalies sont détectées à partir de deux paires différentes (
ip-a,) et (,ip-cip-b) qui ont la même adresseip-bde destination mais des adressesip-asource différentes etip-cip-b. Ensuite, le nombre de correspondances pourip-bles incréments jusqu’à2. Supposons que la valeur seuil or count soit également définie sur2, alors la signature déclenche l’événement d’attaque.Peer : spécifiez cette option pour détecter les attaques entre les adresses IP source et de destination des sessions pendant le nombre spécifié de fois. Cela signifie que la valeur de seuil s’applique à une paire d’adresses source et de destination. Supposons que des anomalies soient détectées à partir de deux paires source/destination différentes (
ip-a, ) et (,ip-aip-c).ip-bEnsuite, le nombre de correspondances pour chaque paire est défini sur1, même si les deux paires ont une adresse source commune.
Compter
La valeur du nombre ou du seuil spécifie le nombre de fois que l’objet d’attaque doit détecter une attaque dans l’étendue spécifiée avant que l’équipement ne considère que l’objet d’attaque correspond à l’attaque. Si vous liez l’objet d’attaque à plusieurs ports et que l’objet d’attaque détecte cette attaque sur différents ports, chaque attaque sur chaque port est comptée comme une occurrence distincte. Par exemple, lorsque l’objet d’attaque détecte une attaque le puis le , le nombre est égal à TCP/80 TCP/8080deux.
Une fois la count correspondance atteinte, chaque attaque qui correspond aux critères entraîne une augmentation du nombre d’attaques d’une unité. Ce cycle de comptage dure une durée définie par l’utilisateur (configurée à l’aide de l’option interval ), après quoi le cycle se répète.
Intervalle
Intervalle spécifie l’intervalle de temps maximal entre deux instances d’une attaque personnalisée à liaison temporelle. La plage de l’intervalle de temps est comprise entre 0 seconde et 1 heure et la valeur par défaut est de 60 secondes.
Propriétés de l’attaque (attaques signatures)
Les objets d’attaque de signature utilisent une signature d’attaque dynamique (un modèle qui existe toujours dans une section spécifique de l’attaque) pour détecter les attaques connues. Ils incluent également le protocole ou le service utilisé pour perpétrer l’attaque et le contexte dans lequel l’attaque se produit. Les propriétés suivantes sont spécifiques aux attaques de signature, et vous pouvez les configurer lors de la configuration de l’attaque de signature :
Le contexte de l’attaque, le type de flux et la direction sont des champs obligatoires pour définir la signature de l’attaque.
- Contexte de l’attaque
- Direction de l’attaque
- Schéma d’attaque
- Paramètres spécifiques au protocole
- Exemple de définition d’une attaque par signature
Contexte de l’attaque
Un contexte d’attaque définit l’emplacement de la signature. Si vous connaissez le service et le contexte du service spécifique, spécifiez-le, puis spécifiez les contextes de service appropriés. Si vous connaissez le service, mais que vous n’êtes pas sûr du contexte spécifique du service, spécifiez l’un des contextes généraux suivants :
first-data-packet: spécifiez ce contexte pour détecter l’attaque uniquement dans le premier paquet de données.first-packet: spécifiez ce contexte pour détecter l’attaque uniquement dans le premier paquet d’un flux. Lorsque le sens de flux de l’objet d’attaque est défini surany, l’appareil vérifie le premier paquet des flux serveur-client et client-serveur. Si vous savez que la signature de l’attaque apparaît dans le premier paquet d’une session, le fait de choisirfirst packetplutôt que depacketréduire la quantité de trafic que l’équipement doit surveiller, ce qui améliore les performances.packet: spécifiez ce contexte pour qu’il corresponde au modèle d’attaque au sein d’un paquet. Lorsque vous sélectionnez cette option, vous devez également spécifier la liaison de service pour définir les options d’en-tête de service . Bien que cela ne soit pas obligatoire, la spécification de ces paramètres supplémentaires améliore la précision de l’objet d’attaque et donc les performances.line: spécifiez ce contexte pour détecter une correspondance de motif à l’intérieur d’une ligne spécifique de votre trafic réseau.normalized-stream: spécifiez ce contexte pour détecter l’attaque dans l’ensemble d’un flux normalisé. Le flux normalisé est l’une des multiples façons d’envoyer des informations. Dans ce flux, les informations contenues dans le paquet sont normalisées avant qu’une correspondance ne soit effectuée. Supposonswww.yahoo.com/sportsque soit identique àwww.yahoo.com/s%70orts. La forme normalisée pour représenter ces deux URL peut êtrewww.yahoo.com/sports. Choisisseznormalized streamau lieu destream, à moins que vous ne souhaitiez détecter un modèle dans sa forme exacte. Par exemple, si vous souhaitez détecter le modèlewww.yahoo.com/s%70ortsexact , sélectionnezstream.normalized-stream256: spécifiez ce contexte pour détecter l’attaque dans les 256 premiers octets d’un flux normalisé.normalized-stream1k: spécifiez ce contexte pour détecter l’attaque dans les 1024 premiers octets d’un flux normalisé.normalized-stream-8k: spécifiez ce contexte pour détecter l’attaque uniquement dans les 8 192 premiers octets d’un flux normalisé.stream: spécifie ce contexte pour réassembler les paquets et extraire les données pour rechercher une correspondance de motif. Cependant, l’appareil ne peut pas reconnaître les limites des paquets pour les contextes de flux, de sorte que les données de plusieurs paquets sont combinées. Spécifiez cette option uniquement lorsqu’aucune autre option de contexte ne contient l’attaque.stream256: spécifiez ce contexte pour réassembler les paquets et rechercher une correspondance de modèle dans les 256 premiers octets d’un flux de trafic. Lorsque le sens de flux est défini surany, l’appareil vérifie les 256 premiers octets des flux serveur-client et client-serveur. Si vous savez que la signature de l’attaque apparaîtra dans les 256 premiers octets d’une session, le fait de choisirstream256plutôt questreamde réduire la quantité de trafic que l’équipement doit surveiller et mettre en cache, améliorant ainsi les performances.stream1k: spécifiez ce contexte pour réassembler les paquets et rechercher une correspondance de modèle dans les 1024 premiers octets d’un flux de trafic. Lorsque le sens de flux est défini surany, l’appareil vérifie les 1024 premiers octets des flux de serveur à client et de client à serveur. Si vous savez que la signature de l’attaque apparaîtra dans les 1024 premiers octets d’une session,stream1024choisissez plutôt destreamréduire la quantité de trafic que l’appareil doit surveiller et mettre en cache, améliorant ainsi les performances.stream8k: spécifiez ce contexte pour réassembler les paquets et rechercher une correspondance de modèle dans les 8 192 premiers octets d’un flux de trafic. Lorsque le sens de flux est défini surany, l’appareil vérifie les 8 192 premiers octets des flux de serveur à client et de client à serveur. Si vous savez que la signature de l’attaque apparaîtra dans les 8 192 premiers octets d’une session, choisissezstream8192plutôt destreamréduire la quantité de trafic que l’appareil doit surveiller et mettre en cache, améliorant ainsi les performances.
Direction de l’attaque
Vous pouvez spécifier la direction de connexion de l’attaque. L’utilisation d’une seule direction (au lieu de ) améliore les performances, réduit le nombre de faux positifs et augmente la précision de Anyla détection.
Du client au serveur (ne détecte l’attaque que dans le trafic du client au serveur)
Du serveur au client (détecte l’attaque uniquement dans le trafic de serveur à client)
N’importe lequel (détecte l’attaque dans les deux sens)
Schéma d’attaque
Les schémas d’attaque sont des signatures des attaques que vous souhaitez détecter. Une signature est un motif qui existe toujours au sein d’une attaque ; Si l’attaque est présente, la signature l’est aussi. Pour créer le modèle d’attaque, vous devez d’abord analyser l’attaque afin de détecter un modèle (tel qu’un segment de code, une URL ou une valeur dans un en-tête de paquet), puis créer une expression syntaxique qui représente ce modèle. Vous pouvez également annuler un motif. La négation d’un modèle signifie que l’attaque est considérée comme correspondant si le modèle défini dans l’attaque correspond au not modèle spécifié.
La négation de modèle est prise en charge uniquement pour les contextes basés sur des paquets, des lignes et des applications, et non pour les contextes de flux et de flux normalisés.
Paramètres spécifiques au protocole
Spécifie certaines valeurs et options existantes dans les en-têtes de paquets. Ces paramètres sont différents selon les protocoles. Dans une définition d’attaque personnalisée, vous ne pouvez spécifier des champs que pour l’un des protocoles suivants : TCP, UDP ou ICMP. Cependant, vous pouvez définir des champs de protocole IP avec TCP ou UDP dans une définition d’attaque personnalisée.
Les paramètres d’en-tête ne peuvent être définis que pour les objets d’attaque qui utilisent un contexte de paquet ou de premier paquet. Si vous avez spécifié une ligne, un flux, un flux 256 ou un contexte de service, vous ne pouvez pas spécifier de paramètres d’en-tête.
Si vous n’êtes pas sûr des options ou des paramètres d’indicateur du paquet malveillant, laissez tous les champs vides et la détection et prévention d’intrusion (IDP) tente de faire correspondre la signature pour tout le contenu de l’en-tête.
Le Tableau 13 affiche les champs et les indicateurs que vous pouvez définir pour les attaques qui utilisent le protocole IP.
Champ |
Description |
|---|---|
Type de service |
Spécifiez une valeur pour le type de service. Les types de services courants sont les suivants :
|
Longueur totale |
Spécifiez une valeur pour le nombre d’octets dans le paquet, y compris tous les champs d’en-tête et la charge utile de données. |
ID |
Spécifiez une valeur pour la valeur unique utilisée par le système de destination pour réassembler un paquet fragmenté. |
Temps de vie |
Spécifiez une valeur entière comprise entre 0 et 255 pour la durée de vie (TTL) du paquet. Cette valeur représente le nombre d’équipements que le paquet peut traverser. Chaque routeur qui traite le paquet décrémente le TTL de |
Protocole |
Spécifiez une valeur pour le protocole utilisé. |
Source |
Saisissez l’adresse source de l’appareil attaquant. |
Destination |
Saisissez l’adresse de destination de la cible de l’attaque. |
Bit réservé |
Ce bit n’est pas utilisé. |
Plus de fragments |
Lorsqu’elle est définie ( |
Ne fragmentez pas |
Lorsqu’elle est définie ( |
Le Tableau 14 affiche les champs d’en-tête de paquet et les indicateurs que vous pouvez définir pour les attaques utilisant le protocole TCP.
Champ |
Description |
|---|---|
Source Port |
Spécifiez une valeur pour le numéro de port sur l’équipement attaquant. |
Destination Port |
Spécifiez une valeur pour le numéro de port de la cible de l’attaque. |
Numéro de séquence |
Spécifiez une valeur pour le numéro de séquence du paquet. Ce numéro identifie l’emplacement des données par rapport à l’ensemble de la séquence de données. |
Numéro ACK |
Spécifiez une valeur pour le numéro ACK du paquet. Ce numéro identifie le numéro de séquence suivant ; l’indicateur ACK doit être activé pour activer ce champ. |
Longueur de l’en-tête |
Spécifiez une valeur pour le nombre d’octets dans l’en-tête TCP. |
Longueur des données |
Spécifiez une valeur pour le nombre d’octets dans la charge utile de données. Pour les paquets SYN, ACK et FIN, ce champ doit être vide. |
Taille de la fenêtre |
Spécifiez une valeur pour le nombre d’octets dans la taille de la fenêtre TCP. |
Pointeur urgent |
Spécifiez une valeur pour le pointeur urgent. La valeur indique que les données du paquet sont urgentes ; l’indicateur URG doit être activé pour activer ce champ. |
URG |
Lorsqu’il est défini, l’indicateur urgent indique que les données du paquet sont urgentes. |
ACK |
Lorsqu’il est défini, l’indicateur d’accusé de réception accuse réception d’un paquet. |
PSH (en anglais) |
Lorsqu’il est défini, l’indicateur push indique que le récepteur doit envoyer toutes les données de la séquence actuelle à l’application de destination (identifiée par le numéro de port) sans attendre les paquets restants dans la séquence. |
Le RST |
Lorsqu’il est défini, l’indicateur de réinitialisation réinitialise la connexion TCP, en rejetant tous les paquets d’une séquence existante. |
SYN |
Lorsqu’il est défini, l’indicateur SYN indique une demande pour une nouvelle session. |
NAGEOIRE |
Lorsqu’il est défini, l’indicateur final indique que le transfert de paquets est terminé et que la connexion peut être fermée. |
R1 |
Ce bit réservé (1 sur 2) n’est pas utilisé. |
R2 |
Ce bit réservé (2 sur 2) n’est pas utilisé. |
Le Tableau 15 affiche les champs d’en-tête de paquet et les indicateurs que vous pouvez définir pour les attaques utilisant le protocole UDP.
Champ |
Description |
|---|---|
Source Port |
Spécifiez une valeur pour le numéro de port sur l’équipement attaquant. |
Destination Port |
Spécifiez une valeur pour le numéro de port de la cible de l’attaque. |
Longueur des données |
Spécifiez une valeur pour le nombre d’octets dans la charge utile de données. |
Le Tableau 16 affiche les champs d’en-tête de paquet et les indicateurs que vous pouvez définir pour les attaques utilisant le protocole ICMP.
Champ |
Description |
|---|---|
ICMP Type |
Spécifiez une valeur pour le code principal qui identifie la fonction du paquet de demande ou de réponse. |
ICMP Code |
Spécifiez une valeur pour le code secondaire qui identifie la fonction du paquet de demande ou de réponse dans un type donné. |
Numéro de séquence |
Spécifiez une valeur pour le numéro de séquence du paquet. Ce numéro identifie l’emplacement du paquet de demande ou de réponse par rapport à l’ensemble de la séquence. |
ICMP ID |
Spécifiez une valeur pour le numéro d’identification. Le numéro d’identification est une valeur unique utilisée par le système de destination pour associer les paquets de demande et de réponse. |
Longueur des données |
Spécifiez une valeur pour le nombre d’octets dans la charge utile de données. |
Exemple de définition d’une attaque par signature
Voici un exemple de définition d’attaque par signature :
<Entry> <Name>sample-sig</Name> <Severity>Major</Severity> <Attacks><Attack> <TimeBinding><Count>2</Count> <Scope>dst</Scope></TimeBinding> <Application>FTP</Application> <Type>signature</Type> <Context>packet</Context> <Negate>true</Negate> <Flow>Control</Flow> <Direction>any</Direction> <Headers><Protocol><Name>ip</Name> <Field><Name>ttl</Name> <Match>==</Match><Value>128</Value></Field> </Protocol><Name>tcp</Name> <Field><Name><Match><</Match> <value>1500</Value> </Field></Protocol></Headers> </Attack></Attacks> </Entry>
Propriétés de l’attaque (attaques par anomalies de protocole)
Un objet d’attaque par anomalie de protocole détecte les attaques inconnues ou sophistiquées qui violent les spécifications du protocole (RFC et extensions RFC courantes). Vous ne pouvez pas créer d’anomalies de protocole, mais vous pouvez configurer un nouvel objet d’attaque qui contrôle la façon dont votre appareil gère une anomalie de protocole prédéfinie lorsqu’il est détecté.
La liaison de service ou d’application est un champ obligatoire pour les attaques par anomalie de protocole.
Les propriétés suivantes sont spécifiques aux attaques par anomalie de protocole. La direction de l’attaque et la condition de test sont des champs obligatoires pour configurer les définitions d’attaque par anomalie.
- Direction de l’attaque
- Condition d’essai
- Exemple de définition d’une attaque par anomalie de protocole
Direction de l’attaque
La direction de l’attaque vous permet de spécifier la direction de connexion d’une attaque. L’utilisation d’une seule direction (au lieu de ) améliore les performances, réduit le nombre de faux positifs et augmente la précision de Anyla détection :
Du client au serveur (ne détecte l’attaque que dans le trafic du client au serveur)
Du serveur au client (détecte l’attaque uniquement dans le trafic de serveur à client)
N’importe lequel (détecte l’attaque dans les deux sens)
Condition d’essai
La condition de test est une condition à associer pour une attaque par anomalie. Juniper Networks prend en charge certaines conditions de test prédéfinies. Dans l’exemple suivant, la condition est un message trop long. Si la taille du message est supérieure à la valeur préconfigurée pour cette condition de test, l’attaque est mise en correspondance.
<Attacks> <Attack> <Type>anomaly</Type> ... <Test>MESSAGE_TOO_LONG</Test> <Value>yes</Value> ... </Attack> </Attacks>
Exemple de définition d’une attaque par anomalie de protocole
Voici un exemple de définition d’une attaque par anomalie de protocole :
<Entry> <Name>sample-anomaly</Name> <Severity>Info</Severity> <Attacks><Attack> <TimeBinding><Count>2</Count> <Scope>peer</Scope></TimeBinding> <Application>TCP</Application> <Type>anomaly</Type> <Test>OPTIONS_UNSUPPORTED</Test> <Direction>any</Direction> </Attack></Attacks> </Entry>
Propriétés d’attaque (attaques combinées ou en chaîne)
Un objet d’attaque composé ou en chaîne détecte les attaques qui utilisent plusieurs méthodes pour exploiter une vulnérabilité. Cet objet combine plusieurs signatures et/ou anomalies de protocole en un seul objet d’attaque, ce qui oblige le trafic à faire correspondre un modèle de signatures et d’anomalies combinées au sein de l’objet d’attaque composé avant que le trafic ne soit identifié comme une attaque. En combinant, voire en spécifiant l’ordre dans lequel les signatures ou les anomalies doivent correspondre, vous pouvez être très précis sur les événements qui doivent se produire avant que l’équipement n’identifie le trafic comme une attaque.
Vous devez spécifier un minimum de 2 membres (attaques) dans une attaque composée. Vous pouvez spécifier jusqu’à 32 membres dans l’attaque composée. Les membres peuvent être des attaques par signature ou par anomalie.
Les propriétés suivantes sont spécifiques aux attaques composées :
- Portée
- Commande
- Réinitialisation
- Expression (expression booléenne)
- Index des membres
- Exemple de définition d’une attaque composée
Portée
L’étendue vous permet de spécifier si l’attaque correspond au sein d’une session ou entre les transactions d’une session. Si le service spécifié prend en charge plusieurs transactions au sein d’une même session, vous pouvez également spécifier si la correspondance doit se produire sur une seule session ou peut être effectuée sur plusieurs transactions au sein d’une session :
Spécifiez session pour autoriser plusieurs correspondances pour l’objet au sein de la même session.
Spécifiez transaction de faire correspondre l’objet à plusieurs transactions qui se produisent au cours de la même session.
Commande
Utilisez la correspondance ordonnée pour créer un objet d’attaque composé qui doit correspondre à chaque signature de membre ou anomalie de protocole dans l’ordre que vous spécifiez. Si vous ne spécifiez pas de correspondance ordonnée, l’objet d’attaque composé doit toujours correspondre à tous les membres, mais le modèle d’attaque ou les anomalies de protocole peuvent apparaître dans l’attaque dans un ordre aléatoire.
Réinitialisation
Spécifie qu’un nouveau journal est généré chaque fois qu’une attaque est détectée au cours de la même session. Si ce champ est activé no , l’attaque n’est consignée qu’une seule fois pour une session.
Expression (expression booléenne)
L’utilisation du champ d’expression booléenne désactive la fonction de correspondance ordonnée. Le champ d’expression booléenne utilise les propriétés du nom du membre ou de l’index du membre. Les trois opérateurs booléens suivants sont pris en charge, ainsi que les parenthèses, ce qui permet de déterminer la priorité :
or: si l’un ou l’autre des modèles de nom de membre correspond, l’expression correspond.and: si les deux modèles de nom de membre correspondent, l’expression correspond. Peu importe l’ordre dans lequel les membres apparaissent.oand (ordered and): si les deux modèles de nom de membre correspondent et s’ils apparaissent dans le même ordre que celui spécifié dans l’expression booléenne, l’expression correspond.
Supposons que vous ayez créé cinq membres de signature, intitulés s1-s5. Supposons que vous sachiez que l’attaque contient toujours le motif s1, suivi de soit s2 ou s3. Vous savez également que l’attaque contient s4 toujours et , s5mais que leurs positions dans l’attaque peuvent varier. Dans ce cas, vous pouvez créer l’expression booléenne suivante :
((s1 oand s2) or (s1 oand s3)) and (s4 and s5)
Vous pouvez définir une correspondance ordonnée ou une expression (pas les deux) dans une définition d’attaque personnalisée.
Index des membres
L’index des membres est spécifié dans les attaques en chaîne afin d’identifier un membre (attaque) de manière unique. Dans l’exemple suivant, l’index de membre est utilisé pour identifier les membres m01 et m02 dans l’expression définie :
<Expression>m02 AND m01</Expression> <Order>no</Order> <Reset>no</Reset> <ScopeOption/> <Members> <Attack> <Member>m01</Member> <Type>Signature</Type> ... <Pattern><!CDATA[.*/getlatestversion]]></Pattern> <Regex/> </Attack> <Attack><Member>m02</Member> <Type>Signature</Type> ... <Pattern><!CDATA[\[Skype\'.*]]></Pattern> <Regex/> </Attack> <Attack>
Lors de la définition de l’expression, vous devez spécifier l’index des membres pour tous les membres.
Exemple de définition d’une attaque composée
Voici un exemple de définition d’une attaque composée :
<Entry> <Name>sample-chain</Name> <Severity>Critical</Severity> <Attacks><Attack> <Application>HTTP</Application> <Type>Chain</Type> <Order>yes</Order> <Reset>yes</Reset> <Members><Attack> <Type>Signature</Type> <Context>packet</Context> <Pattern><![CDATA[Unknown[]></Pattern> <Flow>Control</Flow> <Direction>cts</Direction> </Attack><Attack> <Type>anomaly</Type> <Test>CHUNK_LENGTH_OVERFLOW</Test> <Direction>any</Direction> </Attack></Members> </Attack></Attacks> </Entry>
Création d’un objet d’attaque composé
Utiliser des objets d’attaque composés dans les cas où :
Les attaques utilisent plusieurs méthodes pour exploiter une vulnérabilité et, examinées de manière indépendante, les contextes individuels semblent bénins.
L’appariement de plusieurs contextes réduit le nombre de faux positifs.
Le couplage d’une signature à une anomalie de protocole réduit le nombre de faux positifs.
Vous sélectionnez des objets d’attaque de signature ou des anomalies prédéfinies en tant que « membres » de l’objet composé, et vous utilisez des expressions booléennes pour spécifier la logique de correspondance.
Pour configurer un objet d’attaque composé :
Voir aussi
Modification d’objets d’attaque personnalisés en raison des changements introduits dans la mise à jour de signature
Cette rubrique décrit les modifications apportées à certains contextes de service générés par le décodeur de protocole HTTP. À partir de la mise à jour de signature #1972, le décodeur de protocole HTTP ne génère plus de contextes. Si votre stratégie de sécurité IDP inclut des signatures personnalisées qui utilisent les contextes qui ont été supprimés, vous devez modifier vos définitions d’objets d’attaque comme décrit ci-dessous pour éviter les erreurs de compilation de stratégie. Cette rubrique contient les informations suivantes :
- Référence : Contextes supprimés
- Exemple : Remplacement du contexte pour les motifs apparaissant dans du texte HTML
- Exemple : Remplacement des contextes pour les modèles apparaissant dans les URL
Référence : Contextes supprimés
Pour améliorer les performances, le décodeur de protocole HTTP ne génère plus les contextes répertoriés dans la première colonne du tableau 19. Consultez ce tableau pour obtenir des instructions sur le remplacement des contextes dans les objets d’attaque personnalisés.
Enlevé |
Remplacer par |
Directive |
|---|---|---|
http-text-html-body |
http-texte-html |
Remplacez les signatures qui utilisent le contexte http-text-html-body par http-text-html. Vous n’avez pas besoin d’apporter de modifications au motif de signature ou à d’autres propriétés. |
|
Utilisez une combinaison des contextes suivants :
|
Utilisez une signature composée avec un booléen ET pour diviser le motif de signature en plusieurs morceaux. Assurez-vous que le champ Portée est défini sur Transaction. L’utilisation du contexte http-request-method est facultative. Vous utilisez le contexte http-request-method pour lier la détection aux transactions http GET ou POST ou HEAD. Pour la méthode GET, nous utilisons le modèle \[GET\] (GET insensible à la casse). N’utilisez http-request-method que si les résultats que vous avez enregistrés précédemment et qui correspondent à la méthode de requête valent la peine d’être conservés. Si ce n’est pas le cas, omettez-le pour améliorer les performances. Si vous utilisez http-request-method, commandez-le en premier dans la chaîne composée. Utilisez le contexte http-url-parsed pour faire correspondre une signature d’attaque identifiable dans l’URL. Utilisez ce contexte pour faire correspondre un modèle dans l’URL qui apparaît avant les paramètres variables, c’est-à-dire la partie de l’URL située avant le point d’interrogation ( ?). Utilisez un ou plusieurs contextes analysés par les variables http pour faire correspondre les paramètres de la variable URL, c’est-à-dire la partie de l’URL située après le point d’interrogation ( ?), normalement séparée par des esperluettes (&). |
Exemple : Remplacement du contexte pour les motifs apparaissant dans du texte HTML
Chaque contexte généré par le moteur du détecteur HTTP a un coût en performance. Les contextes http-text-html et http-text-html-body ont le même objectif. Réduire le nombre de contextes améliore les performances.
Le tableau 20 montre les propriétés d’une signature avant la mise à jour #1972 et de la signature après. Il s’agit d’un changement simple. Vous ne changez que le contexte. Vous n’avez pas besoin de modifier le motif ou d’autres propriétés.
Avant la mise à jour |
Après la mise à jour |
|
|---|---|---|
Contexte |
http-text-html-body |
http-texte-html |
Modèle |
.*<span></span>.* |
.*<span></span>.* |
Exemple : Remplacement des contextes pour les modèles apparaissant dans les URL
Cette section est divisée en deux parties :
- Signatures qui correspondent aux méthodes de requête
- Signatures correspondant aux chaînes d’URL et aux variables d’URL
Signatures qui correspondent aux méthodes de requête
Lorsque vous modifiez des objets d’attaque personnalisés qui correspondaient précédemment aux méthodes de requête GET, POST ou HEAD, demandez-vous si les correspondances avec ces modèles de méthode de requête ont été efficaces pour vous. Gardez à l’esprit que chaque contexte généré a un coût en performance. Si la méthode de requête n’est pas essentielle à vos résultats, profitez-en pour refondre votre signature sans elle.
Le tableau 21 et le tableau 22 montrent les propriétés d’une signature avant la mise à jour #1972 et de la signature composée après. Cet exemple préserve l’intérêt d’une méthode de requête.
Signature avant mise à jour |
|
|---|---|
Portée |
– |
Contexte |
http-get-url-parsed-param |
Modèle |
\[/viper/vegaspalms/\].* |
Signature composée après mise à jour |
||
|---|---|---|
|
Réf. M01 |
Réf. M02 |
Portée |
Transaction |
|
Contexte |
méthode_de_requête_http |
http-url-parsed |
Modèle |
|
\[/viper/vegaspalms/\].* |
Signatures correspondant aux chaînes d’URL et aux variables d’URL
D’une manière générale, le fractionnement d’un modèle unique en plusieurs contextes peut avoir un impact positif ou négatif sur les performances. Vous devez tester vos modifications pour comprendre l’impact sur les performances avant de déployer les objets d’attaque dans un réseau de production. L’exemple présenté dans les Tableaux 23 et 24 brise la correspondance d’URL en plusieurs contextes. Notre équipe de sécurité a testé les performances pour les recommandations décrites ici.
Signature avant mise à jour |
|
|---|---|
Portée |
– |
Contexte |
http-get-url-param-parsed-param |
Modèle |
|
Signature composée après mise à jour |
||||
|---|---|---|---|---|
Réf. M01 |
Réf. M02 |
Réf. M03 |
Réf. M04 |
|
Portée |
Transaction |
|||
Contexte |
http-url-parsed |
http-variable-parsed |
http-variable-parsed |
http-variable-parsed |
Modèle |
|
|
|
|
Voir aussi
Exemple : Configuration d’attaques combinées ou en chaîne
Cet exemple montre comment configurer des attaques composées ou en chaîne pour des critères de correspondance spécifiques. Un objet d’attaque composé ou en chaîne peut être configuré pour détecter les attaques qui utilisent plusieurs méthodes pour exploiter une vulnérabilité.
Exigences
Avant de commencer, IDP doit être pris en charge et activé sur l’appareil.
Aperçu
Un objet d’attaque composé ou en chaîne peut combiner les signatures et les anomalies pour former un seul objet d’attaque. Un seul objet d’attaque peut contenir :
Au moins deux signatures
Au moins deux anomalies
Une combinaison de signatures et d’anomalies
Les objets d’attaque composés ou en chaîne combinent plusieurs signatures et/ou anomalies de protocole en un seul objet d’attaque, forçant le trafic à correspondre à un modèle de signatures et d’anomalies combinées au sein de l’objet d’attaque composé avant que le trafic ne soit identifié comme une attaque. Ces objets sont également utilisés pour réduire les faux positifs et augmenter la précision de la détection. Il vous permet d’être précis sur les événements qui doivent se produire avant qu’IDP identifie le trafic comme une attaque.
Configuration
Procédure
Configuration rapide de la CLI
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
set security idp idp-policy idpengine rulebase-ips rule 1 match from-zone any set security idp idp-policy idpengine rulebase-ips rule 1 match source-address any set security idp idp-policy idpengine rulebase-ips rule 1 match to-zone any set security idp idp-policy idpengine rulebase-ips rule 1 match destination-address any set security idp idp-policy idpengine rulebase-ips rule 1 match application default set security idp idp-policy idpengine rulebase-ips rule 1 match attacks custom-attacks ftpchain set security idp idp-policy idpengine rulebase-ips rule 1 then action no-action set security idp idp-policy idpengine rulebase-ips rule 1 then notification log-attacks set security idp active-policy idpengine set security idp custom-attack ftpchain severity info set security idp custom-attack ftpchain attack-type chain protocol-binding application ftp set security idp custom-attack ftpchain attack-type chain scope session set security idp custom-attack ftpchain attack-type chain order set security idp custom-attack ftpchain attack-type chain member m1 attack-type signature context ftp-banner set security idp custom-attack ftpchain attack-type chain member m1 attack-type signature pattern .*vsFTPd.* set security idp custom-attack ftpchain attack-type chain member m1 attack-type signature direction server-to-client set security idp custom-attack ftpchain attack-type chain member m2 attack-type signature context ftp-username set security idp custom-attack ftpchain attack-type chain member m2 attack-type signature pattern .*root.* set security idp custom-attack ftpchain attack-type chain member m2 attack-type signature direction client-to-server set security idp custom-attack ftpchain attack-type chain member m3 attack-type anomaly test LOGIN_FAILED set security idp custom-attack ftpchain attack-type chain member m3 attack-type anomaly direction any set security idp traceoptions file idpd set security idp traceoptions flag all
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur cette procédure, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.
Pour configurer des attaques composées ou en chaîne pour des critères de correspondance spécifiques :
Créez une stratégie IDP.
[edit] user@host# set security idp idp-policy idpengine
Associez une base de règles à la stratégie.
[edit security idp idp-policy idpengine] user@host# edit rulebase-ips
Ajoutez des règles à la base de règles.
[edit security idp idp-policy idpengine rulebase-ips] user@host# edit rule 1
Définissez les critères de correspondance de la règle.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set match from-zone any user@host# set match source-address any user@host# set match to-zone any user@host# set match destination-address any
Spécifiez un nom d’ensemble d’applications pour qu’il corresponde aux critères de la règle.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set match application default
Spécifiez l’objet d’attaque correspondant et le nom de l’objet d’attaque.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set match attacks custom-attacks ftpchain
Spécifiez une action pour la règle.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set then action no-action
Spécifiez les options de notification ou de journalisation pour la règle.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set then notification log-attacks
Activez la stratégie IDP.
[edit] user@host# set security idp active-policy idpengine
Spécifiez un nom pour l’attaque personnalisée.
[edit security idp] user@host# set custom-attack ftpchain
Définissez la gravité de l’attaque personnalisée.
[edit security idp custom-attack ftpchain] user@host# set severity info
Définissez le type d’attaque et le nom de l’application pour l’attaque personnalisée.
[edit security idp custom-attack ftpchain] user@host# set attack-type chain protocol-binding application ftp
Définissez la portée et l’ordre dans lequel l’attaque est définie.
[edit security idp custom-attack ftpchain attack-type chain] user@host# set scope session user@host# set order
Spécifiez un nom pour le premier membre de l’objet d’attaque en chaîne.
[edit security idp custom-attack ftpchain attack-type chain] user@host# set member m1
Définissez le contexte, le modèle et la direction du premier membre de l’objet d’attaque en chaîne.
[edit security idp custom-attack ftpchain attack-type chain member m1] user@host# set attack-type signature context ftp-banner user@host# set attack-type signature pattern .*vsFTPd.* user@host# set attack-type signature direction server-to-client
Spécifiez un nom pour le deuxième membre de l’objet d’attaque en chaîne.
[edit security idp custom-attack ftpchain attack-type chain] user@host# set member m2
Définissez le contexte, le modèle et la direction du deuxième membre de l’objet d’attaque en chaîne.
[edit security idp custom-attack ftpchain attack-type chain member m2] user@host# set attack-type signature context ftp-username user@host# set attack-type signature pattern .*root.* user@host# set attack-type signature direction client-to-server
Spécifiez un nom pour le troisième membre de l’objet d’attaque en chaîne.
[edit security idp custom-attack ftpchain attack-type chain] user@host# set member m3
Spécifiez un type et une direction d’attaque pour le troisième membre de l’objet d’attaque en chaîne.
[edit security idp custom-attack ftpchain attack-type chain member m3] user@host# set attack-type anomaly direction any
Spécifiez les options de suivi et les informations du fichier de suivi pour les services IDP.
[edit] user@host# set security idp traceoptions file idpd
Spécifiez les événements et autres informations qui doivent être inclus dans la sortie de trace.
[edit] user@host# set security idp traceoptions flag all
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show security idp 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 idp
idp-policy idpengine {
rulebase-ips {
rule 1 {
match {
from-zone any;
source-address any;
to-zone any;
destination-address any;
application default;
attacks {
custom-attacks ftpchain;
}
}
then {
action {
no-action;
}
notification {
log-attacks;
}
}
}
}
}
active-policy idpengine;
custom-attack ftpchain {
severity info;
attack-type {
chain {
protocol-binding {
application ftp;
}
scope session;
order;
member m1 {
attack-type {
signature {
context ftp-banner;
pattern .*vsFTPd.*;
direction server-to-client;
}
}
}
member m2 {
attack-type {
signature {
context ftp-username;
pattern .*root.*;
direction client-to-server;
}
}
}
member m3 {
attack-type {
anomaly {
test LOGIN_FAILED;
direction any;
}
}
}
}
}
}
traceoptions {
file idpd;
flag all;
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Lorsque vous passez commit en mode configuration, la configuration est vérifiée en interne, puis validée. S’il y a des erreurs, la validation échouera et les erreurs seront signalées.
Vérification
Pour vérifier que la configuration de l’attaque en chaîne fonctionne correctement, effectuez la tâche suivante :
Vérification de la configuration
But
Vérifiez que la configuration de l’attaque en chaîne est correcte.
Action
À partir du mode opérationnel, entrez la show security idp policy-commit-status commande pour vérifier l’état de la compilation ou du chargement de la stratégie.
La sortie de la show security idp policy-commit-status commande est dynamique, il n’y a donc pas de sortie unique pour cette commande.
Vérifiez que les attaques sont détectées conformément à la configuration, transmettez le trafic via l’appareil pour déclencher une correspondance d’attaque. Par exemple, entrez la show security idp status commande pour vérifier si la stratégie est chargée ou non.
user@host> show security idp status
IDP policy[/var/db/idpd/bins/test.bin.gz.v] and detector[/var/db/idpd/sec-repository/installed-detector/libidp-detector.so.tgz.v] loaded successfully. The loaded policy size is:785 Bytes
Entrez la commande pour transmettre le show security idp attack table trafic d’attaque, puis vérifiez que les attaques sont détectées ou non.
La commande n’affichera la sortie que lorsque des attaques sont détectées.
user@host> show security idp attack table
IDP attack statistics: Attack name #Hits FTP:USER:ROOT 1
Exemple : Configuration de groupes d’attaques avec des groupes d’attaques dynamiques et des groupes d’attaques personnalisés
Cet exemple montre comment configurer des groupes d’attaques avec des groupes d’attaques dynamiques et des groupes d’attaques personnalisés dans une stratégie IDP pour protéger un serveur FTP ou Telnet.
Exigences
Avant de commencer, installez le package de sécurité sur l’appareil uniquement si l’une des déclarations suivantes est vraie :
Des groupes d’attaque dynamiques sont configurés.
Les groupes d’attaques personnalisés contiennent des attaques ou des groupes d’attaques prédéfinis.
Si les groupes d’attaques personnalisés contiennent uniquement des attaques personnalisées, la licence du package de sécurité n’est pas requise et il n’est pas nécessaire d’installer le package de sécurité sur l’appareil. Pour installer le package de sécurité, vous avez besoin d’une licence de package de sécurité IDP.
Aperçu
L’IDP contient un grand nombre d’objets d’attaque prédéfinis. Pour gérer et organiser les stratégies IDP, les objets d’attaque peuvent être regroupés. Un groupe d’objets d’attaque peut contenir au moins deux types d’objets d’attaque. Les groupes d’attaque sont classés comme suit :
Groupe d’attaques dynamiques : contient les objets d’attaque en fonction de certains critères de correspondance. Lors d’une mise à jour de signature, l’appartenance dynamique à un groupe est automatiquement mise à jour en fonction des critères de correspondance de ce groupe. Par exemple, vous pouvez regrouper dynamiquement les attaques liées à une application spécifique à l’aide des filtres du groupe d’attaques dynamiques.
Custom attack group (Groupe d’attaques personnalisé) : contient la liste des attaques spécifiées dans la définition de l’attaque. Un groupe d’attaques personnalisé peut également contenir des attaques prédéfinies spécifiques, des attaques personnalisées, des groupes d’attaques prédéfinis ou des groupes d’attaques dynamiques. Un groupe d’attaques personnalisé est de nature statique, car les attaques sont spécifiées dans le groupe. Par conséquent, le groupe d’attaque ne change pas lorsque la base de données de sécurité est mise à jour. Il peut s’agir d’attaques prédéfinies ou de groupes d’attaques prédéfinis à partir de la base de données de signatures, ou d’autres attaques personnalisées et de groupes d’attaques dynamiques.
Dans cet exemple, nous configurons un groupe d’attaques dans une stratégie IDP pour protéger un serveur FTP ou Telnet contre des attaques personnalisées et dynamiques.
Configuration
Procédure
Configuration rapide de la CLI
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
set security idp idp-policy idpengine rulebase-ips rule 1 match from-zone any set security idp idp-policy idpengine rulebase-ips rule 1 match source-address any set security idp idp-policy idpengine rulebase-ips rule 1 match to-zone any set security idp idp-policy idpengine rulebase-ips rule 1 match destination-address any set security idp idp-policy idpengine rulebase-ips rule 1 match application default set security idp idp-policy idpengine rulebase-ips rule 1 match attacks custom-attack-groups cust-group set security idp idp-policy idpengine rulebase-ips rule 1 match attacks dynamic-attack-groups dyn2 set security idp idp-policy idpengine rulebase-ips rule 1 then action no-action set security idp idp-policy idpengine rulebase-ips rule 1 then notification log-attacks set security idp active-policy idpengine set security idp custom-attack customftp severity info set security idp custom-attack customftp attack-type signature context ftp-username set security idp custom-attack customftp attack-type signature pattern .*guest.* set security idp custom-attack customftp attack-type signature direction client-to-server set security idp custom-attack-group cust-group group-members customftp set security idp custom-attack-group cust-group group-members ICMP:INFO:TIMESTAMP set security idp custom-attack-group cust-group group-members "TELNET - Major" set security idp custom-attack-group cust-group group-members dyn1 set security idp dynamic-attack-group dyn1 filters category values TROJAN set security idp dynamic-attack-group dyn2 filters direction expression and set security idp dynamic-attack-group dyn2 filters direction values server-to-client set security idp dynamic-attack-group dyn2 filters direction values client-to-server set security idp dynamic-attack-group dyn2 filters age-of-attack less-than value 7 set security idp dynamic-attack-group dyn2 filters vulnerability-type values Injection set security idp dynamic-attack-group dyn2 filters vendor Microsoft set security idp dynamic-attack-group dyn2 filters cvss-score less-than value 7 set security idp traceoptions file idpd set security idp traceoptions flag all
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur cette procédure, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.
Pour configurer des groupes d’attaques avec des groupes d’attaques dynamiques et des groupes d’attaques personnalisés :
Créez une stratégie IDP.
[edit] user@host# set security idp idp-policy idpengine
Associez une base de règles à la stratégie.
[edit security idp idp-policy idpengine] user@host# set rulebase-ips
Ajoutez des règles à la base de règles.
[edit security idp idp-policy idpengine rulebase-ips] user@host# set rule 1
Définissez les critères de correspondance de la règle.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set match from-zone any user@host# set match source-address any user@host# set match to-zone any user@host# set match destination-address any
Spécifiez un nom d’ensemble d’applications pour qu’il corresponde aux critères de la règle.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set match application default
Spécifiez une correspondance pour le groupe d’attaques personnalisé.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set match attacks custom-attack-groups cust-group
Spécifiez une correspondance pour le groupe d’attaques dynamiques.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set match attacks dynamic-attack-groups dyn2
Spécifiez une action pour la règle.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set then action no-action
Spécifiez les options de notification ou de journalisation pour la règle.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set then notification log-attacks
Activez la stratégie IDP.
[edit] user@host# set security idp active-policy idpengine
Spécifiez un nom pour l’attaque personnalisée.
[edit security idp] user@host# set custom-attack customftp
Définissez la gravité de l’attaque personnalisée.
[edit security idp custom-attack customftp] user@host# set severity info
Définissez le type et le contexte de l’attaque.
[edit security idp custom-attack customftp] user@host# set attack-type signature context ftp-username
Spécifiez un modèle pour l’attaque.
[edit security idp custom-attack customftp] user@host# set attack-type signature pattern .*guest.*
Spécifiez la direction de l’attaque.
[edit security idp custom-attack customftp] user@host# set attack-type signature direction client-to-server
Spécifiez un nom pour le groupe d’attaques personnalisé.
[edit security idp] user@host# set custom-attack-group cust-group
Spécifiez une liste d’attaques ou de groupes d’attaques qui appartient au groupe d’attaques personnalisé.
[edit security idp custom-attack-group cust-group] user@host# set group-members customftp user@host# set group-members ICMP:INFO:TIMESTAMP user@host# set group-members "TELNET - Major" user@host# set group-members dyn1
Spécifiez un nom pour le premier groupe d’attaques dynamiques.
[edit security idp] user@host# set dynamic-attack-group dyn1
Configurez un filtre et définissez une valeur de catégorie pour le filtre.
[edit security idp dynamic-attack-group dyn1 ] user@host# set filters category values TROJAN
Spécifiez un nom pour le deuxième groupe d’attaques dynamiques.
[edit security idp] user@host# set dynamic-attack-group dyn2
Configurez un filtre pour le deuxième groupe d’attaques dynamiques et définissez la direction et ses valeurs pour ce champ.
[edit security idp dynamic-attack-group dyn2 ] user@host# set filters direction expression and user@host# set filters direction values server-to-client user@host# set filters direction values client-to-server user@host# set filters age-of-attack less-than value 7 user@host# set filters cvss-score less-than value 7 user@host# set filters file-type MPEG user@host# set filters vendor Microsoft user@host# set filters vulnerability-type values Injection
Spécifiez les options de suivi et les informations du fichier de suivi pour les services IDP.
[edit] user@host# set security idp traceoptions file idpd
Spécifiez les événements et autres informations qui doivent être inclus dans la sortie de trace.
[edit] user@host# set security idp traceoptions flag all
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show security idp 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 idp
idp-policy idpengine {
rulebase-ips {
rule 1 {
match {
from-zone any;
source-address any;
to-zone any;
destination-address any;
application default;
attacks {
custom-attack-groups cust-group;
dynamic-attack-groups dyn2;
}
}
then {
action {
no-action;
}
notification {
log-attacks;
}
}
}
}
}
active-policy idpengine;
custom-attack customftp {
severity info;
attack-type {
signature {
context ftp-username;
pattern .*guest.*;
direction client-to-server;
}
}
}
custom-attack-group cust-group {
group-members [ customftp ICMP:INFO:TIMESTAMP "TELNET - Major" dyn1 ];
}
dynamic-attack-group dyn1 {
filters {
category {
values TROJAN;
}
}
}
dynamic-attack-group dyn2 {
filters {
direction {
expression and;
values [ server-to-client client-to-server ];
}
age-of-attack less-than
{
value 7;
}
vulnerability-type
{
values Injection;
}
vendor Microsoft;
cvss-score less-than
{
value 7;
}
}
}
traceoptions {
file idpd;
flag all;
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Lorsque vous passez commit en mode configuration, la configuration est vérifiée en interne, puis validée. S’il y a des erreurs, la validation échouera et les erreurs seront signalées.
Vérification
Vérification de la configuration
But
Vérifiez que la configuration est correcte.
Action
À partir du mode opérationnel, entrez la show security idp policy-commit-status commande pour vérifier l’état de la compilation ou du chargement de la stratégie.
La sortie de la show security idp policy-commit-status commande est dynamique, il n’y a donc pas de sortie unique pour cette commande.
Vérifiez que les attaques sont détectées conformément à la configuration, transmettez le trafic via l’appareil, ce qui déclenchera une correspondance d’attaque. Par exemple, entrez la show security idp status commande pour vérifier si la stratégie est chargée ou non.
user@host> show security idp status
IDP policy[/var/db/idpd/bins/test.bin.gz.v] and detector[/var/db/idpd/sec-repository/installed-detector/libidp-detector.so.tgz.v] loaded successfully. The loaded policy size is:785 Bytes
Entrez la commande pour transmettre le show security idp attack table trafic d’attaque, puis vérifiez que les attaques sont détectées ou non.
La commande n’affichera la sortie que lorsque des attaques sont détectées.
user@host> show security idp attack table
IDP attack statistics: Attack name #Hits FTP:USER:ROOT 1
Expressions DFA d’objet d’attaque personnalisées
Le Tableau 25 fournit des exemples de syntaxe pour faire correspondre un modèle d’attaque.
Exemple de syntaxe |
Description |
Exemples de correspondances |
|---|---|---|
Bonjour.. \B.0.1.. 00\B... monde |
Il y a deux aspects à l’appariement : Doit correspondre au modèle de masque de bits : \B.0.0.1.. 00\B Doit correspondre au nombre d’octets (signifié par .) avant et après le motif de masque de bits. |
Allumettes: Bonjour.. \B.0.11100\B... mondeBonjour.. \B.0.10000\B... monde Ne correspond pas : Bonjour.\B.0.1.. 00\B.worldBonjour.. \B.0.1.. 11\B... monde |
\X01 86 A5 00 00\X |
Modèle avec les cinq octets spécifiés mot pour mot. |
Tél. 01 86 A5 00 00 |
(hello|world) |
Motif avec bonjour ou monde se produisant une fois. |
Bonjour monde |
(hello|world)+ |
Motif avec bonjour ou monde se produisant une ou plusieurs fois. |
helloworld bonjour le monde bonjourbonjour |
\[Bonjour\] |
Pattern hello, insensible à la casse. |
Bonjour Bonjour Bonjour |
\uBonjour\u |
Pattern hello, Unicode insensible. |
Bonjour 68656c6c6f |
hello\sworld |
Modèle hello world, les deux mots séparés par un espace. |
Salut tout le monde |
[c-e]a(d|t) |
Modèle avec la première lettre de c, d ou e ; la lettre du milieu a ; et se terminant par d ou t. |
chat papa manger |
[^c-d]a(d|t) |
Modèle qui commence par une lettre autre que c, d ou e ; avoir la deuxième lettre a ; et se terminent par d ou t. |
mode Zad |
a*b+c |
Modèle avec n’importe quel nombre de caractères (y compris zéro) ; suivi d’un ou plusieurs caractères b ; suivi d’un c caractère. |
av. J.-C abc aaaabbbbc |
T[Kk] |
Modèle qui commence par un T majuscule, suivi d’un k insensible à la casse. |
TK Tk |
([Tt])k |
Modèle qui commence par un t insensible à la casse, suivi d’un k minuscule. |
Tk Tk |
Mer[Dans] |
Motif commençant par Mer, suivi d’un l, d’un m ou d’un n minuscule. |
Phoque Couture Sean |
([B-D])at |
Modèle qui commence par un B majuscule, C ou D, suivi d’un at minuscule. |
Chauve-souris Chat Dat |
\0133\[bonjour\]\0135 |
Modèle qui commence par une parenthèse ouvrante, suivie d’un bonjour insensible à la casse, se terminant par une parenthèse fermante. Cette expression utilise l’expression \0 pour signifier que l’expression suivante est un code octal, puis le code octal de la parenthèse ouvrante (133) ou de la parenthèse fermante (135) suit. |
[bonjour] [HeLLo] |
Exemple : Utilisation de la négation de modèle
Vous pouvez utiliser la négation de modèle pour exclure un modèle connu pour être sûr et pour correspondre à tout le reste.
Par exemple, supposons que vous conceviez un objet d’attaque pour inspecter le trafic vers un serveur FTP. Vous savez que le nom d’utilisateur et les mots de passe du compte sont bien conservés pour garantir que seuls les utilisateurs autorisés peuvent accéder aux ressources internes. Cependant, à mesure que les réseaux se développent et que de nouveaux composants sont ajoutés, les comptes utilisateurs peuvent proliférer, augmentant ainsi l’accès réseau à des composants spécifiques. Dans cet exemple, vous avez un serveur FTP sur votre réseau interne sur lequel plusieurs comptes d’utilisateur sont activés. Pour améliorer la sécurité, vous souhaitez restreindre l’accès à l’administrateur FTP.
Vous créez un objet d’attaque pour le service FTP, le contexte ftp-username et le modèle admin, puis vous cochez la case Annuler . Le résultat est un objet d’attaque qui peut signaler les tentatives de connexion d’utilisateurs autres que admin. Vous pouvez utiliser cet objet d’attaque dans une règle qui consigne ou supprime le trafic correspondant.
Voir aussi
Exemple : Extensions de fichiers correspondantes
Dans cet exemple, vous souhaitez détecter les métafichiers Microsoft Windows, qui utilisent les extensions .emf (Windows Enhanced Metafiles) et .wmf (Microsoft Windows Metafile).
Pour faire correspondre l’un ou l’autre de ces types de fichiers, utilisez une expression DFA simple :
.*\.\[w|emf\]
Dans cette expression :
Le point, combiné à l’astérisque (.*), indique qu’un ou plusieurs caractères doivent apparaître (caractère générique).
La barre oblique inverse combinée au point (\.) indique que le point est échappé (le point apparaît dans le modèle).
Les parenthèses au début et à la fin de l’expression ( ) indiquent un groupe. La barre verticale entre le e et le w (e|w) indique une relation OU entre les caractères. Pour cette expression, e ou w doit apparaître dans le motif pour correspondre à cette expression ; Un seul doit être présent.
Le crochet ouvrant (\[) indique le début d’une correspondance insensible à la casse pour tous les caractères jusqu’à ce que le crochet fermant (\]) apparaisse.
Le crochet fermant (\]) indique la fin d’une correspondance insensible à la casse.
Voir aussi
Exemple : attaques par déni de service Apache Tomcat
Dans cet exemple, nous supposons que vous disposez d’un serveur Web exécutant Apache Tomcat. Votre administrateur de sécurité vous informe qu’une vulnérabilité vient d’être annoncée pour Apache Tomcat, et vous décidez de créer un objet d’attaque personnalisé pour protéger votre réseau jusqu’à ce que vous puissiez planifier un temps d’arrêt pour corriger le serveur.
L’avis CVE relatif à la vulnérabilité (http://nvd.nist.gov/nvd.cfm?cvename=CAN-2002-0682) contient la citation suivante :
A cross-site scripting vulnerability in Apache Tomcat 4.0.3 allows remote attackers to execute script as other web users via script in a URL with the /servlet/ mapping, which does not filter the script when an exception is thrown by the servlet.
À partir de ces informations, vous savez que l’attaque utilise HTTP. Vous devez maintenant localiser le code d’attaque. L’avis comprend également des références qui renvoient vers plus d’informations sur l’attaque. Malheureusement, aucune des pages Web référencées ne contient de code d’exploitation. Après avoir effectué une recherche sur le Web à l’aide des informations que vous avez apprises grâce à l’avis CVE, vous localisez un code d’exploitation sur http://packetstormsecurity.nl/0210-exploits/neuter.c. Copiez le script et déplacez-le sur l’ordinateur de l’attaquant dans votre laboratoire de test.
Pour développer cet objet d’attaque :
Voir aussi
Liste des conditions de test IDP pour un protocole spécifique
Lorsque vous configurez des attaques personnalisées IDP, vous pouvez spécifier des conditions de test de liste pour un protocole spécifique. Pour répertorier les conditions de test pour ICMP :
Répertoriez les conditions de test prises en charge pour ICMP et choisissez celle que vous souhaitez configurer. Les conditions de test prises en charge sont disponibles dans l’interface de ligne de commande au niveau de la
[edit security idp custom-attack test1 attack-type anomaly]hiérarchie.user@host#set test icmp? Possible completions: <test> Protocol anomaly condition to be checked ADDRESSMASK_REQUEST DIFF_CHECKSUM_IN_RESEND DIFF_CHECKSUM_IN_RESPONSE DIFF_LENGTH_IN_RESEND
Configurez le service pour lequel vous souhaitez configurer la condition de test.
user@host# set service ICMP
Configurez la condition de test (il n’est pas nécessaire de spécifier le nom du protocole).
user@host# set test ADDRESSMASK_REQUEST
Si vous avez terminé de configurer l’appareil, passez
commiten mode de configuration.
Comprendre les décodeurs de protocole IDP
Les décodeurs de protocole sont utilisés par la détection et prévention d’intrusion (IDP) pour vérifier l’intégrité du protocole et les informations contextuelles du protocole en recherchant des anomalies et en s’assurant que les normes RFC sont respectées. Une anomalie peut être n’importe quelle partie d’un protocole, comme l’en-tête, le corps du message ou d’autres champs individuels qui s’écartent des normes RFC pour ce protocole. Par exemple, dans le cas de SMTP, si SMTP MAIL TO précède SMTP HELO, il s’agit d’une anomalie dans le protocole SMTP.
Lorsque des informations contextuelles sur le protocole sont disponibles, les décodeurs de protocole vérifient les attaques dans ces contextes. Par exemple, pour SMTP, si un e-mail est envoyé à user@company.com, user@company.com est l’information contextuelle et SMTP MAIL TO est le contexte. En utilisant les données contextuelles du protocole, plutôt que l’ensemble du paquet, pour détecter les attaques, les décodeurs de protocole améliorent les performances et la précision globales.
Si une stratégie est configurée avec une règle qui correspond à la vérification du décodeur de protocole pour SMTP, la règle se déclenche et les mesures appropriées sont prises.
Le module IDP est livré avec un ensemble préconfiguré de décodeurs de protocole. Ces décodeurs de protocole ont des paramètres par défaut pour les diverses vérifications contextuelles spécifiques au protocole qu’ils effectuent. Vous pouvez utiliser ces valeurs par défaut ou les ajuster pour répondre aux besoins spécifiques de votre site. Pour afficher la liste des décodeurs de protocole disponibles, entrez la commande suivante :
user@host # show security idp sensor-configuration detector protocol-name ?
Pour obtenir une vue plus détaillée de l’ensemble actuel de décodeurs de protocole et de leurs valeurs de contexte par défaut, vous pouvez afficher le fichierdetector-capabilities.xml situé dans le dossier /ar/db/idpd/sec-download de l’appareil. Lorsque vous téléchargez un nouveau package de sécurité, vous recevez également ce fichier qui répertorie les protocoles actuels et les valeurs de contexte par défaut du décodeur.
Exemple : Vulnérabilité CDE/dtlogin sous UNIX
Dans cet exemple, votre réseau comprend plusieurs postes de travail utilisateurs et des serveurs exécutant UNIX. De nombreux systèmes d’exploitation UNIX utilisent le Common Desktop Environment (CDE) comme interface utilisateur graphique. Votre administrateur de sécurité vous informe d’une nouvelle vulnérabilité dans le processus dtlogin pour CDE (le processus dtlogin gère un processus de connexion GUI à CDE).
L’avis CERT relatif à la vulnérabilité (http://www.kb.cert.org/vuls/id/179804) contient les informations suivantes :
...The dtlogin program contains a "double-free" vulnerability that can be triggered by a specially crafted X Display Manager Control Protocol (XDMCP) packet... Block XDMCP traffic (177/udp) from untrusted networks such as the Internet...
À partir de ces informations, vous savez que l’attaque utilise le paquet de protocole XDMCP et s’exécute sur UDP/177. Vous devez maintenant localiser le code d’attaque. L’avis comprend également des références qui renvoient vers plus d’informations sur l’attaque. Une référence, http://lists.immunitysec.com/pipermail/dailydave/2004-March/000402.html, indique que la personne qui a signalé l’attaque en premier a également écrit un script qui reproduit l’attaque. Procurez-vous le script et déplacez-le sur l’ordinateur de l’attaquant dans votre laboratoire de test.
Pour développer cet objet d’attaque :
Voir aussi
Exemple : Détection d’un ver
Les vers et les chevaux de Troie contournent souvent les pare-feu et d’autres mesures de sécurité traditionnelles pour pénétrer dans un réseau. Dans cet exemple, vous allez créer un objet d’attaque personnalisé pour détecter le ver Blaster sur votre réseau.
L’avis CERT (http://www.cert.org/advisories/CA-2003-20.html) concernant le ver Blaster donne les informations suivantes :
The W32/Blaster worm exploits a vulnerability in Microsoft's DCOM RPC interface...”
À partir de ces informations, vous savez que l’attaque utilise l’exploit DCOM, une faille de sécurité précédemment identifiée. Vous devez maintenant localiser le code d’attaque. L’avis comprend également des références qui renvoient vers plus d’informations sur l’attaque. Malheureusement, aucune des pages Web référencées ne contient de code d’exploitation. Après avoir effectué une recherche sur le Web à l’aide des informations fournies par l’avis du CERT, vous localisez le code d’exploitation sur PacketStorm (http://packetstormsecurity.com/0307-exploits/dcom.c).
Pour développer cet objet d’attaque :
Voir aussi
Exemple : Signature composée pour détecter l’exploitation d’une vulnérabilité HTTP
Certaines attaques sont conçues pour paraître bénignes lorsqu’elles sont examinées paquet par paquet. Pour ces attaques, vous pouvez créer une signature composée qui détecte plusieurs modèles de signature dans plusieurs contextes (service, non-service ou les deux).
Dans cet exemple, vous disposez d’un serveur Web qui utilise les extensions Microsoft FrontPage Server. Votre administrateur de sécurité vous informe d’une nouvelle vulnérabilité de débordement de la mémoire tampon dans les extensions FrontPage Server.
L’avis BugTraq pour la vulnérabilité (http://www.securityfocus.com/bid/9007/discussion/) contient les informations suivantes :
Microsoft FrontPage Server Extensions are prone to a remotely exploitable buffer overrun vulnerability ... It is possible to trigger this condition with a chunked-encoded HTTP POST request...
L’exemple de démonstration de faisabilité suivant est également fourni :
POST /_vti_bin/_vti_aut/fp30reg.dll HTTP/1.1 Transfer-Encoding: chunked PostLength PostData 0
De plus, un lien vers l’exploit compilé est inclus.
À partir de ces informations, vous savez que l’attaque utilise le protocole HTTP et qu’au moins une partie de l’attaque utilise la méthode POST. Utilisez le lien vers l’exploit compilé pour obtenir le script et le déplacer vers l’ordinateur de l’attaquant dans votre laboratoire de test.
Pour développer cet objet d’attaque :
Voir aussi
Exemple : Utilisation de paramètres de liaison temporelle pour détecter une attaque par force brute
La contrainte de liaison temporelle nécessite que le modèle se produise un certain nombre de fois dans une minute pour que le trafic soit considéré comme une correspondance.
Vous pouvez utiliser le paramètre de liaison temporelle avec la signature pour détecter les signes d’une attaque par force brute. Un utilisateur qui change son mot de passe est un événement inoffensif, et est normalement vu occasionnellement sur le réseau. Cependant, des milliers de changements de mot de passe en une minute sont suspects.
Lors d’une attaque par force brute, l’attaquant tente de percer les défenses du système en utilisant la force pure, généralement en écrasant la capacité du serveur de destination ou en tentant à plusieurs reprises par essais et erreurs de faire correspondre les informations d’authentification. Lors d’une attaque par connexion par force brute, les attaquants rassemblent d’abord une liste de noms d’utilisateur et un dictionnaire de mots de passe. Ensuite, l’attaquant utilise un outil qui saisit le premier mot de passe dans le dictionnaire du premier utilisateur de la liste, puis essaie chaque mot de passe pour chaque utilisateur jusqu’à ce qu’il obtienne une correspondance. Si l’attaquant essaie toutes les combinaisons de noms d’utilisateur et de mots de passe, il réussit toujours. Cependant, les attaques par force brute échouent souvent parce que le dictionnaire de mots de passe est généralement limité (ne contient pas tous les mots de passe possibles) et que l’outil d’attaque n’effectue pas de permutations sur le mot de passe (comme inverser des lettres ou changer de casse).
Dans cet exemple, vous créez un objet d’attaque de signature qui détecte un nombre excessif de changements de mot de passe pour les utilisateurs authentifiés via HTTP (une application Web).
Tout d’abord, vous configurez un schéma d’attaque :
.*/\[changepassword\.cgi\]
Dans cette expression :
La combinaison de points étoiles (.*) indique une correspondance générique.
La barre oblique inverse avant un caractère indique que le caractère représente une expression régulière et qu’il doit être échappé. Dans ce cas, le caractère est une parenthèse ouvrante. La barre oblique inverse est également utilisée dans cette expression avant le marqueur d’extension de fichier (le point) et avant la parenthèse fermante.
Le nom du script cgi utilisé pour modifier les mots de passe des utilisateurs est inclus, ainsi que l’extension cgi.
Pour plus de contexte, sélectionnez HTTP-URL-PARSED dans la liste, car vous tentez de détecter les changements de mot de passe qui se produisent pour les applications Web. Le script changepassword.cgi, lorsqu’il est utilisé, apparaît dans le cadre de l’URL, mais vous devez indiquer à l’appareil IDP Series d’analyser l’URL afin de trouver le nom.
Ensuite, vous configurez la liaison temporelle.
Dans ces paramètres :
L’étendue est définie sur Pair afin que le modèle d’attaque puisse correspondre à l’événement, quelle que soit la source ou la destination.
Le nombre est défini sur un nombre élevé (jusqu’à 1000) pour éviter les faux positifs. Cette valeur signifie que le script changepassword.cgi doit apparaître 1000 fois dans une URL avant que l’objet d’attaque ne soit mis en correspondance.
Voir aussi
Référence : Numéros de protocole d’objet d’attaque personnalisés
Tableau 26 Numéros de protocole utilisés dans le système IDP.
Nom du protocole |
Numéro de protocole |
|---|---|
HOPOPT |
0 |
ICMP |
1 |
IGMP |
2 |
GGP |
3 |
L’IPIP |
4 |
ST |
5 |
TCP |
6 |
TCC (TCC) |
7 |
EGP |
8 |
L’IGP |
9 |
BBN-RCC-MON |
10 |
NVP-II |
11 |
CHIOT |
12 |
ARGUS |
13 |
EMCON |
14 |
XNET (en anglais seulement) |
15 |
CHAOS |
16 |
UDP |
17 |
MUX |
18 |
DCN-MEAS |
19 |
HMP |
20 |
PMR (en anglais) |
21 |
XND-IDP |
22 |
TRONC-1 |
23 |
TRONC-2 |
24 |
FEUILLE-1 |
25 |
FEUILLE-2 |
26 |
RDP |
27 |
L’IRTP |
28 |
ISO-TP4 |
29 |
NETBLT (en anglais seulement) |
30 |
MFE-NSP (en anglais seulement) |
31 |
MERIT-INP |
32 |
SEPT. |
33 |
3 pièces |
34 |
IDPR |
35 |
XTP (en anglais) |
36 |
DDP |
37 |
TP_PLUS_PLUS |
39 |
IL |
40 |
L’IPV6 |
41 |
Le SDRP |
42 |
ROUTAGE IPV6 |
43 |
FRAGMENT IDV6 |
44 |
L’IDRP |
45 |
RSVP |
46 |
GRE |
47 |
Le MHRP |
48 |
L’Amérique du Nord britannique |
49 |
ESP |
50 |
AH |
51 |
I-NLSP (en anglais seulement) |
52 |
PIQUER |
53 |
NARP (en anglais seulement) |
54 |
MOBILE |
55 |
TLSP (en anglais seulement) |
56 |
SAUTILLER |
57 |
IPV6-ICMP |
58 |
IPV6-NONXT |
59 |
IPV6-OPTS |
60 |
L’AHIP |
61 |
Le CFTP |
62 |
ALNP (en anglais seulement) |
63 |
SAT-EXPAK |
64 |
LE KRYPTOLAN |
65 |
RVD |
66 |
La CIPV |
67 |
L’ADFSP |
68 |
SAM-MON |
69 |
VISA |
70 |
L’IPCV |
71 |
Le CPNX |
72 |
La SSPC |
73 |
WSN |
74 |
PVP |
75 |
BR-SAM-MON |
76 |
DIM-ND |
77 |
WB-MON |
78 |
WB-EXPAK |
79 |
ISO-IP |
80 |
Le VMTP |
81 |
VMTP SÉCURISÉ |
82 |
VIGNES |
83 |
TTP |
84 |
NSFNET-IBP |
85 |
DGP |
86 |
Le TCF |
87 |
EIGRP (en anglais seulement) |
88 |
OSPFIGP (en anglais seulement) |
89 |
SPRITE-RPC |
90 |
GN |
91 |
MTP |
92 |
AX_25 |
93 |
L’IPIP |
94 |
Le MICP |
95 |
SCC-SP |
96 |
ETHERIP |
97 |
L’ENCAP |
98 |
SINGES |
99 |
GMTP (en anglais seulement) |
100 |
Le PGIP |
101 |
PNNI |
102 |
PIM |
103 |
ARIS |
104 |
SCPS |
105 |
QNX (en anglais) |
106 |
A/N |
107 |
IPCOMP (en anglais seulement) |
108 |
SNP |
109 |
COMPAT-PEER |
110 |
ZP-IN-IP |
111 |
VRRP (en anglais) |
112 |
PGM (en anglais seulement) |
113 |
HOP-O |
114 |
L2TP |
115 |
DDX |
116 |
L’IATP |
117 |
STP (en anglais seulement) |
118 |
SRP |
119 |
UTI |
120 |
SMP |
121 |
SSM |
122 |
PTP |
123 |
ISIS |
124 |
FEU |
125 |
Le CRTP |
126 |
Le CRUDP |
127 |
SSCOPMCE |
128 |
L’IPLT |
129 |
SPS |
130 |
PIPE |
131 |
Le protocole SCTP |
132 |
FC |
133 |
RSVP-E2E-IGNORE |
134 |
n/a |
|
n/a |
|
n/a |
|
RÉSERVÉ |
255 |
Référence : Caractères ASCII non imprimables et imprimables
Les tableaux suivants fournissent des détails sur la représentation ASCII des caractères imprimables et non imprimables.
Dec |
Sortilège |
Opo |
Carboniser |
Commentaire |
|---|---|---|---|---|
0 |
0 |
000 |
NUL |
Zéro |
1 |
1 |
001 |
SOH |
Début de l’en-tête |
2 |
2 |
002 |
STX (en anglais seulement) |
Début du texte |
3 |
3 |
003 |
ETX (en anglais seulement) |
Fin du texte |
4 |
4 |
004 |
EOT |
Fin de transmission |
5 |
5 |
005 |
ENQ |
Enquête |
6 |
6 |
006 |
ACK |
Reconnaître |
7 |
7 |
007 |
BEL |
Cloche |
8 |
8 |
010 |
BS |
Backspace |
9 |
9 |
011 |
ONGLET |
Onglet horizontal |
10 |
Un |
012 |
SI |
Saut de ligne |
11 |
B |
013 |
VT |
Onglet vertical |
12 |
C |
014 |
FF |
Flux de formulaire |
13 |
D |
015 |
CR |
Retour chariot |
14 |
E |
016 |
AINSI |
Décalage vers la sortie |
15 |
F |
017 |
SI |
Changement de vitesse |
16 |
10 |
020 |
DLE |
Échappatoire à la liaison de données |
17 |
11 |
021 |
DC1 |
Contrôle des équipements 1 |
18 |
12 |
022 |
CC2 |
Contrôle de l’équipement 2 |
19 |
13 |
023 |
DC3 |
Contrôle des équipements 3 |
20 |
14 |
024 |
DC4 |
Contrôle des équipements 4 |
21 |
15 |
025 |
NAK |
Accusé de réception négatif |
22 |
16 |
026 |
SYN |
Ralenti synchrone |
23 |
17 |
027 |
ETB (en anglais seulement) |
Fin du bloc de transmission |
24 |
18 |
030 |
POUVOIR |
Annuler |
25 |
19 |
031 |
EM |
Fin du moyen |
26 |
1A |
032 |
SUB |
Substituer |
27 |
1Md |
033 |
ESC |
Échapper |
28 |
1C |
034 |
FS |
Séparateur de fichiers |
29 |
1D |
035 |
GS |
Séparateur de groupe |
30 |
1E |
036 |
RS |
Séparateur d’enregistrements |
31 |
1F |
037 |
NOUS |
Séparateur d’unités |
Dec |
Sortilège |
Opo |
Carboniser |
|---|---|---|---|
32 |
20 |
040 |
Espace |
33 |
21 |
041 |
! |
34 |
22 |
042 |
|
35 |
23 |
043 |
# |
36 |
24 |
044 |
$ |
37 |
25 |
045 |
% |
38 |
26 |
046 |
& |
39 |
27 |
047 |
|
40 |
28 |
050 |
( |
41 |
29 |
051 |
) |
42 |
2A |
052 |
* |
43 |
2Mds |
053 |
+ |
44 |
2C |
054 |
, |
45 |
2D |
055 |
- |
46 |
2E |
056 |
. |
47 |
2F |
057 |
/ |
48 |
30 |
060 |
0 |
49 |
31 |
061 |
1 |
50 |
32 |
062 |
2 |
51 |
33 |
063 |
3 |
52 |
34 |
064 |
4 |
53 |
35 |
065 |
5 |
54 |
36 |
066 |
6 |
55 |
37 |
067 |
7 |
56 |
38 |
070 |
8 |
57 |
39 |
071 |
9 |
58 |
3A |
072 |
: |
59 |
3Mds |
073 |
; |
60 |
3C |
074 |
< |
61 |
3D |
075 |
= |
62 |
3E |
076 |
> |
63 |
3F |
077 |
? |
64 |
40 |
100 |
@ |
65 |
41 |
101 |
Un |
66 |
42 |
102 |
B |
67 |
43 |
103 |
C |
68 |
44 |
104 |
D |
69 |
45 |
105 |
E |
70 |
46 |
106 |
F |
71 |
47 |
107 |
G |
72 |
48 |
110 |
H |
73 |
49 |
111 |
Je |
74 |
4A |
112 |
J |
75 |
4Md |
113 |
K |
76 |
4C |
114 |
L |
77 |
4D |
115 |
M |
78 |
4E |
116 |
N |
79 |
4F |
117 |
O |
80 |
50 |
120 |
P |
81 |
51 |
121 |
Q |
82 |
52 |
122 |
R |
83 |
53 |
123 |
S |
'84 |
54 |
124 |
T |
85 |
55 |
125 |
U |
86 |
56 |
126 |
V |
87 |
57 |
127 |
W |
88 |
58 |
130 |
X |
89 |
59 |
131 |
Y |
90 |
5A |
132 |
Z |
91 |
5Mds |
133 |
[ |
92 |
5C |
134 |
\ |
93 |
5D |
135 |
] |
94 |
5E |
136 |
^ |
95 |
5F |
137 |
_ |
96 |
60 |
140 |
` |
97 |
61 |
141 |
un |
98 |
62 |
142 |
b |
99 |
63 |
143 |
c |
100 |
64 |
144 |
d |
101 |
65 |
145 |
e |
102 |
66 |
146 |
f |
103 |
67 |
147 |
g |
104 |
68 |
150 |
h |
105 |
69 |
151 |
Je |
106 |
6A |
152 |
j |
107 |
6Mds |
153 |
k |
108 |
6C |
154 |
l |
109 |
6D |
155 |
m |
110 |
6E |
156 |
n |
111 |
6F |
157 |
o |
112 |
70 |
160 |
p |
113 |
71 |
161 |
q |
114 |
72 |
162 |
r |
115 |
73 |
163 |
s |
116 |
74 |
164 |
t |
117 |
75 |
165 |
u |
118 |
76 |
166 |
v |
119 |
77 |
167 |
w |
120 |
78 |
170 |
x |
121 |
79 |
171 |
y |
122 |
7A (en anglais) |
172 |
z |
123 |
7Mds |
173 |
{ |
124 |
7C |
174 |
| |
125 |
7D |
175 |
} |
126 |
7E |
176 |
~ |
127 |
7F |
177 |
DEL |
128 |
80 |
200 |
Ç |
129 |
81 |
201 |
ü |
130 |
82 |
202 |
é |
131 |
83 |
203 |
â |
132 |
84 |
204 |
ä |
133 |
85 |
205 |
à |
134 |
86 |
206 |
å |
135 |
87 |
207 |
ç |
136 |
88 |
210 |
ê |
137 |
89 |
211 |
ë |
138 |
8A |
212 |
è |
139 |
8Mds |
213 |
ï |
140 |
8C |
214 |
î |
141 |
8D |
215 |
ì |
142 |
8E |
216 |
Ä |
143 |
8F |
217 |
Å |
144 |
90 |
220 |
É |
145 |
91 |
221 |
æ |
146 |
92 |
222 |
Æ |
147 |
93 |
223 |
ô |
148 |
94 |
224 |
ö |
149 |
95 |
225 |
ò |
150 |
96 |
226 |
û |
151 |
97 |
227 |
ù |
152 |
98 |
230 |
ÿ |
153 |
99 |
231 |
Ö |
154 |
9A (en anglais seulement) |
232 |
Ü |
155 |
9Mds |
233 |
¢ |
156 |
9C |
234 |
£ |
157 |
9D |
235 |
¥ |
158 |
9E |
236 |
P |
159 |
9F |
237 |
ƒ |
160 |
A0 |
240 |
á |
161 |
A1 |
241 |
í |
162 |
A2 (en anglais) |
242 |
ó |
163 |
A3 (en anglais) |
243 |
ú |
164 |
A4 (en anglais) |
244 |
ñ |
165 |
A5 (en anglais) |
245 |
Ñ |
166 |
A6 |
246 |
ª |
167 |
L’A7 |
247 |
º |
168 |
L’A8 |
250 |
¿ |
169 |
L’A9 |
251 |
¬ |
170 |
AA |
252 |
|
171 |
AB |
253 |
1/2 |
172 |
Courant alternatif |
254 |
1/4 |
173 |
ANNONCE |
255 |
¡ |
174 |
Æ |
256 |
" |
175 |
AF |
257 |
" |
176 |
B0 |
260 |
¦ |
177 |
Réf. B1 |
262 |
¦ |
178 |
Catégorie B2 |
262 |
¦ |
179 |
Catégorie B3 |
263 |
¦ |
180 |
Catégorie B4 |
264 |
¦ |
181 |
Catégorie B5 |
265 |
¦ |
182 |
Réf. B6 |
266 |
¦ |
183 |
Réf. B7 |
267 |
+ |
184 |
B8 |
270 |
+ |
185 |
Réf. B9 |
271 |
¦ |
186 |
BA |
272 |
¦ |
187 |
BB |
273 |
+ |
188 |
Av. J.-C |
274 |
+ |
189 |
BD |
275 |
+ |
190 |
ÊTRE |
276 |
+ |
191 |
BF |
277 |
+ |
192 |
C0 |
300 |
+ |
193 |
C1 |
301 |
- |
194 |
C2 |
302 |
- |
195 |
C3 |
303 |
+ |
196 |
C4 |
304 |
- |
197 |
C5 |
305 |
+ |
198 |
C6 |
306 |
¦ |
199 |
C7 |
307 |
¦ |
200 |
Le C8 |
310 |
+ |
201 |
C9 |
311 |
+ |
202 |
CA |
312 |
- |
203 |
CB |
313 |
- |
204 |
CC |
314 |
¦ |
205 |
CD |
315 |
- |
206 |
Après Jésus-Christ |
316 |
+ |
207 |
CF |
317 |
- |
208 |
D0 |
320 |
- |
209 |
J1 |
321 |
- |
210 |
D2 |
322 |
- |
211 |
J3 |
323 |
+ |
212 |
D4 |
324 |
+ |
213 |
J5 |
325 |
+ |
214 |
D6 |
326 |
+ |
215 |
D7 |
327 |
+ |
216 |
D8 |
330 |
+ |
217 |
D9 |
331 |
+ |
218 |
DA |
332 |
+ |
219 |
DB |
333 |
¦ |
220 |
Courant continu |
334 |
_ |
221 |
DD |
335 |
¦ |
222 |
DE |
336 |
¦ |
223 |
DF |
337 |
¯ |
224 |
E0 |
340 |
un |
225 |
E1 |
341 |
ß |
226 |
E2 |
342 |
G |
227 |
L’E3 |
343 |
p |
228 |
E4 |
344 |
S |
229 |
E5 |
345 |
s |
230 |
E6 |
346 |
μ |
231 |
E7 |
347 |
t |
232 |
E8 |
350 |
F |
233 |
E9 |
351 |
T |
234 |
EA |
352 |
O |
235 |
EB |
353 |
d |
236 |
CE |
354 |
8 |
237 |
ED |
355 |
f |
238 |
EE |
356 |
e |
239 |
EF |
357 |
n |
240 |
F0 |
360 |
= |
241 |
F1 (en anglais) |
361 |
+/- |
242 |
F2 |
362 |
= |
243 |
F3 (en anglais) |
363 |
= |
244 |
F4 |
364 |
( |
245 |
F5 |
365 |
) |
246 |
F6 |
366 |
÷ |
247 |
F7 |
367 |
˜ |
248 |
F8 |
370 |
° |
249 |
F9 |
371 |
﹒ |
250 |
FA |
372 |
﹒ |
251 |
FB |
373 |
v |
252 |
FC |
374 |
n |
253 |
FD |
375 |
² |
254 |
FE |
376 |
¦ |
255 |
FF |
377 |
|
Exemple : configuration de décodeurs de protocole IDP
Cet exemple montre comment configurer les paramètres du décodeur de protocole IDP.
Exigences
Avant de commencer, passez en revue la fonctionnalité de décodeurs de protocole IDP. Reportez-vous à la section Présentation des décodeurs de protocole IDP.
Aperçu
Le module IDP Junos est livré avec un ensemble de décodeurs de protocole préconfigurés. Ces décodeurs de protocole ont des paramètres par défaut pour les diverses vérifications contextuelles spécifiques au protocole qu’ils effectuent. Vous pouvez utiliser les paramètres par défaut ou les ajuster pour répondre aux besoins spécifiques de votre site. Cet exemple vous montre comment régler le décodeur de protocole pour FTP.
Configuration
Procédure
Procédure étape par étape
Pour configurer les paramètres du décodeur de protocole IDP :
Affichez la liste des protocoles qui ont des paramètres réglables.
[edit] user@host# edit security idp sensor-configuration detector protocol-name FTP
Configurez les paramètres réglables pour le protocole FTP.
[edit security idp sensor-configuration-detector protocol-name FTP] user@host# set tunable-name sc_ftp_failed_logins tunable-value 4 user@host# set tunable-name sc_ftp_failed_flags tunable value 1 user@host# set tunable-name sc_ftp_line_length tunable-value 1024 user@host# set tunable-name sc_ftp_password_length tunable-value 64 user@host# set tunable-name sc_ftp_sitestring_length tunable-value 512 user@host# set tunable-name sc_ftp_username_length tunable-value 32
Si vous avez terminé de configurer l’appareil, validez la configuration.
[edit] user@host# commit
Vérification
Pour vérifier que la configuration fonctionne correctement, entrez la show security idp status commande.
Comprendre la prise en charge de plusieurs détecteurs IDP
Lorsqu’un nouveau package de sécurité est reçu, il contient des définitions d’attaque et un détecteur. Dans n’importe quelle version d’un package de sécurité, les définitions d’attaque correspondent aux capacités du détecteur inclus. Lorsque l’ancienneté des stratégies est désactivée sur l’appareil (voir l’instruction reset-on-policy pour les commandes d’ancienneté des stratégies), une seule stratégie est active à la fois. Toutefois, si la datation des stratégies est activée et qu’une mise à jour est effectuée, la stratégie existante n’est pas déchargée lors du chargement de la nouvelle stratégie. Par conséquent, les deux stratégies peuvent être en vigueur sur l’appareil. Dans ce cas, toutes les sessions existantes continueront d’être inspectées par des stratégies existantes et les nouvelles sessions seront inspectées avec de nouvelles stratégies. Une fois que toutes les sessions existantes utilisant l’ancienne stratégie se sont terminées ou ont expiré, l’ancienne stratégie est alors déchargée.
Lorsqu’une stratégie est chargée, elle est également associée à un détecteur. Si la nouvelle stratégie en cours de chargement a un détecteur associé qui correspond au détecteur déjà utilisé par la stratégie existante, le nouveau détecteur n’est pas chargé et les deux stratégies utilisent un seul détecteur associé. Mais si le nouveau détecteur ne correspond pas au détecteur actuel, le nouveau détecteur est chargé avec la nouvelle stratégie. Dans ce cas, chaque stratégie chargée utilisera alors son propre détecteur associé pour détecter les attaques.
Notez qu’un maximum de deux détecteurs peuvent être chargés à la fois. Si deux détecteurs sont déjà chargés (par deux stratégies ou plus) et que le chargement d’une nouvelle stratégie nécessite également le chargement d’un nouveau détecteur, au moins un des détecteurs chargés doit être déchargé avant que le nouveau détecteur puisse être chargé. Avant qu’un détecteur ne soit déchargé, toutes les stratégies qui utilisent le détecteur correspondant sont également déchargées.
Vous pouvez afficher la stratégie actuelle et la version correspondante du détecteur en entrant la commande suivante :
user@host> show security idp status
À partir de Junos OS version 18.4R1, 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. L’inspection IDP se poursuit pour les attaques contextuelles 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.
Comprendre la décompression de contenu
Dans les protocoles d’application comme HTTP, le contenu peut être compressé puis transmis sur le réseau. Les modèles ne correspondent pas au contenu compressé, car ils sont écrits pour correspondre aux données de trafic non codées. Dans ce cas, la détection de l’IDP est éludée. Pour éviter l’évasion de la détection IDP sur le contenu compressé HTTP, un sous-module IDP a été ajouté pour décompresser le contenu du protocole. La correspondance de motif de signature est effectuée sur le contenu décompressé.
Pour afficher l’état de toutes les valeurs du compteur IPS, entrez la commande suivante :
user@host> show security idp counters ips
Certaines attaques sont introduites par le biais de contenus compressés. Lorsque le contenu est décompressé, il peut prendre une taille très importante, ce qui consomme de précieuses ressources système, ce qui entraîne un déni de service. Ce type d’attaque est reconnaissable au rapport entre la taille des données décompressées et la taille des données compressées. Le compteur content-decompress-ratio-over-limit identifie le nombre d’incidents pour lesquels ce ratio a été dépassé. Le ratio de défaillance est considéré comme cohérent avec un environnement typique. Dans certains cas, cependant, il peut être nécessaire d’ajuster ce ratio en réinitialisant la content-decompress-ratio-over-limit valeur. Gardez à l’esprit, cependant, qu’un ratio plus élevé réduit les chances de détecter ce type d’attaque.
Le compteur content-decompress-memory-over-limit identifie le nombre d’incidents où la quantité de données décompressées a dépassé la mémoire allouée. L’allocation de mémoire par défaut fournit 33 Ko par session pour un nombre moyen de sessions nécessitant une décompression en même temps. Pour déterminer si cette valeur est cohérente avec votre environnement, analysez les valeurs des compteurs liés à la décompression et le nombre total de sessions IDP traversant l’équipement, et estimez le nombre de sessions nécessitant une décompression en même temps. En supposant que chacune de ces sessions nécessite 33 Ko de mémoire pour la décompression, comparez vos besoins estimés à la valeur par défaut. Si nécessaire, vous pouvez ajuster l’allocation de mémoire en réinitialisant la content-decompression-max-memory-kb valeur. Notez qu’étant donné que la décompression de contenu nécessite une allocation importante de mémoire, les performances du système seront affectées par l’augmentation de l’allocation maximale de mémoire pour la décompression.
Exemple : Configuration de la décompression de contenu IDP
Cet exemple montre comment configurer la décompression de contenu IDP.
Exigences
Avant de commencer, passez en revue la fonctionnalité de décompression de contenu IDP. Reportez-vous à la section Comprendre la décompression de contenu
Aperçu
La fonction de décompression est désactivée par défaut. Dans cet exemple, vous activez le détecteur, configurez la mémoire maximale à 50 000 kilo-octets et configurez un taux de décompression maximal de 16:1.
L’activation de la décompression entraînera une réduction des performances de votre appareil.
Configuration
Procédure
Procédure étape par étape
Pour configurer la décompression de contenu IDP :
Activez le détecteur.
[edit] user@host# set security idp sensor‑configuration detector protocol‑name HTTP tunable‑name sc_http_compress_inflating tunable‑value 1
Note:Pour désactiver le détecteur, réglez le
tunable‑valuesur 0.Si nécessaire, modifiez la mémoire maximale en kilo-octets.
[edit security idp] user@host# set sensor-configuration ips content-decompression-max-memory-kb 50000
Si nécessaire, configurez le taux de décompression maximal.
[edit security idp] user@host# set sensor-configuration ips content-decompression-max-ratio 16
Si vous avez terminé de configurer l’appareil, validez la configuration.
[edit] user@host# commit
Vérification
Pour vérifier que la configuration fonctionne correctement, entrez la show security idp status ips commande. Les compteurs de décompression de contenu fournissent des statistiques sur le traitement de la décompression.
Comprendre les attaques basées sur les signatures IDP
Pour configurer un objet d’attaque personnalisé, spécifiez un nom unique pour celui-ci, puis spécifiez des informations supplémentaires, ce qui peut vous aider à localiser et à gérer l’objet d’attaque.
Certaines propriétés des définitions d’objet d’attaque sont communes à tous les types d’attaques, telles que le nom de l’attaque, le niveau de gravité, la liaison de service ou d’application, la liaison temporelle et la liaison de protocole ou de port. Certains champs sont spécifiques à un type d’attaque et ne sont disponibles que pour cette définition d’attaque spécifique.
Les objets d’attaque de signature utilisent une signature d’attaque dynamique (un modèle qui existe toujours dans une section spécifique de l’attaque) pour détecter les attaques connues. Ils incluent également le protocole ou le service utilisé pour perpétrer l’attaque et le contexte dans lequel l’attaque se produit. Les propriétés suivantes sont spécifiques aux attaques de signature et vous pouvez les configurer lors de la configuration de l’attaque de signature : contexte de l’attaque, direction de l’attaque, modèle d’attaque et paramètres spécifiques au protocole (champs d’en-tête TCP, UDP, ICMP ou IP).
Lorsque vous configurez des attaques basées sur des signatures, gardez à l’esprit les points suivants :
Le contexte et la direction de l’attaque sont des champs obligatoires pour la définition de la signature de l’attaque.
La négation de modèle est prise en charge uniquement pour les contextes basés sur les paquets, les lignes et les applications, et non pour les contextes de flux et de flux normalisés.
Lorsque vous configurez les paramètres spécifiques au protocole, vous ne pouvez spécifier des champs que pour l’un des protocoles suivants : IP, TCP, UDP ou ICMP.
Lors de la configuration d’une liaison de protocole, vous ne pouvez spécifier qu’un seul des éléments suivants : IP, ICMP, TCP, UDP, RPC ou applications.
IP : le numéro de protocole est un champ obligatoire.
TCP et UDP : vous pouvez spécifier un seul port (
minimum-port) ou une plage de ports (minimum-portetmaximum-port). Si vous ne spécifiez pas de port, la valeur par défaut est prise (0-65535).RPC : le numéro de programme est un champ obligatoire.
À partir de Junos OS version 19.1R1, vous pouvez configurer des attaques basées sur des signatures à l’aide des paramètres étendus d’Hyperscan. En définissant des valeurs optimales pour les paramètres étendus d’Hyperscan, vous pouvez améliorer considérablement le processus de correspondance des modèles d’attaque.
Pour configurer les paramètres étendus, incluez l’option optional-parameters au niveau de la [edit security idp custom-attack attack-name attack-type signature] hiérarchie. Vous pouvez configurer les paramètres suivants sous l’option optional-parameters :
min-offsetmax-offsetmin-length
Bref principe de fonctionnement de l’API Hyperscan - Hyperscan est un moteur logiciel de correspondance d’expressions régulières conçu pour offrir des performances et une flexibilité élevées. Lorsqu’une signature avec un modèle est configurée dans le cadre d’une stratégie IDP, le modèle est identifié comme une expression régulière. Sur le moteur de routage, Hyperscan prend cette expression régulière en entrée et la compile pour former une base de données qui est envoyée au moteur de transfert de paquets. Lorsqu’un paquet entre dans le moteur de transfert de paquets, les données qu’il contient sont inspectées pour déterminer si elles correspondent à l’expression régulière utilisée dans la base de données.
Si une stratégie IDP est configurée avec un ensemble de signatures, des groupes d’automates finis déterministes (DFA) sont formés. Les modèles de toutes les signatures dans les groupes DFA sont transmis à Hyperscan pour former une base de données unique, qui peut être utilisée pour vérifier toutes les attaques dans le paquet à la fois. Étant donné qu’une seule base de données est utilisée au lieu d’une base de données distincte pour chaque attaque, le processus de correspondance de modèles est efficace.
Lorsqu’une signature est configurée avec les paramètres étendus, l’API Hyperscan forme la base de données en tenant compte des paramètres configurés. Le processus de correspondance de modèles se produit sur le moteur de transfert de paquets avec cette nouvelle base de données. Ces paramètres permettent de contraindre l’ensemble des correspondances produites par un motif au moment de la compilation plutôt que de dépendre de l’application pour traiter les correspondances indésirables au moment de l’exécution.
Voir aussi
Exemple : Configuration d’attaques basées sur des signatures IDP
Cet exemple montre comment créer un objet d’attaque basé sur des signatures.
Exigences
Avant de commencer, configurez les interfaces réseau.
Aperçu
Dans cet exemple, vous créez une attaque de signature appelée sig1 et lui attribuez les propriétés suivantes :
Action recommandée (supprimer le paquet) : supprime un paquet correspondant avant qu’il n’atteigne sa destination, mais ne ferme pas la connexion.
Liaison temporelle : spécifie l’étendue en tant que et le nombre en tant que
source10. Lorsque la portée estsource, toutes les attaques provenant de la même source sont comptées, et lorsque le nombre d’attaques atteint le nombre spécifié (10), l’attaque est consignée. Dans cet exemple, une attaque sur dix provenant de la même source est enregistrée.Contexte d’attaque (paquet) : correspond au modèle d’attaque au sein d’un paquet.
Direction de l’attaque (toute) : détecte l’attaque dans les deux sens : trafic client-serveur et serveur-client.
Protocol (TCP) : spécifie la valeur TTL de 128.
Shellcode (Intel) : définit l’indicateur de détection du shellcode pour les plates-formes Intel.
Protocol binding (Liaison de protocole) : spécifie le protocole TCP et les ports 50 à 100.
Une fois que vous avez configuré un objet d’attaque basé sur une signature, vous spécifiez l’attaque en tant que critère de correspondance dans une règle de stratégie IDP. Reportez-vous à la section Exemple : Définition de règles pour une base de règles IPS IDP.
Configuration
Procédure
Configuration rapide de la CLI
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
set security idp custom-attack sig1 severity major set security idp custom-attack sig1 recommended-action drop-packet set security idp custom-attack sig1 time-binding scope source count 10 set security idp custom-attack sig1 attack-type signature context packet set security idp custom-attack sig1 attack-type signature shellcode intel set security idp custom-attack sig1 attack-type signature protocol ip ttl value 128 match equal set security idp custom-attack sig1 attack-type signature protocol-binding tcp minimum-port 50 maximum-port 100 set security idp custom-attack sig1 attack-type signature direction any
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur cette procédure, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.
Pour créer un objet d’attaque basé sur des signatures :
Spécifiez un nom pour l’attaque.
[edit] user@host# edit security idp custom-attack sig1
Spécifiez les propriétés communes de l’attaque.
[edit security idp custom-attack sig1] user@host# set severity major user@host# set recommended-action drop-packet user@host# set time-binding scope source count 10
Spécifiez le type et le contexte de l’attaque.
[edit security idp custom-attack sig1] user@host# set attack-type signature context packet
Spécifiez la direction de l’attaque et l’indicateur shellcode.
[edit security idp custom-attack sig1] user@host# set attack-type signature shellcode intel
Définissez le protocole et ses champs.
[edit security idp custom-attack sig1] user@host# set attack-type signature protocol ip ttl value 128 match equal
Spécifiez la liaison de protocole et les ports.
[edit security idp custom-attack sig1] user@host# set attack-type signature protocol-binding tcp minimum-port 50 maximum-port 100
Spécifiez la direction.
[edit security idp custom-attack sig1] user@host# set attack-type signature direction any
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show security idp 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 idp
custom-attack sig1 {
recommended-action drop-packet;
severity major;
time-binding {
count 10;
scope source;
}
attack-type {
signature {
protocol-binding {
tcp {
minimum-port 50 maximum-port 100;
}
}
context packet;
direction any;
shellcode intel;
protocol {
ip {
ttl {
match equal;
value 128;
}
}
}
}
}
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Comprendre les attaques basées sur les anomalies du protocole IDP
Un objet d’attaque par anomalie de protocole détecte les attaques inconnues ou sophistiquées qui violent les spécifications du protocole (RFC et extensions RFC courantes). Vous ne pouvez pas créer d’anomalies de protocole, mais vous pouvez configurer un nouvel objet d’attaque qui contrôle la façon dont votre appareil gère une anomalie de protocole prédéfinie lorsqu’il est détecté.
Les propriétés suivantes sont spécifiques aux attaques par anomalie de protocole :
Direction de l’attaque
Condition d’essai
Lorsque vous configurez des attaques basées sur des anomalies de protocole, gardez à l’esprit les points suivants :
La liaison de service ou d’application est un champ obligatoire pour les attaques par anomalie de protocole. Outre les applications prises en charge, les services incluent également IP, TCP, UDP, ICMP et RPC.
Les propriétés Direction de l’attaque et Condition de test sont des champs obligatoires pour configurer les définitions d’attaque par anomalie.
Exemple : configuration d’attaques basées sur des anomalies de protocole IDP
Cet exemple montre comment créer un objet d’attaque basé sur une anomalie de protocole.
Exigences
Avant de commencer, configurez les interfaces réseau.
Aperçu
Dans cet exemple, vous créez une attaque par anomalie de protocole appelée anomalie1 et lui attribuez les propriétés suivantes :
Liaison temporelle : spécifie l’étendue et
peerle nombre de détections d’anomalies2entre les adresses IP source et de destination des sessions pour le nombre de fois spécifié.Gravité (info) : fournit des informations sur toute attaque qui correspond aux conditions.
Direction de l’attaque (toute) : détecte l’attaque dans les deux sens : trafic client-serveur et serveur-client.
Service (TCP) : correspond aux attaques effectuées à l’aide du service TCP.
Condition de test (OPTIONS_UNSUPPORTED) : correspond à certaines conditions de test prédéfinies. Dans cet exemple, la condition est de correspondre si l’attaque inclut des options non prises en charge.
Shellcode (sparc) : définit l’indicateur de détection du shellcode pour les plates-formes Sparc.
Une fois que vous avez configuré l’objet d’attaque basé sur une anomalie de protocole, vous spécifiez l’attaque en tant que critère de correspondance dans une règle de stratégie IDP. Reportez-vous à la section Exemple : Définition de règles pour une base de règles IPS IDP.
Configuration
Procédure
Configuration rapide de la CLI
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie, puis passez commit en mode de configuration.
set security idp custom-attack anomaly1 severity info set security idp custom-attack anomaly1 time-binding scope peer count 2 set security idp custom-attack anomaly1 attack-type anomaly test OPTIONS_UNSUPPORTED set security idp custom-attack sa set security idp custom-attack sa attack-type anomaly service TCP set security idp custom-attack sa attack-type anomaly direction any set security idp custom-attack sa attack-type anomaly shellcode sparc
Procédure étape par étape
L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur cette procédure, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de l’interface de ligne de commande.
Pour créer un objet d’attaque basé sur une anomalie de protocole :
Spécifiez un nom pour l’attaque.
[edit] user@host# edit security idp custom-attack anomaly1
Spécifiez les propriétés communes de l’attaque.
[edit security idp custom-attack anomaly1] user@host# set severity info user@host# set time-binding scope peer count 2
Spécifiez le type d’attaque et la condition de test.
[edit security idp custom-attack anomaly1] user@host# set attack-type anomaly test OPTIONS_UNSUPPORTED
Spécifiez d’autres propriétés pour l’attaque par anomalie.
[edit security idp custom-attack anomaly1] user@host# set attack-type anomaly service TCP user@host# set attack-type anomaly direction any user@host# attack-type anomaly shellcode sparc
Résultats
À partir du mode configuration, confirmez votre configuration en entrant la show security idp 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 idp
custom-attack anomaly1 {
severity info;
time-binding {
count 2;
scope peer;
}
attack-type {
anomaly {
test OPTIONS_UNSUPPORTED;
service TCP;
direction any;
shellcode sparc;
}
}
}
Si vous avez terminé de configurer l’appareil, passez commit en mode de configuration.
Vérification
Vue d’ensemble de la configuration de la stratégie IDP
La stratégie de détection et de prévention d’intrusion (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 périphérique compatible IDP. Elle vous permet de définir des règles de stratégie correspondant à une section de trafic en fonction d’une zone, d’un réseau et d’une application, puis de prendre des mesures préventives actives ou passives sur ce trafic.
Une stratégie IDP définit la manière dont votre appareil gère le trafic réseau. Il 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 bases de règles, et chaque base de règles contient un ensemble de règles. 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. Une fois que vous avez 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 appareil.
Pour configurer la stratégie IDP, procédez comme suit :
Activez l’IDP dans une stratégie de sécurité.
Configurez les règles de stratégie IDP, les bases de règles IDP et les actions de règle IDP. Voir les rubriques Exemple : Insertion d’une règle dans la base de règles IDP , Exemple : Définition de règles pour une base de règles IPS IDP et Exemple : Configuration et application de règles de réécriture sur un dispositif de sécurité .
Configurez les signatures personnalisées IDP. Consultez les rubriques Comprendre les attaques basées sur les signatures IDP et Exemple : Configuration des attaques basées sur les signatures IDP .
Mettez à jour la base de données de signatures IDP. Reportez-vous à la section Mise à jour de la base de données de signatures IDP.
Présentation des canaux secrets IPv6
Un canal secret est une technique d’attaque qui permet la communication d’informations en transférant des objets via des canaux d’information existants de manière non autorisée ou illicite. À l’aide de canaux cachés, un attaquant peut mener des activités malveillantes sur un réseau.
À partir de la version 19.1R1 de Junos OS, l’identification et l’atténuation des canaux cachés pour les en-têtes d’extension IPv6 sont prises en charge sur la détection et prévention d’intrusion (IDP). C’est le transfert d’informations qui viole les systèmes de sécurité existants. Le package de sécurité pour IDP contient une base de données d’objets d’attaque IDP prédéfinis pour le canal secret que vous pouvez utiliser dans les stratégies IDP pour faire correspondre le trafic aux attaques.
Dans le cadre de cette prise en charge, vous pouvez détecter et signaler les anomalies des en-têtes d’extension IPv6, ce qui peut établir des canaux secrets et prendre les mesures spécifiées dans la stratégie. Les attaques par canal caché sont affichées dans le Show security idp attack table fichier avec les autres attaques.
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.
interval interval-value est introduite au niveau de la
[edit security idp custom-attack attack-name time-binding] hiérarchie pour configurer une liaison temporelle personnalisée.
set security idp custom-attack commande.