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

90% of Incoming DNS Requests Blocked, But Why?

It's become apparent that about 90% of the incoming external DNS requests are being blocked at the firewall.

Config:

Our public NS1 is a Windows 2012R2 server, running in a DMZ. There is a simple DNAT rule (Any -> DNS -> External IP ==> Change dest to NS1 server). There's also a Full NAT rule for internal requests, and an SNAT rule for zone transfers to NS3, as it's offsite.

There's a duplicate set of rules for our public NS2, which is a Linux box on a separate DMZ, and uses a different External IP. I see no difference in the rule sets or Name Server registrations (at the registrar) at all. There's a completely separate Internal DNS infrastructure, which doesn't seem to be implicated at all.

This has all worked properly for many years.

I now notice that about 90% of incoming DNS requests to NS1 are logged as Default Drop. The other 10% get forwarded by the DNAT rule to the server as usual. All requests to NS2 get rewritten and forwarded as expected.

Now I expect this is a good thing, and the firewall is protecting us. But I can't see where or why. They are shown in the Network Protection Overview as dropped packets, but not in Intrusion Prevention.There are 89 DNS amplification Attempts shown, but we're seeing about two blocked DNS queries a second.

We recently added a few countries to the Country Blocking, but packets like that show "Country Blocked", not "Default Drop" in the log.

How can I find out why all these packets are being dropped? Is it possible that one DNS Amplification Attempt corresponds to hundreds of incoming DNS request packets?



This thread was automatically locked due to age.
Parents
  • Update: I tried looking for a correlation of source addresses between the IPS log and the firewall log, but I can't see any. The IPS log reports five attempts in the last hour; the firewall log about 100 in the last minute, all from different, apparently random, addresses.

  • Salut,

    Please copy two or three lines here from the firewall log where DNS requests are blocked.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Okay here goes. It may get a bit hairy....

    The issue itself is no longer occurring -- perhaps because they've stopped hitting us, or a firewall reboot, or something else. Nevertheless, I would still like to understand.

    Because there's nothing in the live log anymore, I went to the log archives from two days ago which was when I noticed the problem. I now see there's more info in the archive than what's shown in the live log.

    Here is a single second slice with three "60001" lines (according to the documentation page here this means "no masquerade rule", but that's obviously wrong -- these 60001 lines are all listed as Default Drop in the live log -- as there is a masquerade rule and 60002 is supposed to be the code for Default Drop) and one "62019" line (corresponding, as I understand it, to "NAT Rule #19" in the live log).

    2021:05:11-15:25:42 forester ulogd[22409]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" mark="0x7c" app="124" srcmac="00:23:6a:5b:d0:ba" dstmac="00:1a:4b:ed:a6:d1" srcip="82.5.86.84" dstip="74.xxx.yyy.68" proto="17" length="59" tos="0x00" prec="0x00" ttl="245" srcport="0" dstport="53" 
    2021:05:11-15:25:42 forester ulogd[22409]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" mark="0x7c" app="124" srcmac="00:23:6a:5b:d0:ba" dstmac="00:1a:4b:ed:a6:d1" srcip="73.25.140.27" dstip="74.xxx.yyy.68" proto="17" length="59" tos="0x00" prec="0x00" ttl="245" srcport="0" dstport="53" 
    2021:05:11-15:25:42 forester ulogd[22409]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" mark="0x7c" app="124" srcmac="00:23:6a:5b:d0:ba" dstmac="00:1a:4b:ed:a6:d1" srcip="67.176.197.62" dstip="74.xxx.yyy.68" proto="17" length="59" tos="0x00" prec="0x00" ttl="245" srcport="0" dstport="53" 
    2021:05:11-15:25:42 forester ulogd[22409]: id="2000" severity="info" sys="SecureNet" sub="packetfilter" name="Packet logged" action="log" fwrule="62019" initf="eth1" srcmac="00:23:6a:5b:d0:ba" dstmac="00:1a:4b:ed:a6:d1" srcip="45.62.217.52" dstip="xxx.yyy" proto="17" length="71" tos="0x00" prec="0x00" ttl="57" srcport="58105" dstport="53" 
    

    Some things of interest:

    - The Source Port of all the dropped packets is 0

    - The length of all the dropped ones is 59,  the accepted packets have varying lengths, including some which are 59

    - They all show mark="0x7c" and app="124" -- any idea what that means?

    Now that I see the additional information in the archived log, it continues to seem to me that the firewall is doing its job. I'd guess these packets are malformed or a known attack. I'm just a little surprised that the IPS logs aren't showing them (although, as I mentioned above, maybe large groups of these lines are counted as single DNS Amplification attacks -- there were about 100 of those when I noticed the issue).

    Thanks for any thoughts, Paul



    Fixed minor typos.
    [edited by: AlatarK at 12:21 AM (GMT -7) on 14 May 2021]
  • Salut Paul,

    If you look at the definition for the DNS Service in your UTM, you'll see that it's "1:65535->53" and not "0:65535->53" which is why the packets were default dropped out of the INPUT chain (fwrule="60001") by the firewall.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Brilliant! I never would have seen that.

    Is there some history or reason behind why 0 is considered a bad source port? It does seem sketchy, but is it actually a known attack?

  • Cloudflare has a very interesting post on something similar here. It may be some kind of side effect of a different DDOS attack, possibly one that was blocked but listed only in the IPS logs as a few blocked DNS Amplification Attempts. Or it could be something entirely different -- the good news is that it was blocked by the firewall.

    Thanks for all the help,

    Paul

Reply
  • Cloudflare has a very interesting post on something similar here. It may be some kind of side effect of a different DDOS attack, possibly one that was blocked but listed only in the IPS logs as a few blocked DNS Amplification Attempts. Or it could be something entirely different -- the good news is that it was blocked by the firewall.

    Thanks for all the help,

    Paul

Children
No Data