DNS security hardening

General questions.
Post Reply
Saiyato
Posts: 36
Joined: October 9th, 2018, 6:55 pm

DNS security hardening

Post by Saiyato » November 28th, 2018, 5:14 pm

I will update this first post with all new info provided, hopefully helping people configure their DNS resolver properly.

To start there are a few measures that can be distinguished at this point:
1. DNSSEC
2. Encrypted DNS queries (DNS over TLS or HTTPS)
3. QNAME minimisation
4. TCP Fast Open (TFO)
5. DNS block lists (breaks DNSSEC?)

Both measures have different impacts and require different actions to configure (or reconfigure for that matter).

DNSSEC
This encompasses the validation of zone certificates against their respective parent zones. Cloudflare has quite an elaborate explanation on how it works. But in short it should prevent different DNS attack types like cache poisoning, they have another page explaining the threats.

By default DNSSEC is enabled in IPFire, however IPFire does not return validated responses itself.

Disabling DNSSEC
It's possible to tamper with the DNSSEC settings according to the thread "Is it possible to disable DNSSEC?".

Testing
How to test whether or not DNSSEC is actually working on a client:
https://dnssec.vs.uni-due.de or http://en.conn.internet.nl/connection/

On the IPFire appliance you can test this with dig:

Code: Select all

[xxx@ipfire ~]# dig pir.org +dnssec +multi

; <<>> DiG 9.11.5 <<>> pir.org +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33426
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;pir.org.               IN A

;; ANSWER SECTION:
pir.org.                299 IN A 97.107.141.235
pir.org.                299 IN RRSIG A 5 2 300 (
                                20190121084003 20190107084003 38661 pir.org.
                                NXxtWGKf/O4wmRohqw1Qi3TIhaVG0CB3WZ0m43KLYe0h
                                /WfVuj23iK+e82So6+9XwaPmCL5U9oHH9Nub7yseNkk6
                                jhVXrgCwRSL6zXfCFyTImVHcCQ3pI3dxr1NXZzYj2vVX
                                foSDS15RRchNCDBbhfGfXyPZgXdRK4YBqL83vpM= )

;; Query time: 66 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 07 13:54:42 CET 2019
;; MSG SIZE  rcvd: 219
And when the chain is broken, no dns information is returned:

Code: Select all

[xxx@ipfire ~]# dig +dnssec www.dnssec-failed.org

; <<>> DiG 9.11.5 <<>> +dnssec www.dnssec-failed.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2916
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.dnssec-failed.org.         IN      A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 07 13:55:18 CET 2019
;; MSG SIZE  rcvd: 50
My question is: when IPFire validates queries, but does not return them validatable, how does that work for the devices behind it? Does it just filter unvalidated responses by not showing the page and should you check the logs when this happens?

Concerns addressed: security

Encrypted DNS (DNS over TLS = DoT or DNS over HTTPS = DoH)
This encompasses encrypting the queries, effectively hiding them (in the case of DoT) in plain sight. I was unable to find consensus on whether one or the other is better, they both encrypt the requests, which should mean a MITM (man-in-the-middle) attack is harder to execute, since there's end-to-end encryption. The DNS server can still log the requests, which means privacy is still not effectively safe guarded, but in the end we're all at the mercy of the DNS servers and their promises not to log our activity. ;) At the very least we should be protected against eavesdropping, which counts for something, right?

Whichever you choose is up to you, DoH hides your DNS queries between other HTTPS traffic, whereas DoT is still recognizable as DNS traffic.

This topic has been discussed several times this year, the following threads were easily identifiable for covering this: The dates match the first posting by TS.

Plus there is a mail conversation.
Again Cloudflare has taken care of an explanation, this saves me a lot of time/typing.

Configuration
This is not automatically configured and requires some know-how to setup, there is a wiki page to support users, but option 1, the most preferable does not work anymore. Plus you still would need to configure unbound to act as such.

