Question about DNS over HTTPS

Network DNS
21

This is where RPZ zone shines with a DoH block list.

True. this is to prevent modification of your DNS requests and prevent ease dropping..

One side affect is your DNS provider gets a better finger print of the DoH user.

22

Hello,
Did you tested IPS as tool to block usage of DoH?

I saw that Peter Russell jpgpi250 provides DOH IPS rules in his repository

The DOH IPS rules provided by Peter Russell are here

Some guidelines (but for pfsense?!) are in the Redme - DoH section

As far as I see, Emerging rules donā€™t seem to be designed to block DoH as a whole.
All rules that contain DNS_over_HTTPS are inside emerging-info.rules - definitely not for blocking DoH.

Late edit: it seems it works to use IPS for bocking DoH
I have added ā€œPeter Russell jpgpi250 DoH rulesā€ in ipfire config file ruleset-sources

My addition to /var/ipfire/suricata/ruleset-sources:

#Peter Russell jpgpi250 DoH rules.

    prussell => {
            summary => "Peter Russell jpgpi250 DoH rules",
            website => "https://github.com/jpgpi250/piholemanual/tree/master?tab=readme-ov-file#doh",
            tr_string => "russell green doh rules",
            requires_subscription => "False",
            dl_url => "https://raw.githubusercontent.com/jpgpi250/piholemanual/master/DOH/DOH.rules",
            dl_type => "plain",
    },

image
image971Ɨ303 18.9 KB

Then disabled RPZ for 60 seconds and forced browser to use DoH by using page DNS over HTTPS

Result: IPS logs [/var/log/suricata/fast.log] started to show suricata was blocking DoH. And the page did not got any answersā€¦

image
image1549Ɨ1033 154 KB

23

thanks for the links :+1:

tl;dr
In short, we will simply block all the IPā€™s of DoH DNS servers on the firewall. Since DoH servers come and go all the time, it is hard to keep track of all DoH servers. Several contributers dedicate time to creating lists with known DoH servers, unfortunately, most of these lists are incomplete or not maintained.
source:
https://jpgpi250.github.io/piholemanual/doc/Block%20DOH%20with%20pfsense.pdf
:slot_machine:

24

Same document contains at title 11 (DoH) this recommendation

It may be wise to implement the suricata rules, even if your firewall is configured as
described in this document. You probably already have created the exception aliases and rules, this to ensure the websites, using resources from the same IP as a known DoH server, are accessible. A client / app may be attempting to use DoH, due to the exceptions this may work. The suricata rules provides protection, if the client uses standard (port 53) DNS queries to get the IP for the DoH server.

25

Protection for DNS queries of DoH servers are better managed by RPZ (on the level of DNS resolving).
Just try the experimental addon.

26

Not lately but it was blocking IPFire for accessing some providers a whileago. Most likely itā€™s missing many DNS providers anyway so itā€™s not good for completely blocking DoH/DoT.

Yes that rule set is named info but anything detected there will be blocked if suricata isnā€™t running in Monitor traffic only mode.

27

The definition for the info rule set is

Infoā€“This category is for signatures to help provide audit level events that are useful for correlation and identifying interesting activity which may not be inherently malicious but is often observed in malware and other threats, for example downloading an Executable over HTTP by IP address rather than domain name.

28

image
image1200Ɨ686 422 KB

No offense to anyone but DoH was the one and only reason @Jon started working on the very popular RPZ addon a few years ago.

What complicates this approach is how to block DoH without blocking DoT,

In my case some of the DoT servers are using the same IP as DoH.

I am wondering if QUiC posing a similar threat

29

It will and will require same approach as for DoH: RPZ and maybe IPS (if the client never laung a DNS request to get the IP address of the DoH server - it simply initiate the DoH connection from its internal database of IP addresses for DoH servers)

At the moment the RFC9250 is in Proposed Standard state (since May 2022)

30

After we figure out DoH and QUIC, we might have to take on an interesting one: Ether Hiding. Basically using Smart contracts as Bullet-Proof Hosting..

How EtherHiding Works

EtherHiding emerged in September 2023 as a key component in the financially motivated CLEARFAKE campaign (UNC5142), which uses deceptive overlays, like fake browser update prompts, to manipulate users into executing malicious code.

EtherHiding involves embedding malicious code, often in the form of JavaScript payloads, within a smart contract on a public blockchain like BNB Smart Chain or Ethereum. This approach essentially turns the blockchain into a decentralized and highly resilient command-and-control (C2) server.

Source: Google Threat Intelligence
31

Hello, one approach we could take is to inspect headers. Iā€™m not fully familiar with the extent of IPFireā€™s capabilities for this, but an intermediate proxy may be able to perform the inspection.

DNS-over-HTTPS requests typically include recognisable header patterns. This method may not be 100% effective, but it could work in many cases. We could evaluate creating a filter that looks for these headers and request patterns:

  • Content-Type: application/dns-message (DoH binary DNS over HTTPS)

  • Content-Type: application/dns-json (DoH JSON responses)

  • Accept: application/dns-json

  • Accept: application/dns-message

  • Method/URI: GET /dns-query?q=ā€¦

  • Method/URI: POST /dns-query

32

Hello Da,

it is all encrypted inside a TLS connection. None of these options will work as the firewall wonā€™t be able to decrypt the stream.

We are currently working on options how to reliably implement DoH blocking against a known list of services.