Hacker News Reader

Comment by jradd | Hacker News Reader

Wish I had more to add than: "This is so neat!"

Seem's like this would be a good way to circumvent web filters that block remote file services (though allow DNS over tcp or udp).

How would one restrict this capability from an administrative perspective?

View on HN

People are already sneaking data through DNS in both directions. Here's a quick example from a year ago that popped in my head first: http://4lemon.ru/2017-01-17_facebook_imagetragick_remote_cod...

FYI re: PoC

NS for hacker.toys not responding

This is very neat as well. Still trying to understand it.

I have tested various use cases for Iodine, which works great, unless you are blocking all outbound dns traffic.

I've typically blocked outgoing DNS requests to arbitrary resolvers on every network I've managed, which disables the use of this FS.

Reason being, if users on my network are using a resolvers other than my own, they can resolve all sorts of domains I would have otherwise blackholed.

Controlling network access on DNS level seems pretty ineffective to me.

Especially with things like Google DNS over HTTPS and https://github.com/pforemski/dingo ...

Pretty much 100% waste of time I think. Users can easily just use raw IP addresses right?

HTTP 1.1 servers need the host name in the request, so that a single IP can host multiple domains that resolve to it. If you just go to the IP address, you get an error or a default host. It should work fine with most other protocols, though.

Add entry to /etc/hosts (or the windows equivalent), navigate in browser.

Too high of a hurdle for your average user though, in which case blocking sites at the DNS resolver works.

I'm pretty sure you can send a request to an IP address with the host name in the request.

Adding to what others say here: if you have/know the ip address, you probably also know the host name. There's nothing magical about:

  # from memory, syntax might not quite work 
  telnet 1.2.3.4 80
  Http/1.1
  Host: example.com
  Get /

Which is indeed why you can put the ip and host name(s) in /etc/hosts - and without other network level blocks - browsers etc will just work.

With http 1.0 blocking/filtering ips was enough, with 1.1 you need a proxy. With tls/ssl you have the choice between (having the capability to) decrypt everything or filter nothing. (obviously ip level filtering works, but it's a little crude in a Http 1/1 world. Ditto for http2 etc).

Oh I'm with you, you've gotta put other controls in place. Still in my basic acl for every network, because it's one if the first things users will do to circumvent controls.

It's also not uncommon to not use the default DNS settings of a network.

Doing this sounds like a good way to increase the noise to signal ratio in your support calls....

Reply on news.ycombinator.com