Les journaux de menaces affichent une direction inversée/inversée pour les adresses IP source et de destination

Symptôme

La direction du trafic est inversée/renversée dans les détails du journal des menaces sur le pare-feu de Palo Alto Networks par rapport aux PCAPs réelles prises sur le pare-feu et les autres périphériques de la couche 3.

Exemple

Le PCAP (ci-dessous) sur le pare-feu de Palo Alto Networks montre:

• Source IP: 70.63.254.57
• Adresse IP de destination: 131.175.61.222

Le journal du routeur (amont) indique:

Juin 26 18:53:48: % SEC-6-IPACCESSLOGP: List vlan106-out autorisé UDP 70.63.254.57 (54473)-> 131.175.61.222 (16465), 1 paquet

• Source IP: 70.63.254.57
• Adresse IP de destination: 131.175.61.222

Le journal des menaces sur le pare-feu affiche:

• Source IP: 131.175.61.222
• Adresse IP de destination: 70.63.254.57

Remarque: la source et l'adresse IP de destination (avec leurs ports respectifs) sont inversées/inversées.

L'exemple suivant montre les détails correspondants de l'entrée des journaux de menaces:

Cause 1:

Le pare-feu de Palo Alto Networks enregistre la menace, le filtrage des données ou les événements de blocage de fichiers, y compris les logiciels espions, en fonction de l'origine du premier paquet suspect, par opposition à la direction de l'établissement de la session. Toutefois, la zone source du journal de trafic est basée sur la personne qui lance la session.

Dans l'exemple ci-dessus de détails du journal des menaces, la direction du flux est affichée comme serveur à client, comme indiqué ici:

La direction de connexion initiale est du client au serveur (70.63.254.57 à 131.175.61.222). Toutefois, dans ce cas, la menace provient du serveur, vers le client. Par conséquent, le journal des menaces montre la direction comme serveur-à-client.

Cause 2:

Une autre instance où la direction inverse peut être vu est de détecter un morceau du trafic botnet qui vient normalement d'un bot victime à un serveur C2. Cependant, certains de ces bots générer aléatoire IPS ou effectuer d'autres tentatives de P2P pour trouver le maître bot. En conséquence, s'il ya des ports UDP ouverts exposés sur le réseau, il sera observé que ces bots tentent de trouver des maîtres bot dans le réseau et l'hôte peut même pas exister. C'est la raison pour laquelle l'attaquant apparaît comme un hôte inexistant dans le réseau, parce que la signature connaît l'autre extrémité de la connexion est un bot infecté ("victime") et l'hôte inexistant est l'attaquant, parce que la communication interceptée par Palo Alto Networks Firewall est normalement d'un bot à un serveur C2.

propriétaire : ppatel