ASA/PIX 7.x et versions ultérieures : Atténuation des attaques réseau

Introduction

Ce document décrit comment atténuer les diverses attaques réseau, telles que les dénis de service (DoS), en utilisant le dispositif de sécurité Cisco (ASA/PIX).

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à ce document.

Composants utilisés

Les informations contenues dans ce document sont basées sur le dispositif de sécurité adaptatif (ASA) de la gamme Cisco 5500 qui exécute le logiciel version 7.0 et ultérieure.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Produits connexes

Ce document peut également être utilisé avec la gamme Cisco 500 PIX qui exécute le logiciel version 7.0 et ultérieure.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Protection contre les attaques SYN

Comment atténuez-vous les attaques SYN (Synchronize/Start) du protocole TCP (Transmission Control Protocol) sur l'ASA/PIX ?

Attaque TCP SYN

L'attaque SYN TCP est un type d'attaque DoS dans laquelle un expéditeur transmet un volume de connexions qui ne peuvent pas être effectuées. Les files d'attente de connexion se remplissent, ce qui empêche les utilisateurs TCP légitimes d'accéder au service.

Lorsqu’une connexion TCP normale démarre, un hôte de destination reçoit un paquet SYN d’un hôte source et renvoie un accusé de réception de synchronisation (SYN ACK). L’hôte de destination doit alors entendre un ACK du SYN ACK avant que la connexion ne soit établie. Il s’agit de la connexion en trois étapes TCP.

En attendant que l’accusé de réception soit envoyé à l’accusé de réception SYN, une file d’attente de connexion de taille finie sur l’hôte de destination garde une trace des connexions en attente d’achèvement. Cette file d'attente se vide généralement rapidement, car l'accusé de réception doit arriver quelques millisecondes après l'accusé de réception SYN.

L’attaque TCP SYN exploite cette conception en demandant à un hôte source d’attaquer de générer des paquets TCP SYN avec des adresses source aléatoires vers un hôte cible. L’hôte de destination cible renvoie un SYN ACK à l’adresse source aléatoire et ajoute une entrée à la file d’attente de connexion. Étant donné que le SYN ACK est destiné à un hôte incorrect ou inexistant, la dernière partie de la « connexion en trois étapes » n'est jamais terminée et l'entrée reste dans la file d'attente de connexion jusqu'à ce qu'un minuteur expire, généralement pendant environ une minute. En générant rapidement des paquets TCP SYN bidon à partir d'adresses IP aléatoires, il est possible de remplir la file d'attente de connexion et de refuser les services TCP (tels que le courrier électronique, le transfert de fichiers ou WWW) aux utilisateurs légitimes.

Il n'existe pas de moyen simple de retracer l'origine de l'attaque, car l'adresse IP de la source est falsifiée.

Les manifestations externes du problème incluent l'impossibilité d'obtenir des e-mails, l'incapacité d'accepter des connexions aux services WWW ou FTP, ou un grand nombre de connexions TCP sur votre hôte dans l'état SYN_RCVD.

Référez-vous à Définition de stratégies de protection contre les attaques de déni de service TCP SYN pour plus d'informations sur les attaques TCP SYN.

Atténuation

Cette section décrit comment atténuer les attaques SYN en définissant le nombre maximal de connexions TCP et UDP (User Datagram Protocol), le nombre maximal de connexions embryonnaires, les délais d'expiration de connexion et comment désactiver le randomisation de séquences TCP.

Si la limite de connexion embryonnaire est atteinte, l'appliance de sécurité répond à chaque paquet SYN envoyé au serveur par un paquet SYN+ACK et ne transmet pas le paquet SYN au serveur interne. Si le périphérique externe répond par un paquet ACK, l'appliance de sécurité sait qu'il s'agit d'une requête valide (et qu'elle ne fait pas partie d'une attaque SYN potentielle). L'appliance de sécurité établit ensuite une connexion avec le serveur et relie les connexions entre elles. Si l'appliance de sécurité n'obtient pas de retour ACK du serveur, elle expire de façon agressive cette connexion embryonnaire.

Chaque connexion TCP comporte deux numéros de séquence initiaux (ISN) : une générée par le client et une générée par le serveur. L'appliance de sécurité randomise le numéro ISN du SYN TCP passant dans les directions entrante et sortante.

