Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 1615 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

XG does not detect ATP that has been detected by UTM

LHerzog

We just received an alert from an upstream SG UTM Firewall that the downstream XG firewall was blocked by SG due to ATP.

This is DNS traffic towards namecheap DNS servers. Probably for for718-whileteam__heldlead__com (__ is a dot .)

2021:04:09-13:11:07 fw-320-2 afcd[5066]: id="2022" severity="warn" sys="SecureNet" sub="packetfilter" name="Packet dropped (ATP)" srcip="XG-firewall-IP" dstip="198.54.117.254" fwrule="63001" proto="17" threatname="C2/Generic-A" status="1" host="198.54.117.198" url="-" action="drop"
2021:04:09-13:12:20 fw-320-2 afcd[5066]: id="2022" severity="warn" sys="SecureNet" sub="packetfilter" name="Packet dropped (ATP)" srcip="XG-firewall-IP" dstip="198.54.117.253" fwrule="63001" proto="17" threatname="C2/Generic-A" status="1" host="198.54.117.198" url="-" action="drop"

This is probably traffic generated by the XG trying to resolve some Host for internal requests trough the namecheap DNS servers.

My questions:

1. why is XG doing something that SG says is insecure? It should block malware DNS itself like SG does. ATP on XG is enabled (Mode: Inspect untrusted content. For optimal performance, inspect only untrusted content.)

2. now please tell me how to find the originating internal IP in the XG logs that tries to DNS trough XG? This in invisible in firewall logs. Or is there a hidden DNS resolver log on XG?



This thread was automatically locked due to age.
Parents
  • +2

    The problem here is due to the exact point in the DNS lookup when ATP is triggering.

    ATP can block on any one of the following:

    - Domain name

    - Full URL

    - IP Address

    In this case, the domain name is not in our ATP data as a malicious domain, but the IP address 198.54.117.198 is.

    What is happening is as follows:

    1. The client sends a DNS request for the bad domain name to the XG Firewall. The request contains the domain name, but obviously has no reference to its IP address.

    2. The XG Firewall receives the request, checks the requested domain against the list. When it finds that the domain is not listed, it forwards the request to the appropriate name server for the host (198.54.117.254) as usual.

    3. The SG sees the outbound request and checks the domain name. It also finds that the domain is not listed and lets the request pass.

    4. The nameserver receives the request and sends a response packet. The response packet includes the IP Address 198.54.117.198

    5. The SG sees the response and looks up the IP address in the ATP data. It finds the IP address is listed, and blocks the response from proceeding to the XG.

    6. The XG firewall receives no valid response to the query. It they retries the request by sending it to an alternate DNS server - 198.54.117.253 - the same sequence of events happens.

    At no point in any of this does the XG get to see the DNS response containing the suspect IP address. The XG therefore cannot raise an ATP alert.

    In answer to your question 2:

    If the SG did not intercept this request, then ATP on the XG would detect it. In this case you would be able to see the original requesting IP address in the Advanced Threat logs. However, XG does not log DNS requests by default unless Advanced Threat Protection detects something. 

  • 0 in reply to RichBaldry

    you provided a real good answer!

    Understandable, reasonable, leaving no open questions!

    Thank you very much!

Reply Children
No Data
Unfiltered HTML