So - correct me if I'm wrong - you need to configure following, assuming you want IPFire to act as the DNS server:
  1. Configure unbound to not use forwarders and save this setting in the (probably) non-exitent file /etc/sysconfig/unbound.

    Code: Select all

    echo "USE_FORWARDERS=0" > /etc/sysconfig/unbound
  2. Combine the certificates for unbound The cert-bundle is already available in /etc/ssl/certs/ca-bundle.crt [update]

    Code: Select all

    cat /etc/ssl/certs/* > /{DIRECTORY CONTAINING CERT BUNDLE}/{BUNDLE FILE}
  3. Configure unbound to connect to a DoT/DoH forward DNS server (configure tls as enabled and list the servers you want) for the root zone (dot) = every request. You can configure any number of servers. The setting forward-tls-upstream en- or disables whether queries to the forward servers use TLS or not, this is not a setting to control TLS queries from the client to IPFire, plus you need to configure the tls-cert-bundle:
    tls-upstream: <yes or no>
    Enabled or disable whether the queries to this forwarder use TLS for transport. Default is no. If you enable this, also configure a tls-cert-bundle or use tls-win-cert to load CA certs, otherwise the connections cannot be authenticated.

    tls-cert-bundle: <file>
    If null or "", no file is used. Set it to the certificate bundle file, for example "/etc/pki/tls/certs/ca-bundle.crt". These certificates are used for authenticating connections made to outside peers. For example auth-zone urls, and also DNS over TLS connections.
    unbound documentation

    Exempli gratia:

    Code: Select all

    server:
    	tls-cert-bundle: /etc/ssl/certs/ca-bundle.crt
    forward-zone:
            name: "."
            forward-addr: 1.1.1.1@853 # Cloudflare
            forward-addr: 9.9.9.9@853 # Quad9
            forward-tls-upstream: yes
    Note: the syntax is forward-addr: <IP-address>[@port][#tls-authentication-name]

    You can find some sever info here.
  4. Use a patched init script (see attachment) and overwrite /etc/init.d/unbound

    Note: use this script at your own risk, it's advised to use it only in development/acceptance environments.[update]
  5. Restart unbound

    Code: Select all

    /etc/init.d/unbound restart
  6. Configure the clients to actually use the IPFire appliance as their DNS server. You can do this by setting the DNS server to the IPFire instance in the green network section of the DHCP page on the WUI.

    If you are running a domain, you probably have set the DNS/DC as first DNS server... I'm not sure what you should do then. Maybe configure the DNS/DC to query IPFire instead of the ISP? See question "d".
  7. Block all other DNS traffic, as outlined on the wiki page.
Testing and troubleshooting
This is a little bit more difficult to check, as you need to investigate the traffic, you can use the following packages (available in Pakfire):
  • tcpick - discontinued for ARM, I couldn't find it

    Code: Select all

    tcpick -i red0 -C "port 853"
  • tcpdump

    Code: Select all

    tcpdump -vvv -i red0 dst port 853
  • unbound-control; you can check whether or not the forward servers are loaded

    Code: Select all

    unbound-control list_forwards
    Or dump the cache

    Code: Select all

    unbound-control dump_cache
Troubleshooting
  • The WUI shows local recursor and I'm unable to browse the internet. Try updating the forwarders, it might be that the responses are dropped:

    Code: Select all

    /etc/init.d/unbound update-forwarders
Validating the root certificates
You can also check whether or not the root key matches the one shared by ICANN (root-anchors.xml) by calling

Code: Select all

unbound-anchor -l
The first two lines should match the values in the XML file, e.g.:

Code: Select all

. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
. IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
On clients you can use drill, dig or nslookup to check whether or not port 853 is being used.

Concerns addressed: privacy, security

QNAME minimisation
The idea is to minimise the amount of data sent from the DNS resolver to the authoritative name server. In the example in the previous section, sending "What are the NS records for .com?" would have been sufficient (since it will be the answer from the root anyway). The rest of this section describes the recommended way to do QNAME minimisation -- the way that maximises privacy benefits (other alternatives are discussed in the appendices).

Instead of sending the full QNAME and the original QTYPE upstream, a resolver that implements QNAME minimisation and does not already have the answer in its cache sends a request to the name server authoritative for the closest known ancestor of the original QNAME. The request is done with:

o the QTYPE NS

o the QNAME that is the original QNAME, stripped to just one label
more than the zone for which the server is authoritative

For example, a resolver receives a request to resolve foo.bar.baz.example. Let's assume that it already knows that ns1.nic.example is authoritative for .example and the resolver does not know a more specific authoritative name server. It will send the query QTYPE=NS,QNAME=baz.example to ns1.nic.example.
In other words, minimise the information sent upstream to the bear minimum, this will not yield better result in the form of quicker responses per se, but it will avoid sharing unnecessary information to third parties.

A slide show which further explains can be found here.

Configuration
This should be fairly easy, there are a few options to control the behaviour, as described on the unbound settings page. This requires unbound version 1.5.7 or higher.
qname-minimisation: <yes or no>
Send minimum amount of information to upstream servers to
enhance privacy. Only sent minimum required labels of the QNAME
and set QTYPE to A when possible. Best effort approach; full
QNAME and original QTYPE will be sent when upstream replies with
a RCODE other than NOERROR, except when receiving NXDOMAIN from
a DNSSEC signed zone. Default is yes.

qname-minimisation-strict: <yes or no>
QNAME minimisation in strict mode. Do not fall-back to sending
full QNAME to potentially broken nameservers. A lot of domains
will not be resolvable when this option in enabled. Only use if
you know what you are doing. This option only has effect when
qname-minimisation is enabled. Default is off.

Note: the below setting is optional!
harden-below-nxdomain: <yes or no>
From RFC 8020 (with title "NXDOMAIN: There Really Is Nothing
Underneath"), returns nxdomain to queries for a name below
another name that is already known to be nxdomain. DNSSEC man-
dates noerror for empty nonterminals, hence this is possible.
Very old software might return nxdomain for empty nonterminals
(that usually happen for reverse IP address lookups), and thus
may be incompatible with this. To try to avoid this only
DNSSEC-secure nxdomains are used, because the old software does
not have DNSSEC. Default is on. The nxdomain must be secure,
this means nsec3 with optout is insufficient.
You obviously need to restart and stop/start unbound afterwards to load the new settings.

Code: Select all

/etc/init.d/unbound restart
unbound-control stop
unbound-control start
Testing
QNAME minimisation is easily tested using dig, querying the txt section of the qnamemintest.internet.nl domain on the IPFire appliance itself.

When it's not enabled it will return:

Code: Select all

[xxx@ipfire ~]# dig txt qnamemintest.internet.nl +short
a.b.qnamemin-test.internet.nl.
"NO - QNAME minimisation is NOT enabled on your resolver :("
Else it will return:

Code: Select all

[xxx@ipfire ~]# dig txt qnamemintest.internet.nl +short
a.b.qnamemin-test.internet.nl.
"HOORAY - QNAME minimisation is enabled on your resolver :)!"
Concerns addressed: privacy

TCP Fast Open (TFO)
TCP Fast Open (TFO) is an experimental update to TCP that enables data to be exchanged safely during TCP's connection handshake. This document describes a design that enables applications to save a round trip while avoiding severe security ramifications. At the core of TFO is a security cookie used by the server side to authenticate a client initiating a TFO connection. This document covers the details of exchanging data during TCP's initial handshake, the protocol for TFO cookies, potential new security vulnerabilities and their mitigation, and the new socket API.
See RFC here: https://tools.ietf.org/html/rfc7413

Configuration
This can't be configured on-the-fly at this point, it needs to be configured when the package is built using the following configuration parameters:

Code: Select all

--enable-tfo-client
--enable-tfo-server
Concerns addressed: speed

DNS block lists
Whether it's ads or malicious sites you want to block, unbound provides for black- and whitelists to fully control your (DNS) traffic.

Configuration
Setup a block list, for example by using the script from sfeakes: https://github.com/sfeakes/ipfire-scripts

PS: I still need to test this and make sure I can actually document something... ;)
Update: I've been informed that this will break DNSSEC functionality, so use at your own risk.

Concerns addressed: security, no ads

Questions
  1. Aimed at encrypted DNS point 1, is it correct to assume this file is used when unbound starts and is not there on vanilla installations?
    Yes, this file does not exist on vanilla installation and can be used to override settings.
  2. Also aimed at encrypted DNS point 1, why would you need to disable forwarders, that is exactly what the conf-file contains?
    It will disable any setup/WUI configured forwarders, which will enable the ones in the settings file(s).
  3. Aimed at encrypted DNS point 2, what good does it do to configure a whole lot of servers? I presume mostly just the top one (assuming they are recursive and will retrieve the entry when it's not there) will be used? Unless that one is not available, but that shouldn't happen too often, so more than two servers is possible, but will almost never be used.
    Unbound will randomly select from those servers, meaning it will divide the queries amongst those servers, further improving privacy.
  4. Aimed at encrypted DNS; when running a domain I just need to point my domain controller to the IPFire appliance, as opposed to my IPS's, right?
  5. Is this the correct command to create the tls-cert-bundle? -> cat /etc/ssl/certs/* > /etc/unbound/ca-bundle.pem
    See inline updates, the cert bundle was already there.
  6. What do the DNS settings in "setup\Network configuration\DNS and Gateway settings" mean? Will they be overwritten by the unbound config? Or are those for the IPFire instance itself, even though it might as well use the unbound server too?
I sure hope I'm making sense, it has become quite a write-up.

Thanks for all the responses (from which I will learn) in advance!
Attachments
unbound.txt
(20.1 KiB) Downloaded 25 times
Last edited by Saiyato on February 5th, 2019, 11:06 am, edited 24 times in total.
Image
Image

Saiyato
Posts: 36
Joined: October 9th, 2018, 6:55 pm

Re: DNS security hardening

Post by Saiyato » November 28th, 2018, 6:00 pm

Image
Image

ummeegge
Community Developer
Community Developer
Posts: 4773
Joined: October 9th, 2010, 10:00 am

Re: DNS security hardening

Post by ummeegge » November 28th, 2018, 6:56 pm

Hi Saiyato,
and thanks for writing all that together. As a result of some threads which you have also posted above, i tried also a little more in that topic. You can find in here --> viewtopic.php?f=50&t=21954 some further testings and also some encountered problems with the above configured scenario. This is a testing/development/also_information thread but the current setup there works for me. Changes in the initscript are still under working progress.

Some more infos from here.

Best,

UE
Image
Image

Saiyato
Posts: 36
Joined: October 9th, 2018, 6:55 pm

Re: DNS security hardening

Post by Saiyato » November 28th, 2018, 9:13 pm

Thanks, I just updated some parts, I must say I havent tested yet... when I quickly tested yesterday, my DNS was broken :(
So I must find the time to test it thorougly :)

Theres one other thing I don't understand, I will add it to the questions. When I configure unbound, what do the DNS settings in "setup\Network configuration\DNS and Gateway settings" mean? Will they be overwritten by the unbound config? Or are those for the IPFire instance itself, even though it might as well use the unbound server too?
Image
Image

ummeegge
Community Developer
Community Developer
Posts: 4773
Joined: October 9th, 2010, 10:00 am

Re: DNS security hardening

Post by ummeegge » November 29th, 2018, 5:59 am

Hi,
Saiyato wrote:
November 28th, 2018, 9:13 pm
Theres one other thing I don't understand, I will add it to the questions. When I configure unbound, what do the DNS settings in "setup\Network configuration\DNS and Gateway settings" mean? Will they be overwritten by the unbound config? Or are those for the IPFire instance itself, even though it might as well use the unbound server too?
this was one working topic since the first tries with the custom_forwarder in local.d ended up in a "local recursor" mode but did crashed also the entries in host.cgi (reported this in the linked thread) whereby i could localize the problem somewhere in the update_forwarders function of the initscript which is disabled in the patched version if 'CUSTOM_FORWARDERS = 0' and if 'forward-zone:' appears in a config file located under local.d. The DNS servers configured via "setup\Network configuration\DNS and Gateway settings" are still present and shown on the starting page of the WUI, in rare cases (if the time needed to be synchronize) the 'local recursor' mode comes back again (needs to be checked) and appears also in the WUI as such.
How this works: I think this is the point where "unbound-control" comes into the game. There was also in the first tries the need to execute

Code: Select all

unbound-control stop
unbound-control start
to use the custom_forwarders in local.d (has also been changed to only start while further testings). If the entry 'CUSTOM_FORWARDERS = 0' in /etc/sysconfig/unbound or if no config file in local.d have a 'forward-zone:' entry, unbound jumps back to the old configured DNS servers from "setup\Network configuration\DNS and Gateway settings" after an restart of unbound.

Another point, i won´t advise to use the patch of the initscript from my topic except for testing/development.
Saiyato wrote:
November 28th, 2018, 9:13 pm
Thanks, I just updated some parts, I must say I havent tested yet... when I quickly tested yesterday, my DNS was broken :(
So I must find the time to test it thorougly :)
Which configuration do you mean ? And what happens as your DNS broke ?

Best,

UE

EDIT:
Saiyato wrote:
November 28th, 2018, 5:14 pm
[*]
Aimed at encrypted DNS point 2, what good does it do to configure a whole lot of servers? I presume mostly just the top one (assuming they are recursive and will retrieve the entry when it's not there) will be used? Unless that one is not available, but that shouldn't happen too often, so more than two servers is possible, but will almost never be used.
One thing in this is surely redundancy but also randomization is here a point --> https://www.monperrus.net/martin/random ... s-requests . If i enable DoT, all configured servers appears in TCPick stream sniff which is different to the regular configuration (see here --> viewtopic.php?f=6&t=21866#p120276 ). "rrset-roundrobin: yes" is set in unbound.conf but seems to work only with DoT (may DoH too not sure about this).
Saiyato wrote:
November 28th, 2018, 5:14 pm
[*] Is this the correct command to create the tls-cert-bundle? -> cat /etc/ssl/certs/* > /etc/unbound/ca-bundle.pem
The bundle is already there --> https://cgit.ipfire.org/ipfire-2.x.git/ ... rtificates , just set the path to /etc/ssl/certs/ca-bundle.crt

drill is currently not available on IPFire but i will build it with a little more time (kdig is already there but do have some other dependencies)...
TCPick has been dropped but i do patched it (Debian patch set) --> https://lists.ipfire.org/pipermail/deve ... 03450.html and is not official available for 32 and 64bit platform --> https://people.ipfire.org/~ummeegge/TCPick/ . Am currently building it for ARM too...
Image
Image

Saiyato
Posts: 36
Joined: October 9th, 2018, 6:55 pm

Re: DNS security hardening

Post by Saiyato » November 29th, 2018, 3:55 pm

Long post alert!
ummeegge wrote:
November 29th, 2018, 5:59 am
this was one working topic since the first tries with the custom_forwarder in local.d ended up in a "local recursor" mode but did crashed also the entries in host.cgi (reported this in the linked thread) whereby i could localize the problem somewhere in the update_forwarders function of the initscript which is disabled in the patched version if 'CUSTOM_FORWARDERS = 0' and if 'forward-zone:' appears in a config file located under local.d. The DNS servers configured via "setup\Network configuration\DNS and Gateway settings" are still present and shown on the starting page of the WUI, in rare cases (if the time needed to be synchronize) the 'local recursor' mode comes back again (needs to be checked) and appears also in the WUI as such.
How this works: I think this is the point where "unbound-control" comes into the game. There was also in the first tries the need to execute

Code: Select all

unbound-control stop
unbound-control start
to use the custom_forwarders in local.d (has also been changed to only start while further testings). If the entry 'CUSTOM_FORWARDERS = 0' in /etc/sysconfig/unbound or if no config file in local.d have a 'forward-zone:' entry, unbound jumps back to the old configured DNS servers from "setup\Network configuration\DNS and Gateway settings" after an restart of unbound.
This is still a bit unclear to me, I will read into the script first, so I can actually understand all that is happening. ;)
ummeegge wrote:
November 29th, 2018, 5:59 am
Another point, i won´t advise to use the patch of the initscript from my topic except for testing/development.
Added a disclaimer in the steps, as stated above I'm not entirely up to speed on the script, so I need to organise a few things/information to understand it all. I have no problems reading in German, but finding the correct keywords can be troublesome for a non-native speaker.
ummeegge wrote:
November 29th, 2018, 5:59 am
Saiyato wrote:
November 28th, 2018, 9:13 pm
Thanks, I just updated some parts, I must say I havent tested yet... when I quickly tested yesterday, my DNS was broken :(
So I must find the time to test it thorougly :)
Which configuration do you mean ? And what happens as your DNS broke ?
Well, my DNS broke in the sense that I was unable to resolve any name anymore, note that this only happened after reboot. I'm starting to understand that the /etc/init.d/unbound script does more than just unbound stop/start. So I'm sure I made an error somewhere along the road and I'm pretty sure I needed to add the cert bundle. This needs retesting on my part, please ignore till further notice ;)
ummeegge wrote:
November 29th, 2018, 5:59 am
Saiyato wrote:
November 28th, 2018, 5:14 pm
[*]
Aimed at encrypted DNS point 2, what good does it do to configure a whole lot of servers? I presume mostly just the top one (assuming they are recursive and will retrieve the entry when it's not there) will be used? Unless that one is not available, but that shouldn't happen too often, so more than two servers is possible, but will almost never be used.
One thing in this is surely redundancy but also randomization is here a point --> https://www.monperrus.net/martin/random ... s-requests . If i enable DoT, all configured servers appears in TCPick stream sniff which is different to the regular configuration (see here --> viewtopic.php?f=6&t=21866#p120276 ). "rrset-roundrobin: yes" is set in unbound.conf but seems to work only with DoT (may DoH too not sure about this).
Thanks for the pointer, I will try to read and structure that information into a short statement to clarify it for the rest.
ummeegge wrote:
November 29th, 2018, 5:59 am
Saiyato wrote:
November 28th, 2018, 5:14 pm
[*] Is this the correct command to create the tls-cert-bundle? -> cat /etc/ssl/certs/* > /etc/unbound/ca-bundle.pem
The bundle is already there --> https://cgit.ipfire.org/ipfire-2.x.git/ ... rtificates , just set the path to /etc/ssl/certs/ca-bundle.crt
Noted and updated the post, thanks! I'm still swimming in information I need to structure, so this is of great help.
ummeegge wrote:
November 29th, 2018, 5:59 am
drill is currently not available on IPFire but i will build it with a little more time (kdig is already there but do have some other dependencies)...
TCPick has been dropped but i do patched it (Debian patch set) --> https://lists.ipfire.org/pipermail/deve ... 03450.html and is not official available for 32 and 64bit platform --> https://people.ipfire.org/~ummeegge/TCPick/ . Am currently building it for ARM too...
Awesome, I'll keep my eyes peeled, I like drill more than dig/nslookup. I use it quite frequently in Kali.
Image
Image

ummeegge
Community Developer
Community Developer
Posts: 4773
Joined: October 9th, 2010, 10:00 am

Re: DNS security hardening

Post by ummeegge » December 3rd, 2018, 8:25 am

Hi Saiyato,
as promised, in here --> https://people.ipfire.org/~ummeegge/ldns/ you can find ldns for ARM. Have used also '--with-examples' and '--with-pyldns' in configure so the following binaries:

Code: Select all

/usr/bin/drill
/usr/bin/ldns-chaos
/usr/bin/ldns-compare-zones
/usr/bin/ldns-config
/usr/bin/ldns-dane
/usr/bin/ldns-dpa
/usr/bin/ldns-gen-zone
/usr/bin/ldns-key2ds
/usr/bin/ldns-keyfetcher
/usr/bin/ldns-keygen
/usr/bin/ldns-mx
/usr/bin/ldns-notify
/usr/bin/ldns-nsec3-hash
/usr/bin/ldns-read-zone
/usr/bin/ldns-resolver
/usr/bin/ldns-revoke
/usr/bin/ldns-rrsig
/usr/bin/ldns-signzone
/usr/bin/ldns-test-edns
/usr/bin/ldns-testns
/usr/bin/ldns-update
/usr/bin/ldns-verify-zone
/usr/bin/ldns-version
/usr/bin/ldns-walk
/usr/bin/ldns-zcat
/usr/bin/ldns-zsplit
/usr/bin/ldnsd
/usr/lib/python2.7/site-packages/_ldns.so*
/usr/lib/python2.7/site-packages/ldns*.py
are also available.
This version do not includes the DNS-over-TLS patch --> https://portal.sinodun.com/stash/projec ... hes/browse so some switches like e.g. from here --> https://dnsprivacy.org/wiki/display/DP/Try+DNS-over-TLS do not work.

In here --> https://people.ipfire.org/~ummeegge/TCPick/ TCPick can also be found for ARM platform.

The uninstall.sh in both packages can also be used as such.

Best,

UE
Image
Image

ummeegge
Community Developer
Community Developer
Posts: 4773
Joined: October 9th, 2010, 10:00 am

Re: DNS security hardening

Post by ummeegge » December 7th, 2018, 3:17 pm

Hi,
two more things which i have currently in mind/testing and wanted to pin it here for a possible hardening/optimization discussion.

1) QNAME minimization: -> https://tools.ietf.org/html/rfc7816 . Tested with current IPFire core 125 and got a

Code: Select all

"NO - QNAME minimisation is NOT enabled on your resolver :("
Even "qname-minimisation: yes" has been set in unbound.conf. By adding

Code: Select all

  qname-minimisation-strict: yes
  harden-below-nxdomain: yes
(via custom DoT config file in local.d), a

Code: Select all

dig txt qnamemintest.internet.nl +short
delivers

Code: Select all

a.b.qnamemin-test.internet.nl.
"HOORAY - QNAME minimisation is enabled on your resolver :)!"
2) TCP Fast Open: --> https://lwn.net/Articles/508865/ --> https://tools.ietf.org/html/rfc7413 which might also be an idea for DoT ?

Some new ;) thoughts from here.

Best,

UE
Image
Image

Saiyato
Posts: 36
Joined: October 9th, 2018, 6:55 pm

Re: DNS security hardening

Post by Saiyato » January 4th, 2019, 10:23 am

Thanks for the updates UE, I've added them to the main post. I must say I haven't tested the tools yet, I'm fairly new to the IPFire environment in terms of installing software, I'm used to apt-get or building from git (sometimes), so I need to check how this ecosystem works exactly.

I have in the meantime successfully tested QNAME minimisation and DNSSEC on the appliance itself, so I presume if my computer queries IPFire the same applies.

Right now I have to determine how to configure DNS in my domain, since I'm running a domain at home I need the domain controller for DNS, but I want the clients to use IPFire for all internet related traffic. I need to read into the DNS server on Windows server and see if I can configure it in such a way that the domain is working as intended, with some internal services, which are using DNS from the domain controller AND all internet queries are routed through IPFire.

I sure hope I'm making sense now.

When I figure that out, I can read into DoT and configure that in such a way that the clients also query IPFire using DoT. This is probably not possible out-of-the-box and I think I will need Stubby for that.... Anyways, still some miles to go. ;)
Image
Image

Saiyato
Posts: 36
Joined: October 9th, 2018, 6:55 pm

Re: DNS security hardening

Post by Saiyato » January 4th, 2019, 10:52 am

Just another thing that comes to mind, if unbound is a recursive resolver, why would you want to configure upstream servers?
Is that for speed purposes? I mean if unbound can check all the way up to the root servers, then you have your DNSSEC and QNAME minimisation right there, if you use upstream servers, there's no way of knowing. Or am I going about this all wrong now?

Without forwarders (and not in cache):
client -> unbound (IPFire) -> root server > tld server > other authoritative name server

With forwarders (and not in cache):
client -> unbound (IPFire) -> configured forward server

Which means you trust the forward server more than unbound _or_ the forward server is quicker (larger cache/quicker responses for the whole round trip).

Or... should I, for my situation, use the resolver, but configure my own domain as a zone that is forwarded elsewhere (e.g. my domain controller)? I'm trying to understand why many people would like to configure for example cloudflare as forward zones with DoT as opposed to having unbound resolve everything.
Image
Image

ummeegge
Community Developer
Community Developer
Posts: 4773
Joined: October 9th, 2010, 10:00 am

Re: DNS security hardening

Post by ummeegge » January 14th, 2019, 3:05 pm

Hi Saiyato,
Saiyato wrote:
January 4th, 2019, 10:23 am
Thanks for the updates UE, I've added them to the main post. I must say I haven't tested the tools yet, I'm fairly new to the IPFire environment in terms of installing software, I'm used to apt-get or building from git (sometimes), so I need to check how this ecosystem works exactly.
packages which are not provided by Pakfire behaves there a little different. If you have *.ipfire packages which are not in(un)stalled via Pakfire just move them to /opt/pakfire/tmp , you can unpack them with an 'tar xvf {PACKAGENAME}' and install them with an './install.sh', Pakfire have an own routine for this. Normally i modify self compiled packages so the uninstall.sh can also be used in the same way also without Pakfire with an simple './uninstall.sh' so all should be uninstalled then.
Saiyato wrote:
January 4th, 2019, 10:23 am
I have in the meantime successfully tested QNAME minimisation and DNSSEC on the appliance itself, so I presume if my computer queries IPFire the same applies.
You won´t need 'harden-below-nxdomain: yes', for a functioning QNAME minimization, have also heard that 'harden-below-nxdomain: yes' can lead to problems on specific configurations.
Saiyato wrote:
January 4th, 2019, 10:23 am
Right now I have to determine how to configure DNS in my domain, since I'm running a domain at home I need the domain controller for DNS, but I want the clients to use IPFire for all internet related traffic. I need to read into the DNS server on Windows server and see if I can configure it in such a way that the domain is working as intended, with some internal services, which are using DNS from the domain controller AND all internet queries are routed through IPFire.
Do you mean something like this --> https://wiki.ipfire.org/configuration/n ... dnsforward ?
Saiyato wrote:
January 4th, 2019, 10:23 am
When I figure that out, I can read into DoT and configure that in such a way that the clients also query IPFire using DoT. This is probably not possible out-of-the-box and I think I will need Stubby for that.... Anyways, still some miles to go. ;)
You won´t need stubby for DoT since unbound can be used for this even some features are not implemented yet, for more informations take a look into here --> https://dnsprivacy.org/wiki/display/DP/ ... ion+Status .
Saiyato wrote:
January 4th, 2019, 10:52 am
Just another thing that comes to mind, if unbound is a recursive resolver, why would you want to configure upstream servers?
Is that for speed purposes? I mean if unbound can check all the way up to the root servers, then you have your DNSSEC and QNAME minimisation right there, if you use upstream servers, there's no way of knowing. Or am I going about this all wrong now?
My current intend is DNS-over-TLS whereby the Root servers do not provide such.

Current config made with your new WUI layout ;-) which i pretty much like (great work) even some formatting stuff are currently not as it should, but nevermind... :
Image

Script for kdigging --> https://gitlab.com/ummeegge/dot-for-ipf ... est_tls.sh but also TLSv1.3 (new and currently not yet released OpenSSL-1.1.1a) points the following out:

Code: Select all


==============================================================================================================================================

;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(81.3.27.54), port(853), protocol(TCP)
;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-bundle.crt'
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=rec1.dns.lightningwirelabs.com
;; DEBUG:      SHA-256 PIN: pOvVkJSj6rWNPM0vR3hoJr/21kZI6TfImhowIEdcEUQ=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
;; DEBUG:      SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.2)-(ECDHE-X25519)-(ECDSA-SHA512)-(CHACHA20-POLY1305)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 49321
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; google.com.         		IN	A

;; ANSWER SECTION:
google.com.         	19	IN	A	216.58.206.14

;; Received 55 B
;; Time 2019-01-14 15:32:56 CET
;; From 81.3.27.54@853(TCP) in 26.3 ms

Exit status: 0

==============================================================================================================================================

;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(146.185.167.43), port(853), protocol(TCP)
;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-bundle.crt'
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=securedns.eu
;; DEBUG:      SHA-256 PIN: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
;; DEBUG:      SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
;; DEBUG:  #3, CN=securedns.eu
;; DEBUG:      SHA-256 PIN: h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g=
;; DEBUG:  #4, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
;; DEBUG:      SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 22000
;; Flags: qr rd ra; QUERY: 1; ANSWER: 6; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR
;; PADDING: 329 B

;; QUESTION SECTION:
;; google.com.         		IN	A

;; ANSWER SECTION:
google.com.         	112	IN	A	74.125.68.100
google.com.         	112	IN	A	74.125.68.101
google.com.         	112	IN	A	74.125.68.138
google.com.         	112	IN	A	74.125.68.113
google.com.         	112	IN	A	74.125.68.102
google.com.         	112	IN	A	74.125.68.139

;; Received 468 B
;; Time 2019-01-14 15:33:01 CET
;; From 146.185.167.43@853(TCP) in 69.9 ms

Exit status: 0

==============================================================================================================================================

;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(89.234.186.112), port(853), protocol(TCP)
;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-bundle.crt'
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=dns.neutopia.org
;; DEBUG:      SHA-256 PIN: wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
;; DEBUG:      SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 32625
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR
;; PADDING: 409 B

;; QUESTION SECTION:
;; google.com.         		IN	A

;; ANSWER SECTION:
google.com.         	55	IN	A	172.217.18.110

;; Received 468 B
;; Time 2019-01-14 15:33:07 CET
;; From 89.234.186.112@853(TCP) in 96.0 ms

Exit status: 0

==============================================================================================================================================

;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(145.100.185.17), port(853), protocol(TCP)
;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-bundle.crt'
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=dnsovertls2.sinodun.com
;; DEBUG:      SHA-256 PIN: NAXBESvpjZMnPWQcrxa2KFIkHV/pDEIjRkA3hLWogSg=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
;; DEBUG:      SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 42968
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR
;; PADDING: 409 B

;; QUESTION SECTION:
;; google.com.         		IN	A

;; ANSWER SECTION:
google.com.         	300	IN	A	172.217.17.110

;; Received 468 B
;; Time 2019-01-14 15:33:12 CET
;; From 145.100.185.17@853(TCP) in 29.7 ms

Exit status: 0

==============================================================================================================================================

;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(185.49.141.37), port(853), protocol(TCP)
;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-bundle.crt'
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=getdnsapi.net
;; DEBUG:      SHA-256 PIN: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
;; DEBUG:      SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 16428
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; google.com.         		IN	A

;; ANSWER SECTION:
google.com.         	206	IN	A	216.58.206.14

;; Received 55 B
;; Time 2019-01-14 15:33:17 CET
;; From 185.49.141.37@853(TCP) in 80.7 ms

Exit status: 0

==============================================================================================================================================

;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(99.192.182.200), port(853), protocol(TCP)
;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-bundle.crt'
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, OU=Domain Control Validated,OU=PositiveSSL Wildcard,CN=*.tenta.io
;; DEBUG:      SHA-256 PIN: nPzhfahBmQOFKbShlLBymTqPtZY31bPpKFnh0A86ys0=
;; DEBUG:  #2, C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO ECC Domain Validation Secure Server CA
;; DEBUG:      SHA-256 PIN: EohwrK1N7rr3bRQphPj4j2cel+B2d0NNbM9PWHNDXpM=
;; DEBUG:  #3, C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO ECC Certification Authority
;; DEBUG:      SHA-256 PIN: 58qRu/uxh4gFezqAcERupSkRYBlBAvfcw7mEjGPLnNU=
;; DEBUG:  #4, C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root
;; DEBUG:      SHA-256 PIN: lCppFqbkrlJ3EcVFAkeip0+44VaoJUymbnOaEUk7tEU=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.2)-(ECDHE-SECP521R1)-(ECDSA-SHA256)-(CHACHA20-POLY1305)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 6544
;; Flags: qr rd ra; QUERY: 1; ANSWER: 6; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 512 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; google.com.         		IN	A

;; ANSWER SECTION:
google.com.         	300	IN	A	108.177.15.138
google.com.         	300	IN	A	108.177.15.113
google.com.         	300	IN	A	108.177.15.102
google.com.         	300	IN	A	108.177.15.100
google.com.         	300	IN	A	108.177.15.101
google.com.         	300	IN	A	108.177.15.139

;; Received 135 B
;; Time 2019-01-14 15:33:23 CET
;; From 99.192.182.200@853(TCP) in 25.9 ms

Exit status: 0

==============================================================================================================================================

;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(199.58.81.218), port(853), protocol(TCP)
;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-bundle.crt'
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=dns.cmrg.net
;; DEBUG:      SHA-256 PIN: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
;; DEBUG:      SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 29919
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR
;; PADDING: 409 B

;; QUESTION SECTION:
;; google.com.         		IN	A

;; ANSWER SECTION:
google.com.         	300	IN	A	172.217.0.238

;; Received 468 B
;; Time 2019-01-14 15:33:28 CET
;; From 199.58.81.218@853(TCP) in 127.8 ms

Exit status: 0

==============================================================================================================================================

;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(159.69.198.101), port(853), protocol(TCP)
;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-bundle.crt'
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=dot-de.blahdns.com
;; DEBUG:      SHA-256 PIN: xA4eoRqEmI6Ke/y7bicySNXdckMeWe1tYAMnbF8bAdc=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
;; DEBUG:      SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 21862
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR
;; PADDING: 409 B

;; QUESTION SECTION:
;; google.com.         		IN	A

;; ANSWER SECTION:
google.com.         	139	IN	A	172.217.17.46

;; Received 468 B
;; Time 2019-01-14 15:33:33 CET
;; From 159.69.198.101@853(TCP) in 61.6 ms

Exit status: 0

==============================================================================================================================================

(Encrypted SNI needs to be checked) from my feeling and point of view, DoT is faster then unencrypted DNS but i also use an modified unbound (with TCP-Fast-Open) and the randomization works pretty well, as you can see the 'ad' flag is set so DNSSEC works also for all configured servers.

Again some thoughts from here.

Best,

UE
Image
Image

Post Reply