DNS Firewalling with MISP
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
Comments
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!
Anonymous
Jan 22nd 2019
5 years ago
Anonymous
Jan 22nd 2019
5 years ago
https://dnsrpz.info/
Anonymous
Jan 26th 2019
5 years ago