La randomisation du numéro ISN de l’hôte protégé empêche un pirate de prédire le numéro ISN suivant pour une nouvelle connexion et de potentiellement détourner la nouvelle session.

Si nécessaire, il est possible de désactiver la répartition aléatoire des numéros de séquence initiaux du protocole TCP. Exemple :

• Si un autre pare-feu en ligne effectue également la répartition aléatoire des numéros de séquence initiaux, il n’est pas nécessaire que les deux pare-feu effectuent cette mesure, même si cette mesure n’a pas d’incidence sur le trafic.

• Si vous utilisez le saut multiple BGP externe (eBGP) via l'appliance de sécurité et que les homologues eBGP utilisent MD5, la randomisation casse la somme de contrôle MD5.

• Vous utilisez un périphérique WAAS (Wide Area Application Services) qui nécessite que l'appliance de sécurité ne randomise pas les numéros de séquence des connexions.

Remarque : vous pouvez également configurer le nombre maximal de connexions, le nombre maximal de connexions embryonnaires et la randomisation des séquences TCP dans la configuration NAT. Si vous configurez ces paramètres pour le même trafic à l'aide des deux méthodes, l'appliance de sécurité utilise la limite inférieure. Pour la randomisation des séquences TCP, si elle est désactivée à l'aide de l'une ou l'autre des méthodes, l'appliance de sécurité désactive la randomisation des séquences TCP.

Complétez ces étapes afin de définir les limites de connexion :

1. Afin d'identifier le trafic, ajoutez une carte de classe à l'aide de la commande class-map conformément à Using Modular Policy Framework.

2. Afin d'ajouter ou de modifier une carte de stratégie qui définit les actions à entreprendre avec le trafic de la carte de classe, entrez cette commande :

   hostname(config)#policy-map name
   

3. Afin d'identifier la carte de classe (de l'étape 1) à laquelle vous voulez assigner une action, entrez cette commande :

   hostname(config-pmap)#class class_map_name
   

