Anti-Bot looking at inbound traffic on external interface?

[Mike_Jensen]

I am under the impression that the Anti-Bot blade looks at traffic leaving internal networks in an attempt to find internal hosts that have already been compromised and the internal network is defined by the settings for interfaces in the topology, "Leads to: Internet (External) , internal, etc.
I recently enabled ABOT and am surprised to see log cards for udp/53 DNS query for a C&C site requests being detected by ABOT coming in on a external interface as shown in the screen shot.

 

The interface bond1.1027 is indeed set to "External"

 

The only thing I can think of to explain this is that my public IP in the log card is used as a static NAT in a host object for a host that lives off of a "Internal" interface.

Is that why Anti-Bot picked this up?

The internal host that 4.3.x.x NAT's to does indeed accept and service DNS requests from the internet.

[PhoneBoy]

In R81 and above, I believe it also looks at stuff coming in from external as well.

[Mike_Jensen]

I should have specified.... I am running 80.30

[Timothy_Hall]

I'm pretty sure the up arrow next to the bond interface in the log card indicates the packet was detected by AB leaving that interface outbound, not coming into it.  So if that interface is declared External that would indeed be considered outbound traffic and fall under the purview of Anti-Bot.

[Mike_Jensen]

Hi Tim,

I see what you mean about the up arrow and that makes sense.  What still doesn't make sense to me is my hosts IP is the 4.30.x.x.  If this is outbound traffic shouldn't the 4.30.x.x IP show as the source?

Thank you!

[Mike_Jensen]

I had a similar scenario this morning this time for a Backdoor.Win32.Ghost.E ABOT protection.  Per the log card the source is external and the destination is my organizations public IP 4.30.x.x which of course is on a external interface.

Basically from the source and destination in the log card this looks like external traffic coming into my organization.

 This time I was able to download a pcap from the Forensic Details:

It appears there was a NAT translation as the 172.19.x.x IP is a host object of mine that has a static NAT in it for the 4.30.x.x IP.

Is the "offending packet" the first one listed in the PCAP that caused the ABOT log?  If it is this shows the traffic did indeed originate from the public internet and came into a external interface.

With that being said the PCAP does show my 172.19.x.x IP replying to the alleged malicious host so is packet # 2 the offending packet?

 

 

[Timothy_Hall]

I think this strangeness you are seeing may be caused by how different applications behave.  Some are "client talks first" and some are "server talks first".  An example of "server talks first" is FTP, once the TCP 3-way handshake is complete the server presents a 220 banner first then the client replies with USER.  An example of "client talks first" is HTTP, where after the TCP 3-way handshake is complete the client issues an HTTP verb to the server and the server responds.  Perhaps this detection happened in a "server talks first" scenario where your client initiated the connection, but there wasn't any data to make the detection until the server talked back first inbound.

A little-known fact covered in my 2021 IPS/AV/ABOT Video Series is that if the TP action is Detect and "Packet Capture" is set (as in your case), you can get up to 100KB of packets in the capture if the connection continues, whereas you will normally only get one offending packet if the action is Prevent.  This behavior when Detect is set gives additional context, but can make figuring out the offending packet a bit tougher.  See here for more reading: sk148492: Packet capture for IPS logs with "Prevent" or "Detect" actions does not show the desired n...

Given what I've stated above, does what you are seeing in the packet capture make more sense now?

[Mike_Jensen]

Hi Tim,

Yes, that makes sense with the FTP server talk first example.  What about DNS queries?  From what I understand that is a "client talk first", right?

I replicated this scenario in my lab and ABOT performs the same way.  If I make a DNS query to a known malicious site to a DNS server that sits behind my lab gateways Check Point's ABOT "prevents" it.  In my lab I changed ABOT from detect to prevent and I do see the difference in fewer packets captured.  In this DNS query example I now only see 1 packet which must be the offending packet.  The pcap shows the offending packet with a source IP of the host "outside/external" to my gateways.

[Timothy_Hall]

DNS is indeed a client talks first protocol and detection can happen on the very first packet because there is no handshaking with UDP, and it sounds like you are seeing what you should in regards to how many packets are captured with Detect vs. Prevent.

[Mike_Jensen]

Why would a inbound DNS request on a external interface be looked at by Anti Bot?

[jthomp26]

@Timothy_Hall Does AB ever inspect inbound DNS traffic? I think I see what Mike is talking about as the source/destination IP addresses make it seem like this is external --> internal traffic.

[Timothy_Hall]

If an internal client makes a DNS lookup request for a site name and the outbound DNS request does not run afoul of Domain Reputation, the IP provided in the inbound DNS response would then need to be checked by Anti-bot for IP reputation.  Or perhaps Anti-bot waits until the actual outbound connection request to the resolved IP, and then applies the IP Reputation check at that point?  This latter scenario is heavily implied in the "Reputation Layer" section of the ATRG for AV/ABOT, but I'm not 100% sure about this and we'll probably need someone in R&D to comment.  Tagging @PhoneBoy 

[PhoneBoy]

It would make sense that'd we catch the DNS reply before we make the actual IP connection.
Maybe @TP_Master or someone on the team knows for sure.

[Mike_Jensen]

Hi Damon, it's not the reply Check Point is catching.  My system actually never sends a reply.  It is the initial DNS query inbound that Check Point is catching.

[PhoneBoy]

Then...you have your answer 😉

[Mike_Jensen]

I eventually opened a TAC case for this to investigate the ABOT traffic flow.  In summary per TAC ABOT doesn't care about what interfaces are set as internal or external and all that matters is the Threat Prevention Rule Base.  If I want to have ABOT look at traffic leaving my internal networks only I would have to configure the Threat Prevention Rule Base accordingly.

[Timothy_Hall]

Interesting, thanks for the follow-up.