DNS security hardening

General questions.
Post Reply
Saiyato
Posts: 29
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 two measures that can be distinguished at this point:
1. DNSSEC
2. Encrypted DNS queries (DNS over TLS or HTTPS)

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 it by calling unbound:

Code: Select all

/etc/init.d/unbound test-name-server {ADDRESS}
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?

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-forward
    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.

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?
  2. Also aimed at encrypted DNS point 1, why would you need to disable forwarders, that is exactly what the conf-file contains?
  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.
  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
  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 5 times
Last edited by Saiyato on November 29th, 2018, 3:24 pm, edited 11 times in total.
Image

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

Re: DNS security hardening

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

Image

ummeegge
Community Developer
Community Developer
Posts: 4676
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
Image

Saiyato
Posts: 29
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

ummeegge
Community Developer
Community Developer
Posts: 4676
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
Image

Saiyato
Posts: 29
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

ummeegge
Community Developer
Community Developer
Posts: 4676
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
Image

ummeegge
Community Developer
Community Developer
Posts: 4676
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
Image

Post Reply

Who is online

Users browsing this forum: No registered users and 10 guests