Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Mike_Jensen
Advisor

Anti-Bot looking at inbound traffic on external interface?

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.

log card 11-17.png

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

bond interface.png

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.

 

 

0 Kudos
16 Replies
PhoneBoy
Admin
Admin

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

0 Kudos
Mike_Jensen
Advisor

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

0 Kudos
Timothy_Hall
Champion
Champion

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Mike_Jensen
Advisor

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!

0 Kudos
Mike_Jensen
Advisor

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.

log card 11-19-2021.png

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

pcap 11-19-2021.png

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?

 

0 Kudos
Timothy_Hall
Champion
Champion

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?

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Mike_Jensen
Advisor

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.

0 Kudos
Timothy_Hall
Champion
Champion

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Mike_Jensen
Advisor

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

0 Kudos
jthomp26
Employee
Employee

@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.

0 Kudos
Timothy_Hall
Champion
Champion

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 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
PhoneBoy
Admin
Admin

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.

0 Kudos
Mike_Jensen
Advisor

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.

0 Kudos
PhoneBoy
Admin
Admin

Then...you have your answer 😉

0 Kudos
Mike_Jensen
Advisor

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.

0 Kudos
Timothy_Hall
Champion
Champion

Interesting, thanks for the follow-up.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events