Filtering/Blocking & or AppID detection of DNS over HTTPS (DoH) or DNS over TLS (DoT) via Snort/Suricata
-
Hey Everyone,
The use case is I would like to identify (alert), and or block DoH and DoT traffic from leaving my network LAN => WAN my network if possible either through Snort or Suricata app identification.
I believe, but cannot confirm whether I can configure Snort/Suricata via AppID (Layer 7 Application identification) to examine outbound HTTPS traffic for genuine HTTPS packets, versus an injected DNS request via DoH.
I believe I have to do the following:
- SquidProxy (Decrypt SSL traffic)
- Setup Snort or Suricata to identify/fingerprint the any DoH and or DoT traffic going over port 443 Outbound
I'm running the following services:
pfBlockerNG (DNSBL with Pihole lists, and GeoIP blocking)
Snort (connectivity mode) with the following AppID rules
- openappid-collaboration.rules
- openappid-file_transfer.rules
- openappid-messaging.rules
- openappid-remote_access.rules
- openappid-social_networking.rules
- openappid-vpn_tunneling.rules
- openappid-webbrowser.rules
I setup my Firewall rule-sets to do the following:
- LAN Ruleset
- Anti-Lock Out Rule
- Allow LAN to LAN only for DNS queries
- Allow HTTP Outbound
- Allow HTTPS Outbound
- Block all Outbound (TCP/UDP)
- Floating Rulesets
- *pfBlocker permit/deny aliases (preconfigured by pfBlockerNG)
I'm running an SG-1100 and with around 60-115M free, so maybe I can just look for improper HTTPS requests generally speaking with DoH and DoT via appID only too, but I'm not sure whether those signatures exist yet either.
Thanks
-
@shon said in Filtering/Blocking & or AppID detection of DNS over HTTPS (DoH) or DNS over TLS (DoT) via Snort/Suricata:
Hey Everyone,
The use case is I would like to identify (alert), and or block DoH and DoT traffic from leaving my network LAN => WAN my network if possible either through Snort or Suricata app identification.
I believe I have to do the following:
- SquidProxy (Decrypt SSL traffic)
- Setup Snort or Suricata to identify/fingerprint the any DoH and or DoT traffic going over port 443 Outbound
This won't work because Snort and Suricata both sit at a point in the packet chain where they can never see decrypted SSL traffic. When you run the Squid Proxy on the firewall, then it gets inbound packets AFTER Snort or Suricata have already seen them.
The IDS/IPS packages get network packets directly off the NIC before those packets are processed by the remainder of the networking kernel and firewall engine. So viewed from your LAN input, for example, packets from LAN hosts come out of the NIC driver and go directly to Snort or Suricata. If running in Legacy Blocking Mode, a copy of the packet goes to Snort or Suricata and the original packet goes to the firewall engine in the pfSense kernel. If running with Inline IPS Mode (Suricata), then the packet from the NIC goes to Suricata, and if passed by Suricata, then goes to the pfSense kernel and the firewall engine. But in either mode the Squid Proxy would not yet have decrypted the packets when they pass through the IDS/IPS engine.
You could do this with some very complicated routing and multiple proxies, but is it really worth all the headache? End-to-end encryption is the death knell for deep packet inspection. While great for privacy, it is also a double-edged sword because now organizations can't effectively police the usage of their network by users. With DoH and DoT you can't even see DNS requests anymore.
-
To block DoH request you can use pfBlockerNG-devel with these feeds:
https://heuristicsecurity.com/dohservers.txt
https://raw.githubusercontent.com/bambenek/block-doh/master/doh-hosts.txt
https://raw.githubusercontent.com/oneoffdallas/dohservers/master/list.txtand Firefox DoH blocking feature:
You can also block all public DNS IPs with this feed:
https://public-dns.info/nameservers.txt -
-
@viktor_g do you have updated lists?
https://github.com/dibdot/DoH-IP-blocklists/blob/master/doh-domains.txt
-
Is there a simple AppID DoH signature so we don’t have to play wack a mole with DoH block lists? 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? I purchase subscription rules and I see nothing to detect DoH on the IPS IDS. This seems to need some sort of research of a way to do this, detect and log alerts right?
https://docs.snort.org/start/rules
Make sure to upvote
-
@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)
