A strong password is not enough. Passwords can be and have been brute forced..even the best of passwords, hence why 2FA/MFA became a thing in the first place and why a completely alternative to passwords are being studied. 2FA definitely has a bearing and always has a bearing when it comes to logins. To suggest otherwise is to have learned nothing from previous breaches. I've worked in IT and Web Dev for over 10+ years and have seen first hand how valuable 2FA can be. Take a look at website logs sometime and witness how often they are hit with brute force attacks. I've implemented various techniques to mitigate it, including adding 2FA as an additional safe guard.
Attacking a pihole instance is definitely a valid attack vector, especially in the case of a targeted attack. Having access to a pihole and being able to control DNS would make a MITM attack easy as pi, just point to an attacker controlled dns server, point to a fake website and harvest the credentials. There is so much you can do with compromised DNS AND you can go undetected for quite a while if you are subtitle with it.
A lot of network appliances are implementing 2FA with more working on it. Obviously there is a benefit and a need or they would not be implementing it.
I figured you weren't staff, hence not having the badge.
I agree with you on this. A lot hinges on what exactly they are after but just because attacking a pihole may not always be a useful target, doesn't mean that you should ignore that potential threat vector either.
I think what this boils down to is that we have a significant difference in risk tolerance. I'm not going to trust just a password to protect my admin pages. I'm also going to address any and all reasonable attack vectors, which a pihole installation IS a viable threat vector just as my router would be.
It might be more accurate to say that it's a tool that has pros and cons. The pros are clear in many situations and of almost no value in other situations. The cons include development and support, not to mention cost and even liability. If you install a vault door on a trailer, you don't have a mobile vault, you have a trailer with a terrible door.
I've worked in IT since the Web was that new thing that kept coming up in Gopher searches and I've seen first hand how the benefits of technologies always become lost in faith-based discussions.
Pi-hole is intended for use as an internal-facing service to be used by known clients. A compromised machine (AKA unknown clients) already has compromised DNS, compromised Pi-hole session cookies and compromised Pi-hole http traffic, without touching the login page.
I suspect most people's aversion to risk is similar once they appreciate the risk, but you are assessing your risk on the technology in use (you're "not going to trust just a password"), while I am basing my technology on the risk and the cost/benefit of deploying.
I'll leave this here, and thanks for the discussion.
Having access to a Pi-hole is going to allow you to set up a website with fake SSL credentials that will allow the fake website to authenticate user connections properly to make the https connection?
Example - I try to connect via SSL to mybank. You have a fake website called myfakebank. How will my browser connect to your fake website via https since you don't have the SSL credentials that mybank has?
I never said that it would be hosted on pihole, I only said that pihole could be used to manipulate DNS. Further the way this kind of attack works is they use dns to send the victim to an attacker controlled server. They don't need the ssl certs from your bank...They use a domain that is similar enough to your banks, they can get an ssl easy enough and then setup a page that closely mimcs the banks.
This is a pretty common attack method.
I think so. Its happened to plenty of other web admin GUI. Why is it that leads you to believe PiHole is immune to this?
Yeah, if its the one specific machine I access pihole with is the one compremised but again, my attack vector examples rely on entry through servers that are public facing which I don't access pihole with.
I didn't asses it based solely on that and I did take cost/benefit of deployment into account. Earlier when they said that they didn't have the developer/time resources to implement it or review a contribution and I even replied that it was completely understandable. The thing is I wasn't debating the validity of 2FA based on that because we were never out of agreement on that. The only thing we were out of agreement on was the level of validity 2FA has. Other network device vendors have determine that there is merit to having it (opnsense/Ubiquiti for example).
This will just have to be summed up as agree-to-disagree. Thanks as well for the discussion, its been enlightening.
Just want to point out that those vendors make products which are designed to handle traffic from all sources, known and unknown, across network boundaries and across the whole stack. For that reason I would expect any kind of management interface for those products to have a solid multi-factor implementation to help prevent unauthorised access, directly or via trusted admins.
I'm all for security when it's done purposefully and for a purpose, but this just isn't possible with DNS, compromised or not.
A client will ask the DNS for the IP address of a domain. For this exercise we'll say legitbank.com. The DNS will respond with what it thinks is the IP address of that domain. A compromised DNS will replace that IP address with a different IP address. The client will then try to connect to legitbank.com at the bad actors IP address but the server at the bad actors IP address will not have the certificate for legitbank.com. They may have a certificate for legtitbanc.com but it really doesn't matter since the client won't be asking for legtitbanc.com. There is no possible way for a DNS server to change the URL or domain that a client is trying to utilize.
The only way to attack that way is to convince the cleint to actually go to legtitbanc.com while thinking they are visiting legitbank.com. And if you can do that then you don't need to do anything with replacing IP addresses on their DNS server, you own legtitbanc.com to generate the certificate so you can just use the global DNS hierarchy as it is.
That may be, but you need to at least have common ground to understand what the risks and possible attacks are.
While working on the Pi-hole v6.0 API authentication sometime last year, I also looked into TOTP 2FA (think of: Google Authenticator and friends with time-dependent six digit codes). Since we already use the well-known and -trusted libnettle crypto library for DNSSEC, the implementation overhead is minimal as HMAC routines are already available. On the other hand, other alternatives (thinking of FIDO, Yubikeys) are out of question here as they require not only complex libraries on the client side but also server-side applications or couplings to third-party services on the web which are in conflict with Pi-hole's philosophy.
I merged this out-of-tree feature now into the current FTL v6.0 development version. It has a new config option webserver.api.totp_secret taking a Base32-encoded TOTP secret. This feature is disabled by default. When enabled, a valid TOTP token needs to be provided on every login attempt, not only to the website but also to the API itself. When working with local scripts, we have pihole-FTL --totp that creates a valid token for you to ease adding to your scripts. When querying the API from remote, you will have to take care of this yourself.
So far, the backend support is fully implemented, however, frontend is missing most of the convenience stuff (like generating a scanable QR code for your smartphone). You may utilize /api/auth/totp to generate TOTP secrets along with some example codes to check whether adding the second factor worked before really enabling the feature. Mind that the TOTP secret cannot be read through the API, you will only see it once when setting 2FA up but you can always ssh into your Pi-hole to disable 2FA via CLI in case anything goes wrong.
The layout can surely be improved but here is a screenshot from the login page of the v6.0 draft (branch devel-v6). The second input field is only shown when TOTP is enabled on this Pi-hole.
Just wanted to throw out there that I was able to sort of implement something somewhat along those lines as well. Internally, it's just userid/password, but I can get to the admin page externally as well in a secure manner.
In short, I created a Cloudflare tunnel (Cloudflare Tunnel: Expose Your Home Network to the Internet Securely – TheITBros) pointing to my main internal pihole instance, so I can use an https connection from anywhere in the world to connect to the pihole web UI. This uses 2FA as well (so you need to authenticate before you even get to the logon page.. In my case, I've set up two options for that authentication, an emailed code or Google federated logon.
So, now I can point my browser at Sign in ・ Cloudflare Access and get to my interface externally, using https as a bonus.
