But wait, there's more, you also get ...!!!
From: "Michael Paoli" Michael.Paoli@cal.berkeley.edu Subject: Re: [BALUG-Admin] balug.org DNS review Date: Wed, 27 Sep 2017 20:53:38 -0700
[moving this to BALUG-Talk - as at least my mostly general responses aren't really all that highly BALUG (admin) specific]
Thanks for the excellent review! :-)
Some comments, etc, in-line below:
From: "Rick Moen" rick@linuxmafia.com Subject: [BALUG-Admin] balug.org DNS review Date: Wed, 27 Sep 2017 09:25:12 -0700
- Information leakage. NS1.BALUG.ORG / 198.144.194.238 answers
(correctly) CHAOS class queries about its version.
:r! dig version.bind txt chaos @NS1.BALUG.ORG +short "9.9.5-9+deb8u14-Debian"
$ dig +noall +answer +norecurse @ns1.balug.org. hostname.bind TXT CHAOS hostname.bind. 0 CH TXT "balug-sf-lug-v2.balug.org" $
So ... we also have ... https://www.ietf.org/rfc/rfc4892.txt and: id.server hostname.server version.server "has been copied by several name server vendors"
Anyway, ... for the DNS server software at hand ... # hostname && cd /etc/bind*/ && pwd -P && co -l -M named.conf.options balug-sf-lug-v2.balug.org /var/lib/named/etc/bind RCS/named.conf.options,v --> named.conf.options revision 1.6 (locked) done # sed -ne 's///.*$//;/^[ ]*$/d;p' named.conf.options options { directory "/var/cache/bind"; key-directory "/var/cache/bind/keys"; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; }; # ex named.conf.options named.conf.options: unmodified: line 26 :/^}; }; :i version none; hostname none; server-id none; . :w named.conf.options: 29 lines, 749 characters :q # sed -ne 's///.*$//;/^[ ]*$/d;p' named.conf.options options { directory "/var/cache/bind"; key-directory "/var/cache/bind/keys"; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; version none; hostname none; server-id none; }; # ~/bin/Named-checkconf # (cd / && umask 022 && systemctl reload bind9) # $ dig +noall +answer +norecurse +comments @ns1.balug.org. version.bind TXT CHAOS ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49907 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 $ dig +noall +answer +norecurse +comments @ns1.balug.org. hostname.bind TXT CHAOS ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27923 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 $ dig +noall +answer +norecurse +comments @ns1.balug.org. id.server TXT CHAOS ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43870 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 $ Hmmmm... I might've expected NXDOMAIN ... but ... close enough. Can further review and possibly further review later ... but "good enough" for now on that one. # ci -d -u -M -m'disable information leakage & potential' named.conf.options RCS/named.conf.options,v <-- named.conf.options new revision: 1.7; previous revision: 1.6 done #
Anyway, that probably covers things "well enough" for the information leakage / built-in CHAOS stuff.
And in case anyone's wondering, AXFR is generally open to all (likewise for sf-lug.org. and sf-lug.com.) - really nothing to or worthy of hiding in the DNS data records for the LUGs. Does also help out some (legit) project(s) that try to use (at least in part) DNS to map out The Internet (though even in those cases, could, if one wanted to restrict, allow AXFR from those IP(s), but not The Internet at large).
So yes, haven't surveyed the landscape, but seems likewise at least some other DNS server software - besides BIND, has likewise implemented same or similar (mis)features on handing out version and other information in same or similar manner.
And ... defaults matter. At least version and distribution I'm dealing with, id.server is disabled by default (but I also explicitly disabled it, to play it safe(er) - notably should the default ever change). But the others weren't disabled by default.
It'd be a good idea to turn this off. I like to return amusing lies, myself. My stanza in /etc/bind/named.conf.options :
options { directory "/var/cache/bind"; version "Shirley, you're joking"; hostname "ns1.linuxmafia.com"; //server-id is essentially redundant to hostname, default is none //server-id none; auth-nxdomain no; # conform to RFC1035 allow-recursion { [redacted] }; allow-query { [redacted] }; dnssec-validation yes; };
Ah yes. :-) "Of course", there's almost always tradeoffs regarding security. E.g. convenience/speed vs. ... well, security and some information not being so convenient/available.
As for DNS server identifying its software/version ... what [il]legitimate uses for that? Well, there's negligible legitimate use, so general best practice is to disable that - or put in some bogus or intentionally misleading string. Legitimate uses of it being there? Mostly negligible ... but there are some slight ones. E.g. for local or secured environments/networks, can be useful/convenient. E.g. not much harm/risk exposing it on 127.0.0.1 and ::1. But ... open to The Internet ... makes it easier for bots/attackers to know the specific target software ... and thus more likely to be able to successfully attack. However, even if the information isn't made available, software can be probed/"fingerprinted", so even if the version information is disabled or altered, attackers may still figure out - if not precisely the target version - at least often approximately the target software and approximate version or some version range. So ... it's bit of tradeoff ... make the information (much) less accessible (or not) - and make attacker's challenge some fair bit more difficult (but not hugely more difficult). Oh, I did say some negligible legitimate uses ... even on The Internet - software surveys - those *can* be used for legitimate purposes. Can also be abused - particularly if the data isn't quickly rolled up into the aggregate, but hangs around (or leaks) with specific IPs and corresponding software information, etc. ... and especially if that is leaked or exposed in bulk.
I'm also curious - and don't recall - been long time since I read about it ... txt chaos ... that mechanism was put in BIND many many moons ago. Is it entirely (or mostly) unique to BIND? ... in which case even serving up a "dummy" answer would identify it as some flavor of BIND server. Or ... has other DNS server software adopted that same mechanism for reporting version (most notably if it's in as a default - I think most DNS software can do class CHAOS, though probably almost nobody explicitly implements such). Anyway, depending on the various DNS server software behavior - it may be better to, if feasible, disable that response rather than just put in some dummy response. Anyway, ... I'm curious what current best practice is in that regard for DNS servers - and BIND DNS servers. And I don't think I've any issues with, e.g. disabling it. I think thus so far in my life I've used it one to perhaps a few times. It's a "feature" (offering up its software and version information via DNS query) which is of very close to zero legitimate usefulness.