Comment identifier et combattre une attaque d'expiration TTL?

53 0 0 0

 

 

Bonjour tout le monde,

 

Je suis sûr que vous savez tous comment un en-tête IPv4 ressemble et quel est le rôle de chacun déposé là-dedans mais pour le bien de la conversation je vais prendre la liberté de décrire le champ que nous sommes intéressés par ce sujet : Le champ TTL

 

https://forum.huawei.com/enterprise/en/data/attachment/forum/dm/ecommunity/uploads/2014/1101/04/5453f0109cacf.jpg

 

 

Le champ Time to Live indique le temps maximum que le datagramme est autorisé à rester dans le système internet. La valeur TTL est remplie par l'expéditeur et est réduite à chaque point que l'en-tête internet est traité pour refléter le temps passé à traiter le datagramme. Même si aucune information locale n'est disponible sur le temps effectivement dépensé, le champ doit être décrété par 1. En fait, chaque module qui traite le datagramme spécifique, diminue le champ TTL par 1 car un datagramme de nos jours n'est pas traité en une seconde complète.

Lorsque le champ atteint la valeur zéro, le datagramme est rejeté. L'intention est de provoquer une chute des datagrammes non livrables et de lier la durée de vie maximale du datagramme.

 

Ainsi, suivant la logique décrite ci-dessus, si un dispositif de réseau (par exemple, routeur) détecte que la valeur TTL d'un paquet est 0, le dispositif rejette le paquet et envoie un ICMPv4 Type 11, message de code 0 à l'expéditeur initial entraînant un impact correspondant sur l'unité centrale. C'était juste une question de temps de sorte qu'un esprit maléfique penserait d'envoyer intentionnellement à un dispositif une grande quantité de paquets avec la valeur TTL inférieure à 1. Lors de la réception de ces paquets IP, les CPUs des dispositifs attaqués deviennent occupés à traiter les paquets et à envoyer des réponses. De cette façon, l'utilisation du CPU augmente et tous les services réseau sont affectés.

 

Que pouvons-nous faire pour découvrir et protéger le CPU ?

 

Un signal d'alarme doit être l'apparition de journaux qui décrivent que la limite CPCAR pour les paquets expirés TTL a atteint la limite :

Oct 10 2014 08:01:01+01:00 Huawei %DEFD/4/CPCAR_DROP_MPU(l)[6]:Rate of packets to cpu exceeded the CPCAR limit on the MPU. (Protocol=ttl-expired, CIR/CBS=64/10000, ExceededPacketCount=3594)

Sans aucune configuration spéciale, le dispositif générera ces alarmes lorsque la limite CPCAR décrite par la politique de défense par défaut est atteinte.

 

Après avoir reçu ce type de journaux, vous devriez vérifier combien de paquets sont envoyés au cpu ou combien sont rejetés. Vous devriez également voir si l'utilisation du cpu est affectée par eux

 

Ici, les commandes de display cpu-usage et display cpu-defend statistics sont utiles. Si l'utilisation du cpu est affectée et que le dispositif reçoit un grand nombre de paquets expirés, nous devrions envisager de prendre certaines mesures pour réduire l'impact sur le cpu et implicitement sur notre réseau.

 

<Huawei>display cpu-defend statistics all

Statistics on slot 0:

--------------------------------------------------------------------------------

Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte)  Last-dropping-time

ttl-expired                  190434811            61115743  2014-10-10 01:21

                           16574498088          6089746250

--------------------------------------------------------------------------------

 

Solutions :

 

Une autre raison de l'utilisation élevée de cpu pourrait être le grand nombre de paquets expirés TTL qui atteignent le commutateur. J'ai vu que vous avez déjà configuré et appliquez une politique de défense du cpu pour surveiller les paquets expirés et vérifier la source de l'attaque, mais vous avez pris des mesures contre elle.

La première étape devrait être de découvrir la source de l'attaque. Pour ce faire, nous pouvons configurer une politique de défense cpu pour utiliser la fonction de traçage de source d'attaque pour trouver la source ip de la plupart des paquets expirés.

 

 

