Going down the DoH wormhole....
-
@deanfourie yeah doh is horrible IMHO..
My wifes phone keeps trying to see if it can do - but like @Gertjan shows I do some blocking, and resolve those known doh servers to an IP so I can block and log what devices are trying to talk to them.
But yeah if the device is using some unknown or private doh server, its going to be very difficult to stop.. Its not all that easy doing dpi on encrypted traffic..
-
Let me guess : iPhone to .... 172.19.19.19 ? Isn't that RFC1918 or am I one bit off ? If it isn't : a DNS server without reverse ??
Afaik, my iPhone does do DoH right now, and I didn't change any 'setting' to enable or disable it. I'll have a talk with it.
I guess it's capable of doing do ... -
@gertjan I have known doh servers fqdn setup to resolve to that IP.. Just some random IP that popped in my head that I don't use locally.. I wanted a way in the firewall to log any attempt to access doh servers.. This way simple look at firewall log for that IP shows me any device attempting to access any of the known doh servers fqdn that I have setup to resolve to that IP.
example snip
local-data: "dns.adguard.com. 120 IN A 172.19.19.19" local-data: "dns-family.adguard.com. 120 IN A 172.19.19.19" local-data: "dns.google. 120 IN A 172.19.19.19" local-data: "cloudflare-dns.com. 120 IN A 172.19.19.19" local-data: "dns.quad9.net. 120 IN A 172.19.19.19" local-data: "dns9.quad9.net. 120 IN A 172.19.19.19" local-data: "dns10.quad9.net. 120 IN A 172.19.19.19" local-data: "dns11.quad9.net. 120 IN A 172.19.19.19" local-data: "doh.opendns.com. 120 IN A 172.19.19.19" local-data: "doh.cleanbrowsing.org. 120 IN A 172.19.19.19" local-data: "doh.xfinity.com. 120 IN A 172.19.19.19"Sure I could prob do it in pfblocker some easier way.. But I had set that up way back at the beginning of the doh nightmare ;)
My list prob needs updating - but it is quite long, that is just a small snip of fqdn I resolve to that IP.
I do have some lists loaded into pfblocker for doh as well, but if a client tries to resolve any of the ones I have specific in unbound they resolve to that IP and can see it easy in firewall log.. My whole blocking doh stuff prob needs a refresh to be sure..
edit: from this it seems nothing has hit my pfblocker alias..
-
Yea, DoH is shit.
At least if you choose to try secure your own DNS thats fine,
But not given the option, this is not a good protocol.
Who knows whos resolving my queries when I add devices?
-
@deanfourie said in Going down the DoH wormhole....:
Yea, DoH is shit.
haha sing it brother sing it! ;)
-
It screams DPI
-
@deanfourie At one point a couple years ago I did try the pfBlocker method and had issues but I don't recall what they were, now. There is a pretty good writeup on https://github.com/jpgpi250/piholemanual...there is a long PDF for setting up pfSense to use the lists provided.
I have one system, the Dish satellite DVR, where the DVR seemingly uses DNS but its"video on demand" app uses only DoH so I had to allow that. :-/
-
@steveits said in Going down the DoH wormhole....:
app uses only DoH so I had to allow that
that is such BS!!
-
@johnpoz You don't want to know how long it took me to figure out that was the problem. :)
-
@deanfourie said in Going down the DoH wormhole....:
when I add devices?
That is the (only) solution.
Chose what you add to your networks.
After the classic questions as "is it useful" and "do I need it", just add "does it DoH". -
So, just back on this topic.
I'm looking into nDPI. As I use ntopng and really like its capabilities, this library actually looks rather promising and pretty solid!
https://github.com/ntop/nDPI
Whats your thought on installing this alongside pfSense, or even on a separate container?
-
@deanfourie said in Going down the DoH wormhole....:
https://github.com/ntop/nDPI
question for you - while doing dpi on ssl traffic might be viable for say a browser, where you can get the machine to trust your mitm being done. How is that suppose to work for say an iot device using doh?
-
@johnpoz well my guess is, and it is a guess at this stage.
But I would imagine it would then strip the packet down and inspect the header for a DNS request, because as I understand it still has a DNS request hidden inside the HTTPS packet.
Strip it down, and look for any HTTPS traffic with DNS matches and block it.
-
@deanfourie said in Going down the DoH wormhole....:
Strip it down
And again how is that going to be done - you can not do that without the encryption keys for the https session.. This one way to do that is known as man in the middle attack, etc. What can be done is trick the that you are who they are talking to via https, and they send you the stuff encrypted to you.. And then it gets sent on to where your really going via your guy in the middle.
Without that you would have to just plain out break the https encryption to view "inside", ie strip it down.. So how is that going to be done.. mitm is viable with a browser.. But not with iot stuff where you can not tell it to trust your mitm cert, etc..
IDS/IPS as a whole has less and less use with all traffic being encrypted..
Not saying you couldn't look for other patterns in the traffic and possible size of the packets used in talking to the doh server, without having to break the https encryption.. But if that was so easy - I would think it would be all over the place how to do, since many people are not fans of doh or dot..
But the idea off "stripping down" the https communication and looking inside is not so easy - if it was https would be pretty much useless..
-
@johnpoz Yes strip the SSL, inspect, re-encrypt.
Thats the plan. Surely this is possible. Once the SSL is stripped then we can do whatever we like with it.
Otherwise we will just let DoH fester and grow its AIDS inside our networks.
-
@deanfourie Normally MITM is achieved by installing a CA cert on each device and then creating "certificates" on the fly. Can be done on a PC but you can't really install your cert on an IoT device.
Easier to just block DoH per the above and then if you need to, allow a device to use it.
