I can understand the benefit of automating these things but I think it would probably be better for people to setup these things manually first. At least to understand what each step is doing. Otherwise, people are trusting rather a core piece of infrastructure with a random docker image online.
I found personally that there are several aspects of this automation that needs tweaking.
* If you need ipv6 support this config needs to be overhauled.
* Wireguard config should have ipv6 addresses set to avoid potential leakages (even if ipv6 is disabled).
* This setup would benefit from some ddns mechanism as most people do not have static ip setups.
* Firefox is beginning to have https only modes in which case maybe I would like to adjust lighthttp to work with that.
You think an unprivileged docker container is more dangerous than a curl to bash with sudo inside? I beg to differ.
If you care to please elaborate as to why I would be better off piping to bash rather than installing per the documentation? I am honestly interested in your take.
First is that trusting my suggestion is no different than trusting the instructions in your repo. Both can equally harbor nefarious things. So, the question is: do I trust Docker's script over someone that was just on the front page of HN? Probably.
To address the technical side - there are a number of things that can be improved from a security point of view in your compose file:
1) Restrict any new privs.
security_opt:
- no-new-privileges
2) Drop all privs then selectively add.
cap_drop:
- ALL
cap_add:
- NETADMIN
3) Limit CPU and memory.
deploy:
resources:
limits:
cpus: '0.50'
memory: 50M
reservations:
cpus: '0.25'
memory: 20M
4) Change the running users - looks like all the containers are running as root, which is no different from the system user.
There are others, but.. Just because the container isn't explicitly 'privileged' doesn't mean it's operationally safe.
I understand that it’s better to have less dependencies. And I understand that a pipe to bash thing can do more than a naive user would think. But the header of get.docker.com doesn’t pipe directly to bash anymore. You can inspect the downloaded shell script or compare hashes.
I disagree that they should try setting up these things manually. Provided the automated installation is good enough, it's easier to pick apart a ready-made install to find out how it works, than to deal with the learning curve of learning how to troubleshoot the pieces that don't quite work together yet and learning their role in the overall stack.
I would have never gotten into email self-hosting if someone hadn't done the hard work of creating an all-in-one solution, because it would have taken more time than I would be willing to invest.
This software simply isn't a simple set it and forget like microsoft office, skype or other consumer apps. It is more important than a basic mail server because it is resposible for networking and if things like DHCP/DNS goes down then access to the internet is at risk. For 99.9% of people out there, that is just going to be an unpleasant experience when things go wrong. That reasonably could take down people's security, automation, VOIP phones etc..
I have seen pihole alone go down because one of the gravity sources goes down or because of a dhcp misconfiguration.
It involves setting up a VPN and that by itself needs some monitoring/debugging to understand what to do when things necessarily go wrong, especially in regards to routing, setting up splitVPNs etc..
Speaking as someone who has all of this setup manually, there is a bunch of fine tuning and fiddling that makes a set and forget not particularly ideal. On my setup I have to work with a custom cloudflare script to enable DNS records to update. I need a custom lighthttpd config to enable https with letsencrypt. My setup uses DNSCryptProxy instead of unbound (to enable ESNI + DoH for Firefox through my pihole) and as such caching needs to be disabled.... Just a bunch of random tweaks here and there that need to be thought out.
Take an example of simply adding multiple other peers to wireguard. Something that people would reasonably want to do with a pihole/VPN. There are no instructions how to do it with this.
If I'm reading the docker-compose file correctly, this creates an open dns resolver that is accessible to the outside, as Docker by default bypasses the firewall, see https://github.com/chaifeng/ufw-docker. I'm not quite sure about that, though, so I'd be happy to be corrected and learn more about how your setup works exactly.
> Either specify both ports (HOST:CONTAINER), or just the container port (an ephemeral host port is chosen).
It sounds like you get a random publicly accessible port unless you specify a non publicly accessible IP. I'm not sure whether having a DNS server listening on a non standard port would be an issue though.
but nonetheless you're ingress rules in your cloud provider will not allow anything but that's single port so it's not really a big deal provided you close everything else off in your firewall.
I will make an update to see how I can work around this
Thats not true. DNS isnt on 51820. That's wireguard. You cannot hit the DNS unless you're connected to the wireguard VPN provided you're using a cloud provider and you havent configured any additional ingress rules other than port 51820. That I am positive on.
Ahh, so as long as I only list single ports and not pairs, it is not exposed to the host, because the other number of a pair is the port to be exposed on the host. And therefor it is not exposed to the public network in this case. Makes sense, thanks for the explanation!
At the risk of splintering interest: Algo[1] and Streisand[2] are two popular open source projects that do nearly identical things. Both also have the advantage of supporting a wide variety of cloud providers by default. Algo installs the absolute minimum needed to get you online with a well-configured VPN; Streisand comes with a whole bunch of bells and whistles (including some that are easy to misconfigure).
We can't talk about these without talking about nextdns.io which, in my opinion, is the most elegant way of solving this problem.
I wanted to run a pihole for years but never got around to building it into my dns infrastructure. Nextdns, on the other hand, was a quick afternoon setup ...
Maybe NextDNS is more elegant or easier to set up, but I felt that depending on its free plan was too risky (what if it eventually goes away?) and didn't really want to pay for a subscription when I already had a server at home to run PiHole on. I didn't really like needing to go over the Internet to configure it either - the PiHole admin panel is just another intranet site.
It's good that NextDNS exists, but I can't help feeling that having your main site make the kind of third-party requests you'll likely want blocked by their service is kind of a marketing faux pas to say the least.
Just to drive his point home, it takes 5 minutes to get nextdns.io up and running. Want ad-blocking/domainblocking on your mobile phone? Install the app, enter the code and you're done. I used to have a pi-hole, but the rpi broke so now I only use nextdns.io for everything. But you're not in control since it's in running in the cloud, so there's that.
This is a weak argument as pi-hole needs to go to a resolver or perform recursion itself which will give you the same latency or worse. The 1ms latency will only apply to already cached entries that are also cached by you OS anyways, whichever solution you are using.
If you configure NextDNS on a router, your router will perform the exact same caching pi-hole is doing, so it will make no difference performance-wise.
I originally wanted to use that for "baremetal" type deployments, but ultimately was having trouble with the systemd-resolve service. Probably my own ignorance, but ultimately felt I could make a more secure alternative with docker :)
Ya know, I almost edited the comment to specifically say I only looked, and can't speak to the quality of service because I won't do business with Oracle when at all possible.
Thank you, that's really cool. I've been using DNS over TLS, but it's really complicated to set up. Just running your own recursive DNS actually seems easier. :D
Another good reason for having unbound is enabling internal DNS resolution for things that are in the VPN. For example, resolving build-server.mycompany to the in-VPN IP of your build server, and so on.
What does this tooling do? Of course I could Google the components and look it up, and I already know some of those so I can imagine what it might do. But it would be so much better to get the author stance. Ideally for users the first paragraph on both Medium and GitHub would be something in the order of "Use this tutorial to accomplish x through the use of y and z."
Awesome work! I think you saved me many hours, as I was going to tackle this over the weekend. Props for making those suggested security changes right away. I was just looking at my DNS cache last night and was appalled at the number of ad and telemetry requests are happening.
So I’ve never setup a vpn before, I’ve been trying to decide how to make this simple for windows clients and phones. Must I have a vpn client? I’m using IPSec, ssl, and LDAP on the public end. I don’t want a client app. A gateway/router should suffice I hope.
WireGuard is growing in popularity but I’m not aware of any router firmwares which have a WireGuard client built-in (maybe the popular open source firmwares). Many routers have OpenVPN clients built in.
i really like my GL inet router, which has the ability to be a VPN client or server built in to the router GUI. wireguard, openvpn, and tor (!) are options at the router level.
their router's UI is built on top of OpenWrt, so you can always fall back to OpenWrt GUI as well for configuring more advanced setups.
Can anyone recommend an easy way to tunnel an entire network over zerotier? I am able to use zerotier perfectly but access is on a per device basis. Could we tunnel the current network with its gateway as a zerotier pc ?
I found personally that there are several aspects of this automation that needs tweaking.
* If you need ipv6 support this config needs to be overhauled.
* Wireguard config should have ipv6 addresses set to avoid potential leakages (even if ipv6 is disabled).
* This setup would benefit from some ddns mechanism as most people do not have static ip setups.
* Firefox is beginning to have https only modes in which case maybe I would like to adjust lighthttp to work with that.
The list goes on.