cpu-defend policy p1

auto-defend enable

auto-defend attack-packet sample 4

auto-defend threshold 30//// Quand le nombre de paquets envoyés à partir d'une source dans une période spécifiée est plus grand que le seuil que le dispositif trace et enregistre la source

 

auto-defend alarm enable // une alarme est générée lorsque le seuil pour les paquets est atteint

auto-defend alarm threshold 30

auto-defend trace-type source-mac source-ip source-portvlan // trace la source mac,ip and vlan

auto-defend protocol ttl-expired  // identifier les paquets expirés

 

Lorsque vous faites cette configuration, vous devriez également faire attention au taux d'échantillonnage. Cela peut affecter l'utilisation du cpu aussi bien si elle est utilisée depuis longtemps. Un petit rapport d'échantillonnage rend le résultat de traçage de la source d'attaque plus précis, mais augmente l'utilisation du CPU.

 

Après cette configuration, vous recevrez des messages d'alarme pour vous informer lorsque le seuil est passé et vous pouvez également vérifier la source avec la commande display auto-defend attack-source.

 

Exemple :

 

Oct 10 2014 08:02:07+01:00 Huawei %SECE/4/PORT_ATTACK(l)[4]:Port attack occurred.(Slot=MPU, SourceAttackInterface=XGigabitEthernet0/0/1, OuterVlan/InnerVlan=200/0, AttackProtocol=TTL_EXPIRED, AttackPackets=36 packets per second)

 

 

<Huawei>display auto-defend attack-source

  Attack Source User Table (MPU):

  -----------------------------------------------------------------------------

  MacAddress       InterfaceName               Vlan:Outer/Inner    TotalPackets

  -----------------------------------------------------------------------------

 aaaa-bbbb-cccc   XGigabitEthernet0/0/1       200              7696

  -----------------------------------------------------------------------------

  Total: 1

 

  Attack Source IP Table (MPU):

  -----------------------------

  IPAddress        TotalPackets

  -----------------------------

  100.100.160.91   464

  -----------------------------

  Total: 1

 

Nous pouvons voir que beaucoup de paquets viennent de l’adresse mac aaaa-bbbb-cccc et je pense que nous pouvons mettre cette adresse mac dans une liste noire pour filtrer les paquets avec cette source.

 

 

L'autre chose que nous pouvons faire est de limiter l'attaque est d'appliquer une politique punitive pour rejeter les paquets de la source d'attaque identifiée pendant une période de temps. Pour ce faire, vous devez modifier la politique de défense du cpu et exécuter la commande auto-defend action deny timer [time] qui éliminera les paquets de la source d'attaque pendant une période de temps.

 

J'espère que cet article sera pratique. Merci !

 

  • x
  • Standard:

Responder

envoyer
Connectez-vous pour répondre. Se connecter | Enregistrer

Remarque : Afin de protéger vos droits et intérêts légitimes, ceux de la communauté et des tiers, ne divulguez aucun contenu qui pourrait présenter des risques juridiques pour toutes les parties. Le contenu interdit comprend, sans toutefois s'y limiter, le contenu politiquement sensible, le contenu lié à la pornographie, aux jeux d'argent, à l'abus et au trafic de drogues, le contenu qui peut divulguer ou enfreindre la propriété intellectuelle d'autrui, y compris les secrets professionnels, les marques commerciales, les droits d'auteur et les brevets, ainsi que la vie privée personnelle. Ne partagez pas votre nom d'utilisateur ou votre mot de passe avec d'autres personnes. Toutes les opérations effectuées à partir de votre compte seront considérées comme vos propres actions, et toutes les conséquences en découlant vous seront imputées. Pour plus de détails, voir « Politique de confidentialité ».
Si le bouton de la pièce-jointe n'est pas disponible, mettez à jour Adobe Flash Player à la dernière version.

Connectez-vous pour participer à la communication et au partage

S'identifier
Réponse rapide Accéder au haut de page