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.
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.
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",
},
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âŚ
thanks for the links ![]()
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
![]()
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.
Protection for DNS queries of DoH servers are better managed by RPZ (on the level of DNS resolving).
Just try the experimental addon.
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.
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.
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