[BALUG-Talk] [BALUG-Admin] balug.org DNS review ... CHAOS ; -> ...
Michael Paoli
Michael.Paoli@cal.berkeley.edu
Wed Sep 27 22:01:21 PDT 2017
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
>> 3. 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.
More information about the BALUG-Talk
mailing list