If IOC’s are very useful to “detect” suspicious activities, why not use also them to “prevent” them to occur? DNS firewalling can be an efficient way to prevent your users to visit malicious online resources. The principle of DNS firewalling is not new, it is used for a long time to fight against spammers. Services lile SpamHaus[1] provide RPZ feeds. RPZ means “Response Policy Zone” and the principle is to allow a nameserver to reply with an alternate responses to some clients queries.

Based on the fact that users (or malware) use DNS to access malicious resources, why not  configure your DNS resolver to prevent the resolution of domains used for such purposes? But be careful, playing with DNS can have huge impacts on your users or your production systems. That’s why it is mandatory to reduce the risk of false positive alerts! That’s why I prefer to rely on my local source of domains than public resources. Why not use MISP[2] in this case? MISP is the perfect tool to share malware informations and the application allows you to implement sufficient granularity to export only relevant information that YOU control. Examples:

• IOC’s can be tagged with a ’to_ids’ flag
• IOC’s can be tagged with relevant flags
• IOC’s can be filtered against warning list to prevent export of sensitive information like the Alexa top-1M and many more

The implementation is simple. Let’s assume that you already have your own bind resolver installed in /etc/named.

The first step is to generate a RPZ file with our malicious domains. I wrote a quick script to automate this:

# cat -n /usr/local/bin/misp-rpz-export.sh
     1  #!/bin/bash
     2  RPZFILE=/etc/bind/misp.rpz
     3  curl \
     4   -s \
     5   -o $RPZFILE.new \
     6   -d '{"returnFormat":"rpz","last":"30d","to_ids":1}' \
     7   -H "Authorization: <redacted>" \
     8   -H "Accept: application/json" \
     9   -H "Content-type: application/json" \
    10   -X POST https://<redacted>/attributes/restSearch \
    11  && ( for i in {9..0}
    12          do
    13                  mv $RPZFILE.$i $RPZFILE.$((i+1)) 2>/dev/null
    14          done
    15          mv $RPZFILE $RPZFILE.0 2>/dev/null
    16          mv $RPZFILE.new $RPZFILE
    17  ) \
    18  && /usr/sbin/rndc reload

This script exports RPZ data using the MISP REST API, it rotates the file to keep an history (10 backups) and ask bind to reload its configuration.

The generate zone file must be a primary zone in our bind configuration:

zone "misp.rpz" {
        type master;
        file "/etc/bind/misp.rpz";
};

Now define the response policy:

options {
        response-policy {
                zone "misp.rpz" policy cname malicious-domain-detected.<redacted>;
        };
};

For all domains present in the RPZ file, we ask bind to use the CNAME malicious-domain-detected.<redacted>. It’s up to you to decide the action to take. You could resolve this CNAME to 127.0.0.1 or create a virtual host with a default page with detailed information to your users (why they have been blocked).

Of course, we need to track malicious activities. It’s a good idea to generate a new log file:

logging {
    channel rpz_log {
                file "/mnt/named/rpz.log" versions 4 size 100m;
                severity info;
                print-category yes;
                print-severity yes;
                print-time yes;
        };
        category rpz { rpz_log; };
}

Reload bind and let’s test:

# host financialtimesguru.com
financialtimesguru.com is an alias for malicious-domain-detected.<redacted>.
malicious-domain-detected.<redacted>is an alias for malicious-domain-detected.<redacted>.
malicious-domain-detected.<redacted> has address 127.0.0.1

Note that, in another setup, I'm replying to the suspicious DNS requests with the IP address of a DShield honeypot to capture the interesting HTTP traffic. In this case, you can mix protection and hunting!

[1] https://www.spamhaus.org/
[2] https://www.misp-project.org/

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key