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

INDICATOR-COMPROMISE and other IPS checks of DNS: Are they unwise

There have been multiple posts about the IPS alarms for suspicious DNS queries, especially alarms that occur when a lookup is attempted on a free-registration domain like .TK or .ML

The logic of DNS blacklisting makes sense:   It is easier to block a DNS name or name prefix, than it to block all possible IP addresses and ports that may be referenced if the DNS lookup succeeds.

UTM IPS has options for ALERT or DROP.   Alert does nothing to prevent the threat from detonating, so the instinctive decision is to configure it to Block.   But blocking a DNS query is very different from blocking other traffic.   Anytime IPS blocks a packet, the initiator experiences a timeout condition.   For normal traffic, this causes the client to conclude that the target machine is not working.   For a DNS query, silence will cause the initiator to conclude that the DNS server is down, rather than concluding that the target system is down.   

When a client concludes that a DNS server is down, the usual behavior is to change to a secondary DNS server and try again.   This query may also be blocked.   So the net result is to increase unnecessary network traffic, and to move DNS queries from a most-preferred server to a less-preferred server.   The less-preferred server may have lower performance, so overall network performance may be hindered.   I can imagine a situation where a client exhausts all of its DNS options, and quits trying to resolve any DNS name, although I have not seen this occur.   Whether it can occur or not is probably dependent on the rate of failed lookups and the implementation details of your DNS clients. 

What is needed is for the client to get a negative result (unknown DNS name), so that it stops trying to reach that server, rather than a result which incorrectly suggests a DNS problem.   The Quad9.org service purports to do this, although I have not used it yet.   Norton DNS uses a different approach - it returns a Norton honeypot IP address for blacklisted DNS lookups.   Web traffic port 80 receives a Norton block message, while all other ports are unresponsive.

Until and unless UTM DNS can behave like Quad9 or Norton, I think it is wise to set the IPS rules for Miscellaneous Servers... DNS to either Alert or Disabled, and risky to choose Block.



This thread was automatically locked due to age.
  • I don't feel comfortable disabling all of the DNS rules.  Here's a link to the Snort rules as used by the UTM: https://lists.astaro.com/ASGV9-IPS-rules.html.  And here's the list of the 62 available DNS rules: https://lists.astaro.com/ASGV9-IPS-rules.html#241.

    The INDICATOR-COMPROMISE Suspicious DNS requests are rules 28039, 28284, 39866, 39867, 43687, 44076 & 44077 and those can be changed to Alert-only without affecting the other rules.

    I don't think you'd want to disable 44037 "INDICATOR-COMPROMISE DNS request for known malware sinkhole domain iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com - WannaCry" for example.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I guess a lot hangs on whether IPS blocks will cause a "refused" result, a "no such domain" result, or silence.   UTM behavior is apparently different when the traffic is intercepted transparently, rather than being forwarded to UTM.   Still trying to understand it all.   The rest depends on how the Windows DNS infrastructure responds to the behavior of UTM.