Filtering/Blocking & or AppID detection of DNS over HTTPS (DoH) or DNS over TLS (DoT) via Snort/Suricata
-
@JonathanLee if DoH providers encrypt the SNI, what use is snort?
Blocking is always wack-mole. The best way to effectively block all DoH is a combination of proactive lists and MITM. Pfsense can’t do the latter -
@JonathanLee said in Filtering/Blocking & or AppID detection of DNS over HTTPS (DoH) or DNS over TLS (DoT) via Snort/Suricata:
It’s all got to work the same for that protocol, it’s got to be something that can be used to create a significant signature to detect if DoH is being used right?
That question will go out of the window as soon as you know what TLS is. It's a quasi random bit stream. This means that in the TCP packet, the usual packet header with source port and IP, and destination port and IP, and some flags are 'visible'. The payload, 1500 bytes or less, is a perfect random number.
There is no "app ID flag" or something like that, as me, you and everybody else would not like that at all.
There is two important markers, though : the destination port will always be 853, and the protocol will be TCP.
So if you want to filter all DoH traffic, you know now what to do.@JonathanLee said in Filtering/Blocking & or AppID detection of DNS over HTTPS (DoH) or DNS over TLS (DoT) via Snort/Suricata:
to detect DoH on the IPS IDS
As @bmeeks already said above : just forget it.
Yes, it can be done if you except a huge amount of exceptions that can't be handled 'MITM', and this list won't be static over time, you will have to visit your "MITM list/setup" daily to handle all the 'new exceptions' and 'old exceptions that use now new IPs and hostname' so they have to be changed again ... and again .... up until the day you throw MITM out of the window.To only real works around is what 3 letter agencies do : filter at the source, or destination.
But for me and you, filter at the destination = example : facebook.com, is plain impossible.
So : that leaves you the source. But will the user, if it isn't you, be cooperative ? Will they accept the proxy settings on their device ? Would you ? For them, il will be pain up untill the day they leave your network, and look else where for their daily doses of "Internet bits".@shon said in Filtering/Blocking & or AppID detection of DNS over HTTPS (DoH) or DNS over TLS (DoT) via Snort/Suricata:
This seems like an interesting problem for the industry to solve.
It has been solved.
Security and privacy for everyone. No exceptions. Done.Even if you are the president of "any country on planet earth", you can't sneak peak. I know, this is a bold statement, but is rather easy to prove. There are many (to many) good Youtube video's that explain "TLS" from A to Z. It's hard, but the basic principles are quiet easy to understand.
-
@Gertjan yes !! So there are makers. This DoH list grows bigger every day, every day it’s a new one I notice pop up, yes like wack-o-mole. It appears that some OS set systems to utalize DoH as soon as you administer any manually entered DNS address. So many questions start with 1 if we can see a DoH why can’t we program something to spot it automatically. 2 if Snort does AppID and can automatically detect signatures all we would need is some marker to just set Snort to block it.
Let’s agree the floodgates of QUIC and HTTP3 with DoH over HTTP3 are open, I noticed Apple is now working on code for HTTP3 that you can’t turn off. This is the future, and no longer experimental yet they put the cart before the horses so cybersecurity mitigation has still has not caught up.
Squid I noticed does have people working on HTTP3 QUIC. Even PaloAlto AppDetect has found a way to mitigate the HTTP3 risk, prior they said to block it. Squid can do MITM
DoH and QUIC or DoH over QUIC it’s like they tossed all security measures out the window.
Why even allow us to set DNS if the systems don’t fully follow our admin settings? I can’t even turn off the DoH stuff on Apple outside of blocking it. I wonder what the gantt chart would look like for a mitigation timeframe on how to mitigate this situation outside of wack-o-mole.
Port 853 is DNS over TLS
Port 443 TCP is DNS over HTTPS or DoH
Port 443 UDP is DNS over HTTPS3 or QUIC or DoH 2.0It’s not just DoH it’s the jump to UDP with the rapid deployment of HTTP3.
You can see it all over proxies going on. Yes I can block it Wack-O-Mole it but for how long? The flooding of cyber attacks and other issues seen on the news will just continue. Security appliances have been around as long as the internet, all protocols have ways to enact security.
-
@JonathanLee
The ultimate solution is MITM.
Whether that's done on the firewall or the endpoint is up to the Network admin.Today/Present, there is no effective way on pfSense to block DoH
-
@michmoor Squid has been working on ways to improve code for HTTP3 (internet with 443 over just UDP) that would utilize MITM to detect and monitor traffic. Again not all countries allow this type of security measures. I wonder how Palo Alto did this they found a way again they also require certificates installed so leads me to think MITM before the ink dried, they originally said block UDP over port 443 and explained it, today it’s a different path. It’s not like it’s invincible, we remember the Titanic unsinkable, and the issues with the SS great eastern and the propellers first use of steam engines on sail boats. It’s new and they will say it’s invincible but we know it can be seucure also.
Make sure to upvote
-
Palo Alto advises to block UDP/443 to force sessions to run on TCP/443 so that they can be decrypted.
-
@JonathanLee said in Filtering/Blocking & or AppID detection of DNS over HTTPS (DoH) or DNS over TLS (DoT) via Snort/Suricata:
I wonder how Palo Alto did this they found a way again they also require certificates installed ...
Easy, in the good old days, our browser were very permissive.
Example : we're visiting facebook.com using https.
The one pick up the line on the other side, is a web server NOT using a facebook.com certificate (the real facebook.com webserver !), but our local squid/whatever web server app. Our browser would signal this in the address/url bar, of course, but tjhere was no such thing as a big huge screen with a big error message. Back then, nobody was really looking at the address bar / url anyway.
So, 'it worked' ...@michmoor said in Filtering/Blocking & or AppID detection of DNS over HTTPS (DoH) or DNS over TLS (DoT) via Snort/Suricata:
Today/Present, there is no effective way on pfSense to block DoH
Filtering isn't t really needed, I guess.
DoH == a DNS access. DNS servers are not hidden, they are known. If they are unknown, how could my device be made aware of them ? Sure as h#ll it won't be my pfSEnse giving my LAN devices the DoH IP addresses. Probably by an OS update, or some other OS build in list. or a device user insisting with a static setup, to use such DoH servers.
But, eventually, as soon as they exist, in a couple of days, they become known.
After all, the '13' root server, the many TLD servers, and of course, all the domain name servers, are known. These guys can't have 'dynamic IPs'.I believe - but I can't be sure - that DNS servers using DoH won't doing be doing https at the same time, as both will be using port TCP 443, and only one service can listen on a give port - same protocol.
So, DoH, using port TCP 443 will use it's own dedicated IP. And as said, these will get known fast, get listed, and this, thanks to initiatives like pfBlockerng, get blocked, us (admins) doing .... more important things like .... drinking a beer ? ;)@JonathanLee said in Filtering/Blocking & or AppID detection of DNS over HTTPS (DoH) or DNS over TLS (DoT) via Snort/Suricata:
HTTP3 (internet with 443 over just UDP)
Dono what that is - why I would need it, but I'm going to look that up.
This will, and I see it coming already, mean that DoH will also be using TCP and UDP ... -
@Gertjan said in Filtering/Blocking & or AppID detection of DNS over HTTPS (DoH) or DNS over TLS (DoT) via Snort/Suricata:
Dono what that is - why I would need it, but I'm going to look that up.
This will, and I see it coming already, mean that DoH will also be using TCP and UDP ...This was my major concern when Google started testing this as experimental, yes Palo Alto just recommended blocking it but Apple also ran experimental tests with it and they did start using it I can see it in pcap files it will test it over and over after fail back. So future stuff will need a path to secure this soon. It is amazing how fast this stuff moved and IPv6 took over 30 years and is still not fully active but HTTP3 it was like 3 years and it is live and running
-
Hello, at the moment in big company, this is Zscaler which deals with preventing DOH
https://www.zscaler.com/blogs/product-insights/stopping-dns-over-https-doh-abuseI've just tested DOH activation and yes Zscaler is preventing it with proxing internet flux on each computer.
This tuto is clear on how activating DOH on chrome or Firefox and test it.
https://www.zdnet.fr/pratique/comment-activer-dns-over-https-doh-dans-google-chrome-39890301.htm
https://www.zdnet.fr/pratique/pratique-comment-activer-dns-over-https-doh-dans-firefox-39887257.htmFor myself,
i force DNS traffic to outbound only via my DNS server to upstream public DNS
prevent DNS client query 53 to outbound
restrict 5353 and 853
pfBlockerNG blocking with DOH list
restricting LAN outbound of UDP traffic on 443Watching other msg, i think of UDPing my traffic too, just to prevent provider from collecting datas, but if they see ip source and dest ip what's the point of the privacy on DNS requests !?
A+
-
@abds69 said in Filtering/Blocking & or AppID detection of DNS over HTTPS (DoH) or DNS over TLS (DoT) via Snort/Suricata:
with proxing internet flux on each computer
Great ! To circumvent DoH .... let's proxy each LAN device ....
Isn't that like : to prevent my gaz cylinder from exploding during a fire, let's throw a nuke on it.
Btw : the nuke doesn't come for free (neither).@abds69 said in Filtering/Blocking & or AppID detection of DNS over HTTPS (DoH) or DNS over TLS (DoT) via Snort/Suricata:
restricting LAN outbound of UDP traffic on 443
Isn't DoH using TLS thus TCP ?
You should block also TCP port 443 (and 80)
