Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 42 subscribers
  • Views 1843 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.
  • 0 in reply to RichBaldry

    you provided a real good answer!

    Understandable, reasonable, leaving no open questions!

    Thank you very much!

  • +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 LuCar Toni

    it does

       Line 1542: 10:27:43.207892 tun0, IN: IP CLIENT-IP.61052 > XG-IP.53: 8+ A? for718-whileteam.heldlead.com. (47)

    support case?

  • 0 in reply to LHerzog

    And XG would detect the same, if it would receive the same request, which it does not. If you disable this option for a test, it should detect this. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Hi,

    thanks. I removed the internal domain from the log above. Thanks for pointing this out.

    This is normal behaviour of Windows DNS to add internal Domain on the first attempt.

    This is not a problem here. The upstream firewall only receives the real domain without internal domain added.

    The ATP on upstream SG is only for for718-whileteam.heldlead.com

  • 0 in reply to LHerzog

    I guess i see the problem. The Windows client is altering the DNS requests, which result in a skip of the detection. You see, your own Domain is added in the initial request. Hence the ATP is not able to figure out, what domain this is. 

    https://serverfault.com/questions/74067/windows-appending-domain-suffix-to-all-lookups

    If you disable this, ATP on XG should be able to block this. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    it does

    	Line 1506: 10:27:43.087747 tun0, IN: IP CLIENT-IP.61050 > XG-IP.53: 6+ A? for718-whileteam.heldlead.com.internaldomain. (62)
	Line 1536: 10:27:43.155323 tun0, IN: IP CLIENT-IP.61051 > XG-IP.53: 7+ AAAA? for718-whileteam.heldlead.com.internaldomain. (62)
	Line 1542: 10:27:43.207892 tun0, IN: IP CLIENT-IP.61052 > XG-IP.53: 8+ A? for718-whileteam.heldlead.com. (47)
	Line 1543: 10:27:43.207994 lag0, OUT: IP XG-IP.49721 > UPSTREAM-SG-IP.53: 43942+ A? for718-whileteam.heldlead.com. (47)
	Line 1544: 10:27:43.207996 PortA3, OUT: IP XG-IP.49721 > UPSTREAM-SG-IP.53: 43942+ A? for718-whileteam.heldlead.com. (47)
	Line 1548: 10:27:43.293823 tun0, IN: IP CLIENT-IP.61053 > XG-IP.53: 9+ AAAA? for718-whileteam.heldlead.com. (47)
	Line 1549: 10:27:43.293916 lag0, OUT: IP XG-IP.27974 > UPSTREAM-SG-IP.53: 20913+ AAAA? for718-whileteam.heldlead.com. (47)
	Line 1550: 10:27:43.293919 PortA3, OUT: IP XG-IP.27974 > UPSTREAM-SG-IP.53: 20913+ AAAA? for718-whileteam.heldlead.com. (47)

  • 0 in reply to LHerzog

    Can you verify on a tcpdump level, this DNS request actually is proceeded by XG? Because it should shown on XG as well and prevent this. 

    Using tcpdump -ni any port 53 and redo the nslookup. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    ah ok, the detailed view.

    no, does not have an entry for this dst IP

    i changed ATP on XG from untrusted to scan all.

    then did a nslookup towards the XG to resolve for718-whileteam__heldlead__com

    > for718-whileteam.heldlead.com
    Server:  XG
    Address:  XG-IP

    *** for718-whileteam.heldlead.com wurde vonXG nicht gefunden: Non-existent domain.

    XG does not log an ATP alert at all.

    upstream SG does ATP block but does not even log a source IP in live view. In log file I see

    2021:04:12-10:08:36 fw-320-2 named[3300]: rpz: client @0x8d19e88 XG-IP#19900 (for718-whileteam.heldlead.com): view default: rpz IP NXDOMAIN rewrite for718-whileteam.heldlead.com via 32.198.117.54.198.rpz-ip.rpz

    This is overall a real strange ATP situation

  • 0 in reply to LHerzog

    Detailed View or advanced View is the other view in logviewer on the left site in your screenshot. 

    It will show all the syslog entries. 

    Usually i recommend to activate inspect all content, if the appliance has enough performance to do so. 

    __________________________________________________________________________________________________________________

Unfiltered HTML