NAT source mal configurée et attaques terrestres

NAT source mal configurée et attaques terrestres

46931
Created On 09/25/18 19:21 PM - Last Modified 05/31/23 21:36 PM


Resolution


Demande client

Dans les scénarios où un administrateur configure la traduction de destination sur plusieurs destinations sans spécifier de zone source, le NAT source peut se retrouver en bas, agissant comme une règle NAT par défaut qui exécute la traduction source sur le trafic qui n'a pas correspondent aux règles NAT de destination ci-dessus.

Dans de tels cas, la traduction de source est faite sur le trafic qui va à externe/méfiance/public. Si cette source NAT a été configurée de sorte que la zone source soit any et que la zone de destination soit externe/non-Trust/public, le trafic qui atteint cette règle inclut le trafic de la non-confiance étant également la source traduite.

Exemple d'une règle NAT ouverte:

Cela a un effet négatif sur le trafic connu ou de confiance, car en dehors du trafic qui atteint l'Internet, il existe d'autres connexions de trafic de confiance qui va frapper cette source NAT règle.

Voici quelques exemples de trafic qui correspondrait à cette stratégie:

  • UN ping à l'interface externe ou l'ip publique du pare-feu
  • VPN IPSec, négociations de phase 1/IKE à partir du pare-feu homologue

Dans les deux cas, le trafic se heurte à la règle NAT source provoquant une traduction source à appliquer au trafic. La source sera traduite à l'ip publique du pare-feu, et maintenant le pare-feu verrait ce trafic comme ayant la même source et IP de destination. Le pare-feu va immédiatement laisser tomber ce trafic, considérant qu'il s'agit d'usurpation d'adresse IP.

Étant donné que c'est l'une des nombreuses anomalies qui pourraient être observées en raison d'une règle de nat Open source suivantes sont les étapes pour dépanner et identifier le problème.


Étapes de dépannage

Pour confirmer que le trafic est en cours de chute en raison de l'usurpation IP, exécutez la commande suivante et vérifiez les compteurs spécifiquement les compteurs de dépôt.

Un filtre peut être configuré et appliqué aux compteurs pour filtrer pertinent. Pour créer un filtre sur l'interface CLI, reportez-vous aux étapes suivantes.

> Debug dataplane paquet-diag Show Setting

Cette commande affiche les options de filtrage et de journalisation en cours qui sont définies. Veuillez vérifier qu'aucun filtre n'a déjà été défini.

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

Réglage de paquet de diagnostic :

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

Filtre de paquets

  Activé: non

  Paquet préalablement analysé match : aucun

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

Exploitation forestière

  Activé: non

  Log-Throttle: non

  Aggregate-to-single-file: Oui

  Taille du fichier de sortie: 113775 de 10485760 octets

  Caractéristiques :

  Compteurs:

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

Capture de paquets

  Activé: non

  Snaplen: 0

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

Si une sortie différente est visible, utilisez la commande suivante pour effacer les filtres déjà existants.

> débogage dataplane paquets-diag tout effacer

Après cette commande, nous pouvons définir le filtre comme suit pour le scénario IPSec. (remplacez 1.1.1.1 par l'adresse IP de l'homologue et 2.2.2.2 par l'adresse IP publique du pare-feu local)

> Debug dataplane Packet-diag Set filtre match source 1.1.1.1 destination 2.2.2.2 destination-port 500 protocole 17 (pour utiliser le protocole ping 1 pour le scénario ping et ne mentionnent aucun port de destination)

> Debug dataplane paquet-diag Show Setting

La sortie doit ressembler à ce qui suit:

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

Réglage de paquet de diagnostic :

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

Filtre de paquets

  Activé: non

  Paquet préalablement analysé match : aucun

  Index 1:1.1.1.1 [0]-> 2.2.2.2 [500], proto 17

           pénétration-interface toute, évacuation-interface tout, exclure non IP

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

Exploitation forestière

  Activé: non

  Log-Throttle: non

  Aggregate-to-single-file: Oui

  Taille du fichier de sortie: 113775 de 10485760 octets

  Caractéristiques :

  Compteurs:

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

Capture de paquets

  Activé: non

  Snaplen: 0

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

Dans l'interface graphique, les filtres peuvent être configurés sous > Monitor > capture de paquets > filtres

Configurez l'ip source comme IP de l'homologue, IP de destination comme IP publique du pare-feu, le protocole en tant que 17 et le port de destination comme 500.

Après avoir réglé le filtre et initié le trafic IPSec ou ping et suivez la commande ci-dessous et vérifiez les gouttes dues à l'attaque terrestre.

> Show compteur global filtre paquet-filtre Oui Delta Oui gravité baisse

Si le compteur suivant apparaît à chaque fois que vous exécutez la commande ci-dessus, puis le pare-feu est de laisser tomber le trafic en raison de l'usurpation d'adresse IP.

flow_policy_nat_land Drop session Setup: source NAT IP allocation résultat en attaque terrestre

Résolution

Palo Alto Networks recommande fortement de spécifier des zones lors de la configuration des règles de NAT source car elle réduit le risque d'exécution de la traduction sur des paquets qui ne devraient pas être traduits.

propriétaire : dpalani



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClW9CAK&lang=fr&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language