4. Afin de définir les connexions maximales (TCP et UDP), les connexions embryonnaires maximales, per-client-embryonic-max, per-client-max ou si vous voulez désactiver la randomisation de la séquence TCP, entrez cette commande :

   hostname(config-pmap-c)#set connection {[conn-max number] 
   [embryonic-conn-max number] [per-client-embryonic-max number] 
   [per-client-max number][random-sequence-number {enable | 
   disable}}

   Où number est un entier compris entre 0 et 65535. La valeur par défaut est 0, ce qui signifie qu'il n'y a pas de limite sur les connexions.

   Vous pouvez entrer cette commande sur une seule ligne (dans n'importe quel ordre) ou vous pouvez entrer chaque attribut sous forme de commande distincte. La commande est combinée sur une ligne dans la configuration en cours.

5. Afin de définir le délai d'attente pour les connexions, les connexions embryonnaires (semi-ouvertes) et les connexions semi-fermées, entrez cette commande :

   hostname(config-pmap-c)#set connection {[embryonic hh[:mm[:ss]]] 
   [half-closed hh[:mm[:ss]]] [tcp hh[:mm[:ss]]]}

   Où embryonic hh[:mm[:ss] est un temps entre 0:0:5 et 1192:59:59. La valeur par défaut est 0:0:30. Vous pouvez également définir cette valeur sur 0, ce qui signifie que la connexion n'expire jamais.

   Les valeurs half-closed hh[:mm[:ss] et tcp hh[:mm[:ss] sont un temps entre 0:5:0 et 1192:59:59. La valeur par défaut pour half-closed est 0:10:0 et la valeur par défaut pour tcp est 1:0:0. Vous pouvez également définir ces valeurs sur 0, ce qui signifie que la connexion n'expire jamais.

   Vous pouvez entrer cette commande sur une seule ligne (dans n'importe quel ordre) ou vous pouvez entrer chaque attribut sous forme de commande distincte. La commande est combinée sur une ligne dans la configuration en cours.

   • Connexion embryonnaire (semi-ouverte) : une connexion embryonnaire est une demande de connexion TCP qui n'a pas terminé la connexion nécessaire entre la source et la destination.

   • Connexion semi-fermée : connexion semi-fermée lorsque la connexion n'est fermée que dans une seule direction par l'envoi de FIN. Cependant, la session TCP est toujours maintenue par l'homologue.

   • Per-client-embryonic-max : nombre maximal de connexions embryonnaires simultanées autorisées par client, entre 0 et 65535. La valeur par défaut est 0, ce qui permet des connexions illimitées.

   • Per-client-max : nombre maximal de connexions simultanées autorisé par client, entre 0 et 65535. La valeur par défaut est 0, ce qui permet des connexions illimitées.

6. Afin d'activer le mappage de stratégie sur une ou plusieurs interfaces, entrez cette commande :

   hostname(config)#service-policy policymap_name {global | interface interface_name}
   
   

   Où global applique le mappage de stratégie à toutes les interfaces, et interface applique la stratégie à une interface. Une seule stratégie globale est autorisée. Vous pouvez remplacer la stratégie globale sur une interface en appliquant une stratégie de service à cette interface. Vous ne pouvez appliquer qu'un seul mappage de stratégie à chaque interface.

Exemple :

ciscoasa(config)#class-map tcp_syn
ciscoasa(config-cmap)#match port tcp eq 80
ciscoasa(config-cmap)#exit
ciscoasa(config)#policy-map tcpmap
ciscoasa(config-pmap)#class tcp_syn
ciscoasa(config-pmap-c)#set connection conn-max 100
ciscoasa(config-pmap-c)#set connection embryonic-conn-max 200
ciscoasa(config-pmap-c)#set connection per-client-embryonic-max 10
ciscoasa(config-pmap-c)#set connection per-client-max 5
ciscoasa(config-pmap-c)#set connection random-sequence-number enable
ciscoasa(config-pmap-c)#set connection timeout embryonic 0:0:45
ciscoasa(config-pmap-c)#set connection timeout half-closed 0:25:0
ciscoasa(config-pmap-c)#set connection timeout tcp 2:0:0
ciscoasa(config-pmap-c)#exit
ciscoasa(config-pmap)#exit
ciscoasa(config)#service-policy tcpmap global

Remarque : afin de vérifier le nombre total de sessions semi-ouvertes pour un hôte particulier, utilisez cette commande :

ASA-5510-8x# show local-host all

Interface dmz: 0 active, 0 maximum active, 0 denied
Interface management: 0 active, 0 maximum active, 0 denied
Interface xx: 0 active, 0 maximum active, 0 denied
Interface inside: 7 active, 18 maximum active, 0 denied

local host: <10.78.167.69>,

    TCP flow count/limit = 2/unlimited

    TCP embryonic count to host = 0

    TCP intercept watermark = unlimited

    UDP flow count/limit = 0/unlimited

Remarque : la ligne, TCP embryonic count to host, affiche le nombre de sessions semi-ouvertes.

Protection contre les attaques par usurpation IP

PIX/ASA peut-il bloquer les attaques par usurpation IP ?

Usurpation IP

Afin d'obtenir l'accès, les intrus créent des paquets avec des adresses IP source usurpées. Cela exploite les applications qui utilisent l'authentification basée sur les adresses IP et conduit à un accès utilisateur non autorisé et éventuellement racine sur le système ciblé. Les services rsh et rlogin en sont des exemples.

Il est possible d'acheminer des paquets via des pare-feu de routeur de filtrage s'ils ne sont pas configurés pour filtrer les paquets entrants dont l'adresse source se trouve dans le domaine local. Il est important de noter que l'attaque décrite est possible même si aucun paquet de réponse ne peut atteindre l'attaquant.

Voici des exemples de configurations potentiellement vulnérables :

• Pare-feu proxy où les applications proxy utilisent l'adresse IP source pour l'authentification

• Routeurs vers des réseaux externes qui prennent en charge plusieurs interfaces internes

• Routeurs avec deux interfaces qui prennent en charge la création de sous-réseaux sur le réseau interne

Atténuation

Le protocole uRPF (Unicast Reverse Path Forwarding) protège contre l’usurpation d’adresse IP (un paquet utilise une adresse IP source incorrecte pour masquer sa source réelle) en s’assurant que tous les paquets ont une adresse IP source qui correspond à l’interface source correcte conformément à la table de routage.

Normalement, l'appliance de sécurité examine uniquement l'adresse de destination lorsqu'elle détermine où transférer le paquet. Le protocole RPF monodiffusion demande à l'appliance de sécurité d'examiner également l'adresse source. C'est pourquoi il est appelé Reverse Path Forwarding. Pour tout trafic que vous souhaitez autoriser via l'appliance de sécurité, la table de routage de l'appliance de sécurité doit inclure une route vers l'adresse source. Pour plus d'informations, consultez RFC 2267.

Remarque : le :- %PIX-1-106021: Le message Deny protocol reverse path check from src_addr to dest_addr on interface int_name log s'affiche lorsque la vérification du chemin inverse est activée. Désactivez la vérification du chemin inverse avec la commande no ip verify reverse-path interface (nom de l'interface) afin de résoudre ce problème :

no ip verify reverse-path interface (interface name)

Pour le trafic externe, par exemple, l'appliance de sécurité peut utiliser la route par défaut pour satisfaire la protection RPF de monodiffusion. Si le trafic entre à partir d'une interface externe et que l'adresse source n'est pas connue de la table de routage, l'appliance de sécurité utilise la route par défaut pour identifier correctement l'interface externe comme interface source.

Si le trafic entre dans l'interface externe à partir d'une adresse connue de la table de routage, mais associée à l'interface interne, l'appliance de sécurité abandonne le paquet. De même, si le trafic entre dans l'interface interne à partir d'une adresse source inconnue, l'appliance de sécurité abandonne le paquet parce que la route correspondante (la route par défaut) indique l'interface externe.

Unicast RPF est implémenté comme indiqué :

• Les paquets ICMP n'ont pas de session, donc chaque paquet est vérifié.

• UDP et TCP ont des sessions, de sorte que le paquet initial nécessite une recherche de route inverse. Les paquets suivants arrivant pendant la session sont vérifiés à l'aide d'un état existant maintenu dans le cadre de la session. Les paquets non initiaux sont vérifiés pour s'assurer qu'ils arrivent sur la même interface que celle utilisée par le paquet initial.

Afin d'activer Unicast RPF, entrez cette commande :

hostname(config)#ip verify reverse-path interface interface_name

Exemple :

Comme l'illustre cette figure, le PC pirate envoie une requête au serveur d'applications 10.1.1.10 en envoyant un paquet avec une adresse IP source falsifiée 10.1.1.5/24, et le serveur envoie un paquet à l'adresse IP réelle 10.1.1.5/24 en réponse à la requête. Ce type de paquet illégal attaque à la fois le serveur d'applications et l'utilisateur légitime sur le réseau interne.

Unicast RPF peut empêcher les attaques basées sur l'usurpation d'adresse source. Vous devez configurer le uRPF dans l'interface externe de l'ASA comme indiqué ici :

ciscoasa(config)#ip verify reverse-path interface outside

Identification D'Usurpation Utilisant Des Messages Syslog

L'appliance de sécurité continue de recevoir des messages d'erreur Syslog comme indiqué. Cela indique des attaques potentielles utilisant des paquets usurpés ou pouvant se déclencher en raison d'un routage asymétrique.

1. %PIX|ASA-2-106001: Inbound TCP connection denied from IP_address/port 
   to IP_address/port flags tcp_flags on interface interface_name
   

   Explication

   C'est un message lié à la connexion. Ce message se produit lorsqu'une tentative de connexion à une adresse interne est refusée par la stratégie de sécurité définie pour le type de trafic spécifié. Les valeurs possibles de tcp_flags correspondent aux indicateurs de l'en-tête TCP qui étaient présents lorsque la connexion a été refusée. Par exemple, un paquet TCP pour lequel aucun état de connexion n'existe dans l'appliance de sécurité est arrivé et il a été abandonné. Les tcp_flags dans ce paquet sont FIN et ACK.

   Les indicateurs tcp_flags sont les suivants :

   • ACK : le numéro d'accusé de réception a été reçu.

   • FIN : les données ont été envoyées.

   • PSH : le récepteur a transmis des données à l'application.

   • RST : la connexion a été réinitialisée.

   • SYN : les numéros d'ordre ont été synchronisés pour démarrer une connexion.

   • URG : le pointeur urgent a été déclaré valide.

   Il y a de nombreuses raisons pour que la traduction statique échoue sur le PIX/ASA. Cependant, une raison courante est que l'interface de zone démilitarisée (DMZ) est configurée avec le même niveau de sécurité (0) que l'interface externe.

   Afin de résoudre ce problème, attribuez un niveau de sécurité différent à toutes les interfaces

   Référez-vous à Configuration des paramètres d'interface pour plus d'informations.

   Ce message d'erreur apparaît également si un périphérique externe envoie un paquet IDENT au client interne, qui est abandonné par le pare-feu PIX. Référez-vous à Problèmes de performances PIX causés par le protocole IDENT pour plus d'informations

2. %PIX|ASA-2-106007: Deny inbound UDP from outside_address/outside_port 
   to inside_address/inside_port due to DNS {Response|Query}
   

   Explication

   C'est un message lié à la connexion. Ce message s'affiche si la connexion spécifiée échoue en raison d'une commande outbound deny. La variable de protocole peut être ICMP, TCP ou UDP.

   Action recommandée : Utilisez la commande show outbound pour vérifier les listes sortantes.

3. %PIX|ASA-3-106014: Deny inbound icmp src interface_name: IP_address dst 
   interface_name: IP_address (type dec, code dec)

   Explication

   L'appliance de sécurité a refusé tout accès aux paquets ICMP entrants. Par défaut, tous les paquets ICMP se voient refuser l'accès, sauf autorisation spécifique.

4. %PIX|ASA-2-106016: Deny IP spoof from (IP_address) to IP_address on 
   interface interface_name.

   Explication

   Ce message est généré lorsqu'un paquet arrive à l'interface de l'appliance de sécurité qui a une adresse IP de destination de 0.0.0.0 et une adresse MAC de destination de l'interface de l'appliance de sécurité. En outre, ce message est généré lorsque l'appliance de sécurité a rejeté un paquet avec une adresse source non valide, qui peut inclure l'une des adresses suivantes ou une autre adresse non valide :

   • Réseau de bouclage (127.0.0.0)

   • Diffusion (limitée, dirigée vers le réseau, dirigée vers le sous-réseau et dirigée vers tous les sous-réseaux)

   • L’hôte de destination (land.c)

   Afin d'améliorer encore la détection des paquets usurpés, utilisez la commande icmp pour configurer l'appliance de sécurité pour rejeter les paquets avec des adresses source appartenant au réseau interne. En effet, la commande access-list a été désapprouvée et ne fonctionne plus correctement.

   Action recommandée : Déterminez si un utilisateur externe tente de compromettre le réseau protégé. Recherchez les clients mal configurés.

5. %PIX|ASA-2-106017: Deny IP due to Land Attack from IP_address to 
   IP_address

   Explication

   L'appliance de sécurité a reçu un paquet dont l'adresse IP source est égale à l'adresse IP de destination et dont le port de destination est égal au port source. Ce message indique un paquet usurpé conçu pour attaquer les systèmes. Cette attaque est appelée attaque terrestre (Land Attack).

   Action recommandée : Si ce message persiste, une attaque est peut-être en cours. Le paquet ne fournit pas suffisamment d'informations pour déterminer l'origine de l'attaque.

6. %PIX|ASA-1-106021: Deny protocol reverse path check from 
   source_address to dest_address on interface interface_name

   Explication

   Une attaque est en cours. Quelqu'un tente d'usurper une adresse IP sur une connexion entrante. Le protocole RPF de monodiffusion, également appelé recherche de route inverse, a détecté un paquet dont l'adresse source n'est pas représentée par une route et suppose qu'il fait partie d'une attaque sur votre appliance de sécurité.

   Ce message apparaît lorsque vous avez activé Unicast RPF avec la commande ip verify reverse-path. Cette fonctionnalité fonctionne sur les paquets entrant dans une interface. S'il est configuré à l'extérieur, l'appliance de sécurité vérifie les paquets qui arrivent de l'extérieur.

   L'appliance de sécurité recherche une route en fonction de l'adresse source. Si aucune entrée n'est trouvée et qu'aucune route n'est définie, ce message du journal système s'affiche et la connexion est interrompue.

   S’il existe une route, l’appliance de sécurité vérifie l’interface à laquelle elle correspond. Si le paquet est arrivé sur une autre interface, il s’agit soit d’une usurpation, soit d’un environnement de routage asymétrique comportant plusieurs chemins vers une destination. L'appliance de sécurité ne prend pas en charge le routage asymétrique.

   Si le dispositif de sécurité est configuré sur une interface interne, il vérifie les instructions de commande de route statique ou RIP. Si l'adresse source est introuvable, cela signifie qu'un utilisateur interne usurpe son adresse.

   Action recommandée : Même si une attaque est en cours, si cette fonctionnalité est activée, aucune action de l'utilisateur n'est requise. L'appliance de sécurité repousse l'attaque.

   Remarque : la commande show asp drop affiche les paquets ou les connexions abandonnés par le chemin de sécurité accéléré (asp), ce qui peut vous aider à résoudre un problème. Il indique également la date et l'heure de la dernière suppression des compteurs asp. Utilisez la commande show asp drop rpf-excluded dans laquelle le compteur est incrémenté quand ip verify reverse-path est configuré sur une interface et que l'appliance de sécurité reçoit un paquet pour lequel la recherche de route de l'IP source n'a pas donné la même interface que celle sur laquelle le paquet a été reçu.

   ciscoasa#show asp drop frame rpf-violated
     Reverse-path verify failed                                  2

   Remarque :  Recommandation : Suivez la source du trafic en fonction de l'adresse IP source imprimée dans ce message système suivant et recherchez la raison pour laquelle il envoie du trafic usurpé.

   Remarque :  Messages du journal système : 106021

7. %PIX|ASA-1-106022: Deny protocol connection spoof from source_address 
   to dest_address on interface interface_name

   Explication

   Un paquet correspondant à une connexion arrive sur une interface différente de celle où la connexion a commencé.

   Par exemple, si un utilisateur démarre une connexion sur l'interface interne, mais que l'appliance de sécurité détecte la même connexion arrivant sur une interface de périmètre, l'appliance de sécurité dispose de plusieurs chemins vers une destination. Ce routage est appelé routage asymétrique et n'est pas pris en charge sur l'appliance de sécurité.

   Un pirate peut également tenter d'ajouter des paquets d'une connexion à une autre afin d'accéder à l'appliance de sécurité. Dans les deux cas, l'appliance de sécurité affiche ce message et abandonne la connexion.

   Recommandation Action : Ce message apparaît lorsque la commande ip verify reverse-path n'est pas configurée. Vérifiez que le routage n'est pas asymétrique.

8. %PIX|ASA-4-106023: Deny protocol src 
   [interface_name:source_address/source_port] dst 
   interface_name:dest_address/dest_port [type {string}, code {code}] by 
   access_group acl_ID

   Explication

   Un paquet IP a été refusé par la liste de contrôle d’accès. Ce message s'affiche même si l'option log n'est pas activée pour une liste de contrôle d'accès.

   Recommandation Action : Si les messages persistent à partir de la même adresse source, ils peuvent indiquer une tentative d'empreinte ou d'analyse de port. Contactez les administrateurs hôtes distants.

9. %PIX|ASA-3-210011: Connection limit exceeded cnt/limit for dir packet 
   from sip/sport to dip/dport on interface if_name.

10. %ASA-4-419002: Received duplicate TCP SYN from 
    in_interface:src_address/src_port to out_interface:dest_address/dest_port with 
    different initial sequence number.

    Explication

    Ce message du journal système indique que l'établissement d'une nouvelle connexion via le périphérique pare-feu entraînera le dépassement d'au moins une des limites de connexion maximales configurées. Le message du journal système s'applique à la fois aux limites de connexion configurées à l'aide d'une commande statique et à celles configurées à l'aide de Cisco Modular Policy Framework. La nouvelle connexion ne sera pas autorisée à traverser le périphérique pare-feu tant que l'une des connexions existantes n'aura pas été interrompue, ce qui ramène le nombre actuel de connexions en dessous du maximum configuré.

    • cnt : nombre actuel de connexions

    • limit : limite de connexion configurée

    • dir : direction du trafic, entrant ou sortant

    • sip : adresse IP source

    • sport : port source

    • dip : adresse IP de destination

    • dport : port de destination

    • if_name : nom de l'interface sur laquelle l'unité de trafic est reçue, principale ou secondaire.

    Recommandation Action : Étant donné que les limites de connexion sont configurées pour une bonne raison, ce message du journal système peut indiquer une attaque DoS possible, auquel cas la source du trafic peut être une adresse IP usurpée. Si l’adresse IP source n’est pas totalement aléatoire, il peut être utile d’identifier la source et de la bloquer à l’aide d’une liste de contrôle d’accès. Dans d'autres cas, l'obtention de traces de l'analyseur et l'analyse de la source du trafic permettraient d'isoler le trafic indésirable du trafic légitime.

Fonctionnalité de base de détection des menaces dans ASA 8.x

L'appliance de sécurité Cisco ASA/PIX prend en charge la fonctionnalité appelée détection des menaces à partir des versions 8.0 et ultérieures du logiciel. Grâce à la détection de base des menaces, l'appliance de sécurité surveille le taux de paquets abandonnés et les événements de sécurité pour les raisons suivantes :

• Refus par listes d'accès

• Format de paquet incorrect (par exemple invalid-ip-header ou invalid-tcp-hdr-length)

• Limites de connexion dépassées (limites de ressources à l'échelle du système et limites définies dans la configuration)

• Attaque par déni de service détectée (par exemple, SPI non valide, échec de vérification du pare-feu dynamique)

• Les vérifications de base du pare-feu ont échoué (cette option est un taux combiné qui inclut toutes les suppressions de paquets liées au pare-feu dans cette liste à puces. Il n'inclut pas les abandons non liés au pare-feu, tels que la surcharge d'interface, les échecs de paquets lors de l'inspection des applications et les attaques d'analyse détectées.)

• Paquets ICMP suspects détectés

• Échec de l'inspection des paquets

• Surcharge d'interface

• Analyse des attaques détectées (cette option surveille les attaques d'analyse ; par exemple, le premier paquet TCP n'est pas un paquet SYN ou la connexion TCP a échoué lors de la connexion en trois étapes. La détection complète des menaces d'analyse (reportez-vous à Configuration de la détection des menaces d'analyse pour plus d'informations) prend ces informations de taux d'attaque d'analyse et agit sur elle en classant les hôtes comme attaquants et en les rejetant automatiquement, par exemple.)

• Détection de session incomplète, comme une attaque SYN TCP détectée ou aucune attaque de session UDP de données détectée.

Lorsque le dispositif de sécurité détecte une menace, il envoie immédiatement un message de journal système (730100).

La détection de base des menaces affecte les performances uniquement en cas de perte ou de menace potentielle. Même dans ce scénario, l'impact sur les performances est négligeable.

La commande show threat-detection rate est utilisée afin d'identifier les attaques potentielles lorsque vous êtes connecté à l'appliance de sécurité.

ciscoasa#show threat-detection rate
                          Average(eps)    Current(eps) Trigger      Total events
  10-min ACL  drop:                  0               0       0                16
  1-hour ACL  drop:                  0               0       0               112
  1-hour SYN attck:                  5               0       2             21438
  10-min  Scanning:                  0               0      29               193
  1-hour  Scanning:                106               0      10            384776
  1-hour Bad  pkts:                 76               0       2            274690
  10-min  Firewall:                  0               0       3                22
  1-hour  Firewall:                 76               0       2            274844
  10-min DoS attck:                  0               0       0                 6
  1-hour DoS attck:                  0               0       0                42
  10-min Interface:                  0               0       0               204
  1-hour Interface:                 88               0       0            318225

Référez-vous à la section Configuration de la détection des menaces de base du guide de configuration ASA 8.0 pour plus d'informations sur la partie configuration.

Message Syslog 733100

Message d'erreur :

%ASA-4-733100: Object drop rate rate_ID exceeded. Current burst rate 
is rate_val per second, max configured rate is rate_val; 
Current average rate is rate_val per second, max configured rate is 
rate_val; Cumulative total count is total_cnt

L'objet spécifié dans le message du journal système a dépassé le taux de seuil de rafale ou le taux de seuil moyen spécifié. L’objet peut être l’activité de rejet d’un hôte, d’un port TCP/UDP, d’un protocole IP ou de divers abandons en raison d’attaques potentielles. Il indique que le système est en danger.

Remarque : ces messages d'erreur avec résolution s'appliquent uniquement à ASA 8.0 et versions ultérieures.

1. Objet : source générale ou particulière d'un comptage de taux de perte, qui peut inclure les éléments suivants :

   • Pare-Feu

   • Paquets incorrects

   • Limite de taux

   • attaque DoS

   • abandon ACL

   • Limite de conn

   • attaque ICMP

   • Analyse

   • attaque SYN

   • Inspecter

   • Interface

2. rate_ID : débit configuré en cours de dépassement. La plupart des objets peuvent être configurés avec jusqu'à trois débits différents pour différents intervalles.

3. rate_val : valeur de débit particulière.

4. total_cnt : nombre total depuis la création ou la suppression de l'objet.

Ces trois exemples montrent comment ces variables se produisent :

• Pour une perte d'interface due à une limitation de CPU ou de bus :

  %ASA-4-733100: [Interface] drop rate 1 exceeded. Current burst rate is 1 per 
      second, 
  max configured rate is 8000; Current average rate is 2030 per second, 
  max configured rate is 2000; Cumulative total count is 3930654

• Pour une perte d'analyse due à des attaques potentielles :

  ASA-4-733100: [Scanning] drop rate-1 exceeded. Current burst rate is 10 per 
      second_
  max configured rate is 10; Current average rate is 245 per second_
  max configured rate is 5; Cumulative total count is 147409 (35 instances received)

• Pour les paquets incorrects dus à des attaques potentielles :

  %ASA-4-733100: [Bad pkts] drop rate 1 exceeded. Current burst rate is 0 per 
      second, 
  max configured rate is 400; Current average rate is 760 per second, 
  max configured rate is 100; Cumulative total count is 1938933

Action recommandée :

Effectuez ces étapes en fonction du type d'objet spécifié qui apparaît dans le message :

1. Si l'objet du message Syslog est l'un des suivants :

   • Pare-Feu

   • Paquets incorrects

   • Limite de taux

   • attaque DoS

   • abandon ACL

   • Limite de conn

   • attaque ICMP

   • Analyse

   • attaque SYN

   • Inspecter

   • Interface

   Vérifiez si le taux d'abandon est acceptable pour l'environnement en cours d'exécution.

2. Ajustez le taux de seuil de la baisse particulière à une valeur appropriée en exécutant la commande threat-detection rate xxx, où xxx est l'un de ceux-ci :

   • perte d'appel

   • abandon de paquets erronés

   • conn-limit-drop

   • désintoxication

   • fw-drop

   • icmp-drop

   • inspecter-larguer

   • interface-drop

   • menace d'analyse

   • syn-attack

3. Si l'objet dans le message Syslog est un port TCP ou UDP, un protocole IP ou une suppression d'hôte, vérifiez si le taux de suppression est acceptable pour l'environnement en cours d'exécution.

4. Ajustez le taux de seuil de l'abandon particulier à une valeur appropriée en exécutant la commande threat-detection rate bad-packet-drop. Référez-vous à la section Configuration de la détection de menace de base du Guide de configuration d'ASA 8.0 pour plus d'informations.

Remarque : si vous ne souhaitez pas que l'avertissement de dépassement du taux de baisse s'affiche, vous pouvez le désactiver en exécutant la commande no threat-detection basic-threat.

Informations connexes

• Page d'assistance des appareils de sécurité adaptatifs Cisco 5500
• Page de support Cisco 500 gamme PIX
• Définition de stratégies par rapport aux attaques par déni de service TCP SYN
• Bulletin d'atténuation appliquée Cisco : Identification et réduction de l'exploitation des vulnérabilités de déni de service dans le module de commutation de contenu
• Bulletin d'atténuation appliquée Cisco : Identification et réduction de l'exploitation des vulnérabilités multiples dans le module de services de pare-feu et d'appareils Cisco PIX et ASA
• Assistance et documentation techniques - Cisco Systems