"Block DNS Tunneling"

[Fawkesguy]

Anyone know when we might see this feature implemented?

[mimugmail]

I'd guess never since DoT and DoH

[chemlud]

Hmm, for DoT you simply block anything on port 853, but for DoH you need a list of DNS servers (which will hardly be complete and always up to date).

So: basically the DoH protocol killed DNS "security"/surveilance (choose which side you're on ;-) )

[Supermule]

Disable port 853 and launch a MITM using Unbound and only access via  port 53.

Force your clients to use root DNS via unbound and your fine.

[chemlud]

Disable port 853 and launch a MITM using Unbound and only access via  port 53.

Force your clients to use root DNS via unbound and your fine.

MITM using unbound? How should that prevent DNS-over-HTTPS?

[Greelan]

DNS tunneling is a potential issue even with normal DNS, if what the OP means is using the DNS protocol to pass malicious data in DNS responses. I guess Suricata could help with that by providing alerts for or blocking potentially malicious domains

[Supermule]

Disable port 853 and launch a MITM using Unbound and only access via  port 53.

Force your clients to use root DNS via unbound and your fine.

MITM using unbound? How should that prevent DNS-over-HTTPS?

Do we agree that using Unbound as a DNS resolver and the clients using it, will reveal the DNS requests and therefore beeing able to block the dangerous ones??

Your HTTPS DNS request still needs a GW and a resolver.

[Fawkesguy]

I'd guess never since DoT and DoH

Then I wonder why they put these in the GUI?

[chemlud]

Your HTTPS DNS request still needs a GW and a resolver.

Hmm, how do you want to pick out a DNS request from your port 443 traffic? You would have to block all DNS-over-HTTPS servers, which will be hard to maintain...

[chemlud]

I'd guess never since DoT and DoH

Then I wonder why they put these in the GUI?

That's fawke news ;-p

[Fawkesguy]

That's fawke news ;-p

LOL, probably!  It seems impossible, but since the developers included it in the GUI, I figured I'd ask.   :)

[Greelan]

They are Sensei menu items. Ask the Sensei guys (they also spend time here)

[mimugmail]

Yeah, what I meant was doing this with open source in a stable manner. Blocking 853 doesn't help when you have a VPS and using a different port. Also a growing list of public DoH servers in not trustworthy since you can host your DNScrypt server in a VPS.

[mb]

Quite a productive discussion here. Thanks to all who contributed.

There are two types of "tunnelling" involving DNS; both of which are a topic of interest since they might be used for tunnelling malicious traffic:

1. Tunnelling of Internet traffic over DNS protocol
2. Tunnelling of DNS protocol over HTTPS protocol

Former: attackers disguise their traffic as if it was a legitimate DNS traffic. Latter, they disguise their DNS traffic over HTTPS so that network detection/prevention mechanisms do not have visibility over their DNS activity.

With TLS 1.3, where the SNI information can also be encrypted, DNS visibility had become important; however, with DoH, this visibility is also lost, as Michael mentioned, they can easily launch their DoH over a $5/mo VPS.

The "Block DNS Tunnels" option in the Sensei Security menu was meant to solve the first type, meaning detecting Internet traffic which is disguised as DNS traffic. We've introduced an implementation which is dealing with this. If you see "Non-standard DNS traffic" in your Sensei Live Session Logs (Connection Details / Tags) -> , this is a powerful indication of such activity. This feature is still under development; and still needs further testing before we announce the public availability).

Having said that, based on our discussions with Sensei users/customers; We've seen that the latter has become more of  a pressing problem. A malware communicating with its C&C via DoH and TLS 1.3 + SNI encryption can easily bypass all detection mechanisms. No matter which big brand you are using. This is an industry problem right now.

So we've also moved our focus to the second type.

What is our approach to this problem:

Our methodology can be summarized as "Rise from where you fell": gaining visibility where we lost it originally.
Technically speaking, we want to provide the user with the ability to:

1. create acceptable use policies with regard to DoH protocol
2. enforce all DNS traffic over his/her own DoH/DoT system.
3. gain visibility over encrypted/cleartext traffic which is destined for unknown/new/low-reputation sites (TLS inspection capability)

All of the items are being actively worked on right now. We hope to roll them out this year.

[Fawkesguy]

Thank you for that very thorough reply.  The ability to block DoH will be great, when it becomes available.   :)