Hacker News Reader

Comment by Jyaif | Hacker News Reader

> For example, we’ve observed that the UC Berkeley guest Wi-Fi blocks all outbound UDP except for DNS traffic. No amount of clever NAT tricks is going to get around the firewall eating your packets.

I'm not familiar with DNS at all, but can't you craft UDP packets that look like DNS packets, but contain a useful payload with which you can do the whole STUN/UDP-hole-punching/p2p dance, assuming you have matching that can unwrap the payload?

View on HN

Any modern enterprise firewall has app identification built in and will quickly identify you trying to send non dns traffic. And after the solarwinds debacle, everyone with a security team is looking for it.

Well, there'd be no way for a firewall to block a request like:

dig -b peername data.data.data.data

And let the "name server" on the other end listening on port 53 parse the data. You _would_ have to be able to listen on port 53 and of course it would be slow as hell, but it's unblockable.

Check this:

https://www.paloaltonetworks.com/cyberpedia/what-is-dns-tunn...

See the "Preventing DNS Tunneling" chapter.

Interesting, thanks. Seems like the firewall would have to be specifically configured to block, say "WebRTC through DNS tunneling" in this case, though.

TCP over DNS has been a thing for a long time, though I guess it's fallen out of favour because "real" VPNs are so easily available nowadays.

For example you can see here:

https://analogbit.com/software/tcp-over-dns/

Even if you could, the problem would come when you wanted to establish a data connection with the remote end. Assuming "except for DNS traffic" actually means "except for packets on the well-known port for DNS" then you are going to be restricted to sending packets with destination port 53. This means that for comms to work, the remote end is going to have to be able to receive packets on port 53. Some kinds of network setups may allow this -- all of this stuff ends up being hideously dependent on the detail -- but many won't.

There are all sorts of tunnel-thru-DNS possibilities (e.g. iodine, heyoka, etc.). There also a number of ways to mitigate (e.g. limit destination DNS servers, traffic analysis to spot anomalous 'queries', etc.). It's an arms race.

It certainty depends on how the network is doing the packet scanning and the other measures in place. If the security measures include a allow list of DNS servers, then there's little that can be done to bypass it.

Smarter firewalls can filter not just ports but the payload as well.

Reply on news.ycombinator.com