5 ms·

How can they trivially bypass this local filtering? If the router is redirecting all port 53 traffic, there is no way to bypass aside from some alternate name r

How can they trivially bypass this local filtering? If the router is redirecting all port 53 traffic, there is no way to bypass aside from some alternate name resolution scheme.

chipb 6y ago
How well does the redirect scheme work for a device that connects to a central DNS server listening on, say, port 5353 instead? What about 80 or 443?
- vageli 6y ago
  > How well does the redirect scheme work for a device that connects to a central DNS server listening on, say, port 5353 instead? How about 80 or 443? Just because it is not a silver bullet doesn't mean it is not effective for a large percentage of users.
- fiddlerwoaroof 6y ago
  Well, it’s more complicated, but in theory you could do some deep packet inspection that understands the protocols: personally, I’d use this to break DoH connections (for every host name seen in SNI, attempt a DoH query, if it resolves, reset the connection) and attempt to force everything to fall back to plain DNS. Then, whitelist a couple outbound ports (on most networks, maybe just 443 + 53?) and block VPNs.
  - judge2020 6y ago
    > or every host name seen in SNI Not going to be possible in a few years or so: https://news.ycombinator.com/item?id=25344311 https://news.ycombinator.com/item?id=25344311
    - dhaavi 6y ago
      meh. The outer SNI and the IP address still tell a lot about what you are doing online.
      - fiddlerwoaroof 6y ago
        Also, with things like this, you can just reset connections using HTTPS features you don’t support. It might eventually become painful, but it’ll be fine for the near future. And, if enough enterprise middleboxes do this, the standards will be DOA.
  - dhaavi 6y ago
    With the Portmaster (https://github.com/safing/portmaster https://github.com/safing/portmaster) we're going in that direction, but it will take a couple more years to be able to go that deep. Have a look!
- jlgaddis 6y ago
  https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good
acdha 6y ago
If the network allows outbound traffic, they can hard-code an IP list - this is how Cloudflare’s 1.1.1.1 works and malware has done this for decades – or they can use local DNS to resolve a single name which will answer or redirect to a service which does further queries. Malware commonly used IRC for this until that started getting blocked on most networks, but imagine how easy it would be to miss, say, a bot which connects on 443 to a major hosting provider, like half the apps you run, searches Google.com, Twitter, etc., or hits an ad network for a keyword selected by the attacker. In every case, once they get the server(s) to connect to you lose all further visibility unless you’re blocking 443 and forcing traffic through an inspection proxy.
- fiddlerwoaroof 6y ago
  Yeah, it’s an arms race, but I suspect it’s solvable: at least solvable enough that it’s feasible to just not use devices that break your policies. For things like Pi-Hole, the setup I describe will reduce much of the ad noise even without more complicated systems.
  - acdha 6y ago
    The way to solve is either to segregate unmanaged devices onto a separate network and give up on controlling them or to implement the system I described. The same Pi running a DNS server can run a proxy which applies blocking policies on all hostnames.
    - xg15 6y ago
      > The same Pi running a DNS server can run a proxy which applies blocking policies on all hostnames. With DoH, it's easy to not just hardcode the resolver's IP but also the resolver's certificate. How would a proxy be able to intercept that?
      - acdha 6y ago
        If you configure an HTTPS proxy, the client will use the proxy's name to verify the connection to the proxy and trust that the proxy will verify the remote connection. If you're trying to configure transparent proxying where the network redirects traffic to a different device, you would need to have a local CA so you can forge certificates — that's not uncommon in enterprise IT but it's definitely a security risk associated to having something which can MITM anything on your network. In either case, the real question is whether you control the endpoint. If it doesn't support configuring a proxy or installing a CA, all you have is the binary decision to decide whether or not to allow it on the network at all since whoever does control the client has so many options for smuggling traffic out.
SkyPuncher 6y ago
Based on this: https://stackoverflow.com/questions/33099569/how-does-sock-5-proxy-ing-of-dns-work-in-browsers https://stackoverflow.com/questions/33099569/how-does-sock-5... > Firefox, for example, sends hostname to SOCKS proxy without resolving it. So a simple proxy can bypass local restrictions. ----- I remember doing something similar back in my IT days just to see if it was possible. It was.
pdonis 6y ago
> If the router is redirecting all port 53 traffic Then it won't do anything to DNS over HTTPS traffic that is going over port 443. And it won't be able to distinguish that traffic from any other HTTPS traffic.
- fiddlerwoaroof 6y ago
  There’s theoretically ways to solve that: https://news.ycombinator.com/item?id=25349358 https://news.ycombinator.com/item?id=25349358

How can they trivially bypass this local filtering? If the router is redirecting all port 53 traffic, there is no way to bypass aside from some alternate name resolution scheme.

chipb 6y ago

How well does the redirect scheme work for a device that connects to a central DNS server listening on, say, port 5353 instead? What about 80 or 443?

vageli 6y ago
> How well does the redirect scheme work for a device that connects to a central DNS server listening on, say, port 5353 instead? How about 80 or 443? Just because it is not a silver bullet doesn't mean it is not effective for a large percentage of users.
fiddlerwoaroof 6y ago
Well, it’s more complicated, but in theory you could do some deep packet inspection that understands the protocols: personally, I’d use this to break DoH connections (for every host name seen in SNI, attempt a DoH query, if it resolves, reset the connection) and attempt to force everything to fall back to plain DNS. Then, whitelist a couple outbound ports (on most networks, maybe just 443 + 53?) and block VPNs.
- judge2020 6y ago
  > or every host name seen in SNI Not going to be possible in a few years or so: https://news.ycombinator.com/item?id=25344311 https://news.ycombinator.com/item?id=25344311
  - dhaavi 6y ago
    meh. The outer SNI and the IP address still tell a lot about what you are doing online.
    - fiddlerwoaroof 6y ago
      Also, with things like this, you can just reset connections using HTTPS features you don’t support. It might eventually become painful, but it’ll be fine for the near future. And, if enough enterprise middleboxes do this, the standards will be DOA.
- dhaavi 6y ago
  With the Portmaster (https://github.com/safing/portmaster https://github.com/safing/portmaster) we're going in that direction, but it will take a couple more years to be able to go that deep. Have a look!
jlgaddis 6y ago
https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good

acdha 6y ago

If the network allows outbound traffic, they can hard-code an IP list - this is how Cloudflare’s 1.1.1.1 works and malware has done this for decades – or they can use local DNS to resolve a single name which will answer or redirect to a service which does further queries. Malware commonly used IRC for this until that started getting blocked on most networks, but imagine how easy it would be to miss, say, a bot which connects on 443 to a major hosting provider, like half the apps you run, searches Google.com, Twitter, etc., or hits an ad network for a keyword selected by the attacker. In every case, once they get the server(s) to connect to you lose all further visibility unless you’re blocking 443 and forcing traffic through an inspection proxy.

fiddlerwoaroof 6y ago
Yeah, it’s an arms race, but I suspect it’s solvable: at least solvable enough that it’s feasible to just not use devices that break your policies. For things like Pi-Hole, the setup I describe will reduce much of the ad noise even without more complicated systems.
- acdha 6y ago
  The way to solve is either to segregate unmanaged devices onto a separate network and give up on controlling them or to implement the system I described. The same Pi running a DNS server can run a proxy which applies blocking policies on all hostnames.
  - xg15 6y ago
    > The same Pi running a DNS server can run a proxy which applies blocking policies on all hostnames. With DoH, it's easy to not just hardcode the resolver's IP but also the resolver's certificate. How would a proxy be able to intercept that?
    - acdha 6y ago
      If you configure an HTTPS proxy, the client will use the proxy's name to verify the connection to the proxy and trust that the proxy will verify the remote connection. If you're trying to configure transparent proxying where the network redirects traffic to a different device, you would need to have a local CA so you can forge certificates — that's not uncommon in enterprise IT but it's definitely a security risk associated to having something which can MITM anything on your network. In either case, the real question is whether you control the endpoint. If it doesn't support configuring a proxy or installing a CA, all you have is the binary decision to decide whether or not to allow it on the network at all since whoever does control the client has so many options for smuggling traffic out.

SkyPuncher 6y ago

Based on this: https://stackoverflow.com/questions/33099569/how-does-sock-5-proxy-ing-of-dns-work-in-browsers https://stackoverflow.com/questions/33099569/how-does-sock-5... > Firefox, for example, sends hostname to SOCKS proxy without resolving it. So a simple proxy can bypass local restrictions. ----- I remember doing something similar back in my IT days just to see if it was possible. It was.

pdonis 6y ago

> If the router is redirecting all port 53 traffic Then it won't do anything to DNS over HTTPS traffic that is going over port 443. And it won't be able to distinguish that traffic from any other HTTPS traffic.

fiddlerwoaroof 6y ago
There’s theoretically ways to solve that: https://news.ycombinator.com/item?id=25349358 https://news.ycombinator.com/item?id=25349358