Threat Logs Show Inverted/Reversed Direction for Source and Destination IP Addresses

Threat Logs Show Inverted/Reversed Direction for Source and Destination IP Addresses

30017
Created On 09/26/18 13:55 PM - Last Modified 06/02/23 03:33 AM


Resolution


Symptom

The direction of the traffic is inverted/reversed in the threat log details on the Palo Alto Networks firewall when compared to actual PCAPs taken on the firewall and the other Layer-3 devices.

 

Example

The PCAP (below) on the Palo Alto Networks firewall shows:

  • Source IP:        70.63.254.57
  • Destination IP:  131.175.61.222

src-dest.PNG

The router (upstream) log shows:

Jun 26 18:53:48: %SEC-6-IPACCESSLOGP: list vlan106-out permitted udp 70.63.254.57(54473) -> 131.175.61.222(16465), 1 packet

  • Source IP:        70.63.254.57
  • Destination IP:  131.175.61.222

 

The Threat log on the firewall shows:

  • Source IP:        131.175.61.222
  • Destination IP:  70.63.254.57

Note:  The Source and Destination IP (with their respective ports) are inverted/reversed.

 

The following example shows the corresponding details from the Threat logs entry:

threat-log.PNG

 

Cause 1:

The Palo Alto Networks firewall logs Threat, Data filtering, or File blocking events, including spyware, based on where the first suspicious packet originates, as opposed to the session establishment direction. However, the traffic log source zone is based on who initiates the session.

 

In the above example of threat log details, the direction of the flow is displayed as server-to-client, as shown here:

 

s2c.png

The initial connection direction is from client to server (70.63.254.57 to 131.175.61.222). However, in this case, the threat originates from the server, towards the client. Therefore, the threat log shows the direction as server-to-client.

 

Cause 2:

Another instance where the reverse direction can be seen is detecting a piece of the botnet traffic that normally comes from a victim bot to a C2 server. However, some of these bots generate random IPs or perform other P2P attempts to find the bot master. As a result, if there are open UDP ports exposed on the network, it will be observed that these bots attempt to find bot masters within the network and the host may not even exist. This is the reason the attacker shows up as a non-existent host within the network, because the signature knows the other end of the connection is an infected bot ("victim") and the non-existent host is the attacker, because the communication intercepted by Palo Alto Networks firewall is normally from a bot to a C2 server.

 

owner: ppatel



Actions
  • Print
  • Copy Link

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

Choose Language