4 ms·

On my home network, using dnscrypt-proxy, I keep a whitelist of top-level domains my devices have connected to. The few new domains to resolve are forwarded to

by icefog 7y ago

On my home network, using dnscrypt-proxy, I keep a whitelist of top-level domains my devices have connected to. The few new domains to resolve are forwarded to a remote server and logged for periodic review, to update the whitelist or spot suspicious queries. So while it may not scale, it could be useful for spotting DNS C2C.

t34543 7y ago
A that’s pretty spiffy. All home built?
- icefog 7y ago
  Yes, nothing fancy. On the router, Dnsmasq and Dnscrypt-proxy with "forwarding rules" mapping domains or TLDs to desired resolvers. Any queries not matched get forwarded upstream to a server running Dnscrypt-wrapper and Dnsmasq, which logs and resolves over Tor. https://github.com/DNSCrypt/dnscrypt-proxy https://github.com/DNSCrypt/dnscrypt-proxy https://github.com/Cofyc/dnscrypt-wrapper https://github.com/Cofyc/dnscrypt-wrapper
JoshTriplett 7y ago
Does your setup distinguish between IoT-ish devices (where you don't know what software is running) and human-operated devices (which would trigger this every time they browsed to a new site)?
- icefog 7y ago
  No, but that would be fairly easy to configure - put the IoT devices on their own VLAN with dedicated DNS server. My household is small and the list of new domains visited is manageable and interesting to inspect by hand. It's definitely more of a hobby than a scalable solution, I must warn.
danesparza 7y ago
WOW - that takes a lot of discipline! How in the world would this scale on an Enterprise level (which I would assume would be the primary target)? Also -- this specifically exploits IPv6 DNS information: You're checking that manually even at your small scale?
- piffey 7y ago
  IPv6 DNS C2 is pretty easy to spot. ISMDoor for instance throws an exclamation point in its "sync" messages with the C2 which gives it away since that's an invalid character in the spec. Other C2s use IPv6 responses which are encoded which often drops them outside of the global unicast scope or returns an IPv6 address on an unassigned network. IPv6 has such a huge address space that you can check responses with something like ipv6calc and catch anomalies really fast. As far as I've analyzed there isn't a malware family using IPv6 DNS tunneling that actually attempts to be always in an address range that makes sense/valid in its responses or produce a query that couldn't be easily spotted as a blob of base-64/encrypted data. Though given that you get 16 bytes in a AAAA record to work with it would be pretty trivial to make an encoding that uses those 16 bytes to fill with English word combinations that look like valid hostnames then ensure encoded responses are always in say Google's ::/32. Edit: If you're looking to passively monitor your DNS I'm a big fan of CIRCL's D4 project that's just getting up and running. Check it out! https://www.d4-project.org/ https://www.d4-project.org/
3xblah 7y ago
I use a similar setup. The "whitelist" is a zone served by a local authoritative server like tinydns or nsd. There is no remote server. Using a local cache such as dnscache or unbound is optional. Spotting queries to an attacker-controlled domain in the tinydns logs would be easy. The tinydns logs are invaluable for determining what domains our servers and applications actually need to function... versus the ones that serve the interests of third parties for telemetry, ads, tracking, etc.

by icefog 7y ago

t34543 7y ago

A that’s pretty spiffy. All home built?

icefog 7y ago
Yes, nothing fancy. On the router, Dnsmasq and Dnscrypt-proxy with "forwarding rules" mapping domains or TLDs to desired resolvers. Any queries not matched get forwarded upstream to a server running Dnscrypt-wrapper and Dnsmasq, which logs and resolves over Tor. https://github.com/DNSCrypt/dnscrypt-proxy https://github.com/DNSCrypt/dnscrypt-proxy https://github.com/Cofyc/dnscrypt-wrapper https://github.com/Cofyc/dnscrypt-wrapper

JoshTriplett 7y ago

Does your setup distinguish between IoT-ish devices (where you don't know what software is running) and human-operated devices (which would trigger this every time they browsed to a new site)?

icefog 7y ago
No, but that would be fairly easy to configure - put the IoT devices on their own VLAN with dedicated DNS server. My household is small and the list of new domains visited is manageable and interesting to inspect by hand. It's definitely more of a hobby than a scalable solution, I must warn.

danesparza 7y ago

WOW - that takes a lot of discipline! How in the world would this scale on an Enterprise level (which I would assume would be the primary target)? Also -- this specifically exploits IPv6 DNS information: You're checking that manually even at your small scale?

piffey 7y ago
IPv6 DNS C2 is pretty easy to spot. ISMDoor for instance throws an exclamation point in its "sync" messages with the C2 which gives it away since that's an invalid character in the spec. Other C2s use IPv6 responses which are encoded which often drops them outside of the global unicast scope or returns an IPv6 address on an unassigned network. IPv6 has such a huge address space that you can check responses with something like ipv6calc and catch anomalies really fast. As far as I've analyzed there isn't a malware family using IPv6 DNS tunneling that actually attempts to be always in an address range that makes sense/valid in its responses or produce a query that couldn't be easily spotted as a blob of base-64/encrypted data. Though given that you get 16 bytes in a AAAA record to work with it would be pretty trivial to make an encoding that uses those 16 bytes to fill with English word combinations that look like valid hostnames then ensure encoded responses are always in say Google's ::/32. Edit: If you're looking to passively monitor your DNS I'm a big fan of CIRCL's D4 project that's just getting up and running. Check it out! https://www.d4-project.org/ https://www.d4-project.org/

3xblah 7y ago

I use a similar setup. The "whitelist" is a zone served by a local authoritative server like tinydns or nsd. There is no remote server. Using a local cache such as dnscache or unbound is optional. Spotting queries to an attacker-controlled domain in the tinydns logs would be easy. The tinydns logs are invaluable for determining what domains our servers and applications actually need to function... versus the ones that serve the interests of third parties for telemetry, ads, tracking, etc.