Quoting David Zhan ([email protected]): > Hi everyone,
Everyone: 'Hi!' > I am thinking about running a public DNS server (with Pi-Hole) at > home, but not sure if that's safe. Safe against what? In the security field, we tend to use concepts like 'threat model' and 'attack surface'. You may want to look those up and consider what your concerns are and how to articulate them. Exposing any network daemon to remote networks, not to mention the public Internet, necessarily expands your attack surface. This is why you should (1) not run public-facing software without compensating benefit, (2) be picky about which software option you elect to run and how it's configured, and (3) maintain your system, e.g., roll out necessary fixes that may addresss security problems in a timely manner. Relevant to that, you may be pondering choice of software. Here are some good maintained open-source DNS daemons available for Linux: Authoritative-only: ------------------ Knot DNS NSD for small/medium-sized deployments PowerDNS Authoritative Server for large sites YADIFA Recursive-only: -------------- Deadwood dnscache from djbdns/dbndns, which appears to be the best-maintained fork of djbdns PowerDNS Recursor Unbound Generally, I prefer NSD (auth-only) and Unbound (recursive-only). Notably absent from that list is BIND9. Some more details about that are in my DNS software bestiary: http://linuxmafia.com/faq/Network_Other/dns-servers.html If the category distinctions (authoritative, recursive, etc.) are unfamilary, my somewhat puckish allegory about the 'Village of Lan' (that I penned in 2010) may help: http://linuxmafia.com/~rick/lan.html > I planned to share this server with my friends in Melbourne but I > don't want them be able locate my home. Well, far be it from me to criticise what you say you want to do, but, FWIW, I long ago decided that, for my _own_ Internet presence, I would pointedly take the opposite approach, e.g., in the (totally discretionary) LOC (location) reference records I publish in my domain zones, e.g.: $ dig -t LOC linuxmafia.com. @ns1.linuxmafia.com. +short 37 25 53.825 N 122 11 52.128 W 15.00m 1m 10000m 10m $ In fact, to lampshade the joke, I also publish an 'ICBM address' on my personal Web page, accurate to about a centimetre, giving the exact location of my favourite chair in my living room. ICBM: 122.204196°W, 37.430410°N, 49.28 metres elevation I have it on good authority that my 'Here, let me make it trivial for you to determine the exact physical location of me and my computing gear' spooked at least a couple of people who set out to 'doxx' me and found it worrying that I rolled out the red carpet for them. ;-> > Questions: > > Will my user be able to locate my home accurately? > (To suburb is acceptable, but street is a bit scary......) Assuming you don't do as I do and flamboyantly publish that information in LOC records and ICBM address data, then the user's ability to do that would be limited to the accuracy of geoIP data, which also tends to cost money to the consumers of that data. Ever notice that Google News makes a guess at your physical location based on your public IP address? That's using geoIP services. But notice that it's fairly approximate, at most isolating the IP's location to a neighbourhood. and sometimes it's comically wrong, depending. > Will I be facing other risks? Of course you will. This is where you start studying security, the way we sysadmins do. One modest starting point, a piece I wrote about a LinuxWorld Expo security talk in 2000: http://web.archive.org/web/20080427075329/http://security.itworld.com/4352/LWD000829hacking/pfindex.html > P.S.: I will put that server behind a properly configured firewall, so > the server itself should be alright. {headdesk} Nope. Most people use 'firewall' to mean 'set of IP/port filter rulesets'. Consider a hypothetical example server. It has a minimally configured instance of NSD for authoritative nameservice to the public Internet, it runs Portable OpenSSH for remote administrative access, runs atop Linux, and has no other network services whatsoever. Therefore, the attack surface consists of: o code exposed on port 22 (SSH) o code exposed on port 53 (NSD) o Linux TCP/IP stack Add to that a 'properly configured firewall'. What does your attack surface now consist of? Answer: the same, except there is additional possible exposure to stack congestion on account of the netfilter rules. > > _______________________________________________ > luv-main mailing list > [email protected] > https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main _______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
