Dépannage des attaques DoS
Resolution
UNE attaque de déni de service (DoS) est une attaque destinée à arrêter une ressource de machine ou de réseau, la rendant inaccessible à ses utilisateurs prévus. S'Il vous plaît lire la suite sur DoS dans ce qui est une attaque de déni de service?
Cet article donne un aperçu de la façon de dépanner quelques situations dues aux attaques de pare-feu dos. Cet article suppose que vous connaissez les profils de protection dos/zone et que vous vérifiez l'utilisation des ressources:
1. Table de session complète
Cela peut être vu dans les cas où le trafic DoS est autorisé par les stratégies de pare-feu. Si l'attaquant peut trouver des IPS et des ports ouverts en utilisant les techniques de balayage IP ou de balayage de port, il peut lancer une attaque d'inondation. Dans le cas de TCP, une réponse de la victime conduit à une session d'être installé sur le pare-feu pendant 3600 secondes. Plus loin, de tels paquets SYN mèneront à la table de session pleine, provoquant ainsi le trafic légitime être affecté.
S'Il vous plaît noter que dans ces cas, le taux d'attaque d'inondation peut ou peut ne pas être élevé.
Permettre le contournement asymétrique ou la désactivation de TCP-Reject-non-syn peut aggraver la situation, car il mènera à n'importe quel paquet de TCP pour installer une session sur le pare-feu si la stratégie et le routage le permettent.
Dépannage table de session complète
- Dans ce genre de cas, la meilleure façon serait de prendre un dump de la table de session et de le parcourir. Dans la plupart des cas, une adresse IP source particulière ou une adresse IP ciblée se tiendra à l'extérieur. Utilisez la commande "Show session All" pour le même
- Vérifiez si la cible identifiée IP et le port, ou la source du trafic est valide et devrait être autorisé par le pare-feu. Si oui, pouvons-nous restreindre les règles de pare-feu.
- La plupart du temps, dans ces cas, l'atténuation est la meilleure façon. Vous devez implémenter la protection dos/profils de protection de zone pour atténuer ces cas. Mode cookie syn dans la protection contre les inondations syn peut être très utile pour traiter ces situations, car il empêchera le pare-feu d'installer une session et enverra un SYN/ACK paquet à l'attaquant. À moins que l'attaquant ne réponde avec un ACK valide, la session ne sera pas établie.
- Le seuil du mécanisme de protection contre les crues syn doit être ajusté à des exigences spécifiques après analyse du taux de connexion normal à l'IP cible.
2. Tampon de paquets/descripteurs de paquets Full
Cela peut être vu dans les attaques DoS avec un taux élevé de paquets/données. Peut être en raison du taux élevé de nouvelles connexions par seconde ou taux de paquets élevé sur les sessions existantes. Même si les connnections sont refusées, cela n'empêchera pas la mémoire tampon d'être pleine car les paquets doivent être mis en mémoire tampon et avant d'envoyer à l'dataplane pour traitement.
Comment faire pour dépanner:
- Vérifiez les onglets ACC et essayez d'utiliser des filtres personnalisés pour voir S'il y a un trafic particulier qui est exceptionnellement supérieur à L'autre trafic. Cependant ACC Tab ne fournit pas de bonnes informations contre l'attaque en cours. Raison, qu'il prend son flux à partir du résumé du trafic, les bases de données du journal de trafic et la base de données appstats.
Si l'attaque se poursuit via une session en cours, il n'aurait pas encore généré un journal de trafic.
Si l'attaque comprend de nouvelles connexions, l'onglet ACC pourrait ne pas être en mesure de montrer les sessions qui sont de toute façon obtenir échoué.
Conseils et astuces: comment utiliser l'Application Command Center (ACC)conseils & astuces: FAQ ACC Pan-OS 7,0
Tutoriel vidéo: comment utiliser l'Application Command Center (ACC) (ACC)conseils & astuces: FAQ ACC Pan-OS 7,0
Vérifiez pour toutes les sessions en direct avec plus de données que d'habitude. Utilisez l'option min-KB dans le filtre de session comme sous:
admin @ PA-200 > Show session tous les filtres min-KB 5000
--------------------------------------------------------------------------------
IDapplicationétat type Flagsrc [Sport]/zone/proto (traduit IP [port])
VSys DST [dport]/zone (traduit IP [port])
--------------------------------------------------------------------------------
10216PCOIPactiveFlowNS 10.1.1.11 [50002]/Trust/17(10.129.15.24 [61158])
vsys110.101.41.211 [4172]/Untrust(10.101.41.211 [4172])
Ce qui précède est juste un exemple, vous pouvez utiliser la valeur de min-KB comme n'importe où entre 1-1048576, soit presque jusqu'à 1G. Ceci peut fournir un aperçu des sessions avec le taux de trafic le plus haut. Cherchez quelque chose de suspect.
Vous pouvez utiliser ce qui suit pour rechercher des sessions qui surutilisent la mémoire tampon:
Identifier les sessions qui utilisent un pourcentage excessif de la mémoire tampon de paquet
Vérifiez le taux de trafic en direct sur les interfaces et découvrez quelle interface reçoit un trafic excessif. Utilisez le navigateur d'état du système Show pour le même que celui mis en évidence dans l'article suivant: Comment vérifier le débit des interfaces.
Vérifiez tous les ports appropriés selon votre configuration.
Vous devez vous concentrer sur les Rx-Bytes/s ou RX-unicast/s ou RX-multicast/s. Il s'agit du taux affiché dans la deuxième colonne lorsque vous activez le suivi à l'Aide de'Y'et'U'.
Une fois que vous avez identifié le port sur lequel le trafic d'attaque est reçu, vous devez prendre un court dépôt de paquets du trafic reçu sur ce port.
Il est recommandé de le faire sur un commutateur connecté par le port de mise en miroir du trafic que les captures de paquets peuvent être plus intensives de ressources.
Toutefois, si aucune autre option n'est disponible, activez les captures sur le pare-feu de Palo Alto Networks avec Filter comme entrée-interface comme indiqué ci-dessus et exécutez les captures pendant 10-15 secondes.
Arrêtez les captures et ouvrez avec Wireshark. Sous Wireshark regarder sous Statistics-> protocole hiérarchie ou conversations . Vérifiez la conversation sur la couche IP, couche UDP, la couche TCP et vérifier pour tout trafic qui a un nombre élevé de paquets.
Cela peut aider à identifier et à isoler l'attaquant (fiable ou non). Principalement pour la source de confiance, vous pouvez suivre l'hôte affecté et prendre des mesures.
Pour une source non fiable, vous pouvez demander l'Aide de votre FAI pour aider à prévenir la source d'attaque.