My next class:

DNS Firewalling with MISP

Published: 2019-01-22. Last Updated: 2019-01-22 06:51:19 UTC
by Xavier Mertens (Version: 1)
3 comment(s)

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

Keywords: DNS Firewall IOC MISP
3 comment(s)
My next class:

Comments

I wrote a blog about this back in 2013. http://www.bicetech.com/bbice-blog/rpz/ In addition to filtering obviously bad stuff, I use RPZ to block any hostname resolving to a known malicious or compromised IP (there's many lists of those too). This may be too aggressive for some but you can always whitelist also. I STRONGLY recommend making/testing whitelist rules too. :-)

Also, I block a ton of dyn-dns service domains. In the past 5 or so years I've been doing that, I've only run across a few dyn-dns hostnames that were actually legit that I needed to whitelist. BTW, that's a good indicator to add to your "start of the day" dashboard (grin). And speaking of logging, one should also log hits on your RPZ filters. Show the top IPs hitting your RPZ filters and what they're querying for and you'll find bots and other malware.

Lastly, I'd highly recommend using more than one rpz zone. For instance, I put all the web-tracking-sleazy-marketing-adware stuff in one zone by itself. That way when I'm later sifting through my RPZ logs it's easy to exclude the hits caused by your spam filters or your spyware/adware/marketing track-me-everywhere stuff out and see only the more interesting probably-malware hits on your RPZ filters.

And log, log, log! Those RPZ logs are intrusion-detection gold!
On a related note... I made a demo showing off my log server (kibana + elasticsearch + a syslog daemon I wrote in NodeJS) and towards the end I show an example of how I one of my dashboards showing RPZ hits made a bot infection obvious (one that opendns and bluecoat didn't block until several hours AFTER the infection happened). If you think this might be interesting you can see it (and whole pile of blog posts I wrote) here: https://www.minds.com/newsfeed/783558588600688656?referrer=linuxgeek
this is great info, thanks for writing it. see also:

https://dnsrpz.info/

Diary Archives