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

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
9 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
Collaborator

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.

New 2021 IPS/AV/ABOT Self-Guided Video Series
now available at http://www.maxpowerfirewalls.com
0 Kudos
Mike_Jensen
Collaborator

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
Collaborator

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?

New 2021 IPS/AV/ABOT Self-Guided Video Series
now available at http://www.maxpowerfirewalls.com
0 Kudos
Mike_Jensen
Collaborator

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.

New 2021 IPS/AV/ABOT Self-Guided Video Series
now available at http://www.maxpowerfirewalls.com
0 Kudos
Mike_Jensen
Collaborator

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

0 Kudos