I'm looking to limit the damage that can be caused if a Pihole container were to be compromised. Specifically, I'd like to ensure that root access to the container itself cannot allow an attacker to manipulate my domain resolutions. I have relevant firewall rules in place but that wouldn't prevent an attacker from just changing the hosts file (or pihole equivalent) to redirect normal domains to bad IPs.
I'm thinking maybe I could manage the dnsmasq configuration centrally from the host and then mount the configuration(s) read-only? Perhaps manage the adlists and gravity centrally too if that's possible?
Wondering how I could go about this? Thanks in advance.
For the device in question yes, but in this particular case it's only really used for DNS so lateral movement would be needed again if they wanted to get any further. Not being able to manipulate my DNS queries would help a lot to stop that.
If an attacker has root access to your DNS server then there's really nothing you can do to stop it. You can move /etc/hosts to a different filesystem or mark it read only but that does nothing to stop the root user from creating new hosts file or, the more likely scenario, installing a new DNS server or replacing pihole-FTL with their own malware.
The idea would be to lockdown FTLDNS as much as possible in order to limit any damage that can be done by a dnsmasq or FTLDNS exploit. Things such as using scratch containers to limit access to any native binaries which could be used to priv-esc and limiting the container memory to prevent an attacker from injecting too much code into the pihole-FTL process (in lieu of having the native binaries available). Plus other things like firewall rules and IPS signatures to make sure any DNS traffic is legit (since only port 53 UDP would be allowed).
But yeah if the attacker does get root then there's little that could be done to stop DNS poisoning with a hardcoded IP.
lol true. I'm thinking of it from a view of trying to reduce lateral movement if that device is the only one on the network that the attacker is able to gain control of. They'd have a wider range of attacks possible if they can redirect my traffic as opposed to just trying to find other vulnerable services running on networked devices.
That assumes you are giving public access to your resolver, which is an inherently BAD idea.
Otherwise you're tilting at windmills, limiting to UDP means most queries will just not return a result. This is especially true if you intend to use DNSSEC.
To where? TLS pretty much prevents any impersonation or MITM attacks.
I think it's great that you are looking at security and safety, but you have so many other attack surfaces that are bigger and easier to get to than a private DNS server on a LAN.
That assumes you are giving public access to your resolver, which is an inherently BAD idea.
No public access, just guarding against a situation where a device within the VLAN comes under attacker control.
For the firewall rules I mean within the LAN it would be restricted to UDP 53. WAN access would be firewalled to allow the DNS server to only communicate with the desired upstream server.
TLS pretty much prevents any impersonation or MITM attacks.
I'm thinking more along the lines of redirecting to an attacker controlled server on the internet.
you have so many other attack surfaces that are bigger and easier to get to than a private DNS server on a LAN.
The main way for an attacker to gain access to the internal network would be through running malicious code on a user's device (maybe by downloading malware) and having it propagate out from there, so I'm looking at the network bit by bit
Again, you can't redirect TLS sites to an IP with a different certificate. And Pi-hole will only return 0.0.0.0 or NXDOMAIN (or Pi-hole's IP) unless you add in custom configuration files. And the only user that can do that is root, and once someone has root on your system there isn't a single thing you can do to mitigate or prevent abuse. Period.
I wish you the best of luck but you're causing yourself a ton of work that will do nothing.
