Sorry for getting a bit personal here, knowing that this will throw back our lately positive developing relationship, but as you obviously couldn't resist making and repeating an absolute statement against DietPi, I cannot let such uncommented.
Either you rate different aspects of a systems security very differently than me/us, or you drop and raise your standards depending on your current discussion position or with whom you are discussing. I saw enough examples to believe that the letter is not an unrealistic theory. Since I'm a bullhead, likely I behave similar by times, without recognising, but on the firewall topic you'll find my above statements in at least two other places, where it was about offering a firewall as install option via our UI, doing more than "apt install iptables", not about having the package pre-installed. On a Windows system, bloated with closed-sourced applications and features, in-transparent, but constant network traffic to and from various, by me only partly known, hosts, similarly default cheesy perforated firewall rules, I see things completely different and would clearly agree with you. But the FOSS upstream-side development, Debian-side review, testing and compiling, stable suite APT downstream installs is an overall infrastructure that I trust enough to see no need for a pre-installed firewall in let's say 99% of use cases we address.
But as you made such an absolute statement, I'm curious how you set your standards when it's about Pi-hole's security:
If it's a definite requirement for you to configure a firewall before connecting a freshly flashed Linux distro to the internet, then I wonder how you need to rate the obvious security "weaknesses" (quoted, as I see them relative only and not as real issue) that Pi-hole is installed with:
- It's shipped with plain HTTP webserver configuration, making it even difficult to switch to HTTPS as the main configuration is overwritten on each update. I know the three years old community guide, containing correspondingly outdated TLS protocol and cipher settings, with forced cipher order, so that modern Lighttpd defaults and client preferences are weakened. Yes, admins with sufficient knowledge who require elevated security can set this up themselves, but after initial install, the web interface is "exposed".
- This plain text web interface can be initially accessed by a password that is printed two times in plain text to the console during Pi-hole install and of course is then transmitted as plain text from client to server. What a theoretical security issue until the admin manually shuts down the webserver or changes the password. Of course one could setup a firewall to block port 80 before installing Pi-hole (not sure if the installer would go through?), shutdown and configure Lighttpd to use HTTPS and preferably change the password, then unblock port 80 and 443 to allow web UI access. Sounds pretty much like the little extra work that you'd need to do on a fresh DietPi image to have iptables available prior to first network connection.
- Pi-hole is shipped with a blocking page that can be accessed without network restrictions and leaks server information, including the private IP address, in certain circumstances, all again in plain HTTP by default. Since you plan to remove most parts of the blocking page, reasonably IMO, I did not report this issue, until the planned change has been finished. Since the blocking page is only relevant when actively used by changing the blocking mode and for clients which actually use Pi-hole for DNS resolving (usually private networks only), Lighttpd could be easily configured to prevent accessing it from non-private IP ranges by default and prevent access completely when using a different blocking mode.
- The web UI checks the client-controlled "host" header against a list of authorised hostnames/IPs, but includes Lighttpd's server name in this list without giving it a server name in the shipped configuration. In such case, Lighttpd automatically assigns the client-controlled host header value as server name, which renders that check obsolete. To be fair, this does not include CORS via HTTP_ORIGIN if used by the initial client, which still prevents effectively against bad proxies/rewrites.
- The Lighttpd user is granted root permissions to execute the pihole script. What an attack vector!
- And did you know that DietPi addresses most of the above, as it allows to enable modern HTTPS easily, blocks non-private IP range access to the blocking page by default, allows to do the same for the admin UI and re-applies a user-chosen encrypted password for accessing it? The one optional feature breaks access to the Pi-hole admin panel when the local subnet does not use an IP range that is officially reserved for private networks, and in case of a user report in this forum you would blame us for this, while using such an IP range for ones private network can be seen as security issue by itself: security vs convenience for end user and/or support team.
I don't think it makes sense to invest development time into the above points, as most will be obsolete anyway once Pi-hole has the webserver with PHP included into the FTL binary. Let's have a look at that:
- Your plan is to merge a PHP implementation that has not seen commits for three years, is based on ancient EOL PHP 5.3 and that uses a single huge source file without any visible unit tests. You are talking about protection from "things you don't know" and bring a huge rarely used and hence rarely reviewed or tested code block into your project, behind any firewall and with elevated permissions for a quite sensitive network service. I can understand and agree with the reason in this particular case, but from a strict security perspective, breaking admin's possibility to use and configure modern, maintained and well-known webserver and PHP implementations for using the Pi-hole web UI, is a step backwards.
You know why I would still recommend Pi-hole? Because all the above is not an issue in 99% of use cases and considering the users you mainly address and the possibilities that every admin still has to manually harden Pi-hole and system security where required. In an environment I can think of where a missing pre-installed iptables is a killer argument against using a distro/image, I'd not recommend to use any public distro image but bootstrap it in an offline environment from double-checked local repositories. I would never install Pi-hole on such sensitive system, and for DNS-based ad blocking I'd use a block list to Unbound rules converter and do all of that with Unbound only to skip all the possible attack vectors that a webserver, PHP, additional dnsmasq, system user and overall increased complexity that Pi-hole implies.
It is all about the use case and individual needs and a long-sighted security strategy, from developers view as well as from system admin view, always requires a balance between security and convenience for the average user that is addressed. Products are not used when being too inconvenient, making users migrate/stay with less secure alternatives, additional security measures get disabled or worked around, like too similar or written down passwords, in case of forced rotation, 2FA via same device as client, at best with passwords stored in browser, proprietary cloud password manager solutions in general, etc. Pi-hole implies a lot of complexity, theoretical attack vectors and weakened security for basically convenience features on top of its core functionality, mostly addressing lesser experienced users, which is fine as in very most cases, blocking bad websites increases overall user security much more then the above mentioned points, and the easy install and convenience is what made it so popular, even that other much safer and less complex solutions exist.
Another thing: If you quote me, please use the words I used and do not take them out of context. I never wrote that my or our view about a firewall is that "it's too hard" and I'm not even sure what you are referring to with this quote. I made clear that we do not pre-install iptables since for users that need it and know how to configure it it's not a bid deal to install it, even prior to first network access, where really required. If there was a single actual user complaint, I'd more likely re-consider it, as there is also no real argument against pre-installing that little, by default passive package, to be true.
Okay, help me out of the mud, I still love Pi-hole and you guys for developing this great project and the awesome end user support you do, which is kind of exceptional, the above was mostly a defence reflex 
.
