5 ms·

> 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 ar

by Jyaif 3y ago

> 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?

stevekemp 3y ago
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/ https://analogbit.com/software/tcp-over-dns/
Hikikomori 3y ago
Smarter firewalls can filter not just ports but the payload as well.
- deleted 3y ago
  [deleted]
gnfargbl 3y ago
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.
cephei 3y ago
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.
kjs3 3y ago
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.
tw04 3y ago
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.
- commandlinefan 3y ago
  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.
  - JackGreyhat 3y ago
    Check this: https://www.paloaltonetworks.com/cyberpedia/what-is-dns-tunneling https://www.paloaltonetworks.com/cyberpedia/what-is-dns-tunn... See the "Preventing DNS Tunneling" chapter.
    - commandlinefan 3y ago
      Interesting, thanks. Seems like the firewall would have to be specifically configured to block, say "WebRTC through DNS tunneling" in this case, though.

by Jyaif 3y ago

stevekemp 3y ago

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/ https://analogbit.com/software/tcp-over-dns/

Hikikomori 3y ago

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

deleted 3y ago
[deleted]

gnfargbl 3y ago

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.

cephei 3y ago

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.

kjs3 3y ago

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.

tw04 3y ago

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.

commandlinefan 3y ago
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.
- JackGreyhat 3y ago
  Check this: https://www.paloaltonetworks.com/cyberpedia/what-is-dns-tunneling https://www.paloaltonetworks.com/cyberpedia/what-is-dns-tunn... See the "Preventing DNS Tunneling" chapter.
  - commandlinefan 3y ago
    Interesting, thanks. Seems like the firewall would have to be specifically configured to block, say "WebRTC through DNS tunneling" in this case, though.