3 ms·

Thanks, I was aware of the DNS rebinding possibility but not sure how to best protect against that. I'm also less worried about websockets and other things that

Thanks, I was aware of the DNS rebinding possibility but not sure how to best protect against that. I'm also less worried about websockets and other things that I know are running on my machine, but more about all the other random devices floating around in my network. What I really want is a way to block (by default) all connections to my local network from websites outside of my network, like a firewall. It amazes me that browsers just allow this, this should require a permission prompt.

throwaway2048 6y ago
The best way to protect against DNS rebinding attacks is at the DNS server level on your local network. https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/ https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/ the private-address directive and setting cache-min-ttl to a value of higher than 10 minutes or so both do a lot to neuter dns rebinding attacks. Other DNS Resolvers have similar settings.
- ju-st 6y ago
  The DNS resolver/server is still resolving 127.0.0.0/8 and ::1 with these settings.
  - throwaway2048 6y ago
    Not if you tell it otherwise.
lstamour 6y ago
Part of the problem is a number of networks use public IPs including IPv6. NAT isn’t always required. Where it is used though, one could block DNS reflection at the DNS forwarder or locally, and use an application-specific firewall to block connections to local IPs from a particular app. You could use a proxy or custom DNS setting for a browser to blackhole traffic to local addresses but outside of using a proxy they could still use IP addresses. Combined with the earlier solution though that might work for IPv4 NAT environments. Fact is, internet connected devices need to be secure, and NAT as a security tool has to be stopped, it’s just one really convenient security layer, but is relatively easy to work around, so it’s not inherently secure on its own... I am also reminded of Internet Explorer Security Zones, where you could define different rules for your local network vs the public internet. And Home vs Work vs Public wifi connections on Windows. These days, though, most users aren’t going to configure their networks to this degree... safer routers are perhaps the only easy way to start, but folks hate getting lots of notifications, so it’s unclear how any general purpose solution would work beyond localhost.
philsnow 6y ago
I agree about it being scary that the browser doesn't do more to prevent connections from from "localhost" to "not localhost". https://github.com/99designs/aws-vault/issues/578 https://github.com/99designs/aws-vault/issues/578 was for an issue with remote servers accessing the localhost ec2 metadata service that aws-vault can run, that worked exactly by using DNS rebinding. It was fixed only a couple weeks ago, so it seems like this is a developing area and if I were on a red team or pen testing, I would play around with more. I visualize the "localhost hole" problem of blindly trusting localhost as an air gap in a pipe (like [0]); anybody could come along and either drop poison in the pipe, or redirect the water coming from the top to their own bucket, or both. [0] https://districtsales.ca/wp-content/uploads/2019/07/tru-gap-2.jpg https://districtsales.ca/wp-content/uploads/2019/07/tru-gap-...

throwaway2048 6y ago

The best way to protect against DNS rebinding attacks is at the DNS server level on your local network. https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/ https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/ the private-address directive and setting cache-min-ttl to a value of higher than 10 minutes or so both do a lot to neuter dns rebinding attacks. Other DNS Resolvers have similar settings.

ju-st 6y ago
The DNS resolver/server is still resolving 127.0.0.0/8 and ::1 with these settings.
- throwaway2048 6y ago
  Not if you tell it otherwise.

lstamour 6y ago

Part of the problem is a number of networks use public IPs including IPv6. NAT isn’t always required. Where it is used though, one could block DNS reflection at the DNS forwarder or locally, and use an application-specific firewall to block connections to local IPs from a particular app. You could use a proxy or custom DNS setting for a browser to blackhole traffic to local addresses but outside of using a proxy they could still use IP addresses. Combined with the earlier solution though that might work for IPv4 NAT environments. Fact is, internet connected devices need to be secure, and NAT as a security tool has to be stopped, it’s just one really convenient security layer, but is relatively easy to work around, so it’s not inherently secure on its own... I am also reminded of Internet Explorer Security Zones, where you could define different rules for your local network vs the public internet. And Home vs Work vs Public wifi connections on Windows. These days, though, most users aren’t going to configure their networks to this degree... safer routers are perhaps the only easy way to start, but folks hate getting lots of notifications, so it’s unclear how any general purpose solution would work beyond localhost.

philsnow 6y ago

I agree about it being scary that the browser doesn't do more to prevent connections from from "localhost" to "not localhost". https://github.com/99designs/aws-vault/issues/578 https://github.com/99designs/aws-vault/issues/578 was for an issue with remote servers accessing the localhost ec2 metadata service that aws-vault can run, that worked exactly by using DNS rebinding. It was fixed only a couple weeks ago, so it seems like this is a developing area and if I were on a red team or pen testing, I would play around with more. I visualize the "localhost hole" problem of blindly trusting localhost as an air gap in a pipe (like [0]); anybody could come along and either drop poison in the pipe, or redirect the water coming from the top to their own bucket, or both. [0] https://districtsales.ca/wp-content/uploads/2019/07/tru-gap-2.jpg https://districtsales.ca/wp-content/uploads/2019/07/tru-gap-...