Hacker News Reader

Comment by jgeralnik | Hacker News Reader

As long as only one side of the connection is behind a corporate NAT you could simply try all 65535 ports until you find the one that works. The side behind the NAT would receive the packet and then be able to respond.

View on HN

And then you're blacklisted by the corporate firewall for doing what looks like port scanning.

All 3 corporate firewalls I have been behind have been HTTP only. No actual internet connection. (Except for DNS, which worked.)

DNS working in a corporate IT environment is a surprise. Often, clients are issued an internal DNS server via DHCP, and outbound DNS to arbitrary servers is blocked. This helps mitigate DNS hijacking and also allows some additional outbound domain filtering and logging.

Oh, yes, DNS is an internal DNS. You can't change it. I meant, it's the only way to "trickle leak" data without it going through the filtering proxy. But who knows, maybe the DNS requests are logged too, but they don't seem to be filtered.

Edit: they are filtered. Suspicious names go to 127.0.0.1

You can leak names can't you? Wouldn't kinda-short-secret-message.foo.example.com make its way eventually to the authoritative server for example.com, as long as it's not too sketchy a domain?

Yep, that works.

And of course, with the advent of DNS over HTTPS, this is no longer as effective. I can still access blocked sites and get around logging, I just have to set up a tunnel to cloudflare.

Which, from a security point of view, would be grounds for immediate termination and quite some companies I worked for would try to sue you to pay for impact assessment.

(connecting a usb-modem is much safer, I'd have to actually spot the device which would require getting out of my chair... ;)

The point is not really for me to circumvent restrictions, it's more that a bad actor could. This can largely defeat the purpose; though malware using this is not common, it's started to crop up.

Reply on news.ycombinator.com