Closed cinderblock closed 8 years ago
ah indeed. i didn't re read it closely enough
Just got blocked by Hetzner due to this a few minutes ago.
IMO, it really would make sense to at least printout a warning (until #1246 is implemented) while starting ipfs (maybe with a link to this bugreport) as having your host blocked due to ipfs is not a nice 'user experience'.
Hey @adrian-bl yeah it is annoying to deal with that.
How do you suggest detecting the environment to print out the warning? We need some good heuristics. Such warning should not be printed every time ipfs daemon runs, only when the user is likely to be running in an aggressive hosted environment like hetzner.
Hi @jbenet
in an aggressive hosted environment like hetzner.
I wouldn't call them 'aggressive': I can somehow understand that they consider requests to private networks fishy and assume such hosts to be compromised.
How do you suggest detecting the environment to print out the warning?
The cleanest solution would be to print out the warning if all interfaces of the host have public IPv4 addresses (while ignoring 127.0.0.0/8). Another (flaky) solution could be to check if the subnet mask of all interfaces (excluding lo) is bigger than /24 (most hosters use something like /27 or /28 as their networks are routed)
But i wonder how the private IPs are actually ending up in the DHT: Is this intentional?
Eg: BitTorrents Kademlia implementation doesn't have this issue/feature: A node doesn't need to know its own IP address (but could easily learn it by searching for its own node id):
An announce request only includes the listening port of the node - the remote node (which receives the announce) will then store the remote address of the UDP packet. (after verifying the token to avoid spoofing)
We may as well just implement #1246
agree a warning would be nice.
Also documenting in ipfs daemon
The mainline dht is not designed to work in private disconnected networks across many levels of nat and many kinds of networks (including non IP networks) and without access to the Internet. I'm tired of justifying the addresses points. Look up for more.
On Tue, Dec 15, 2015 at 08:44 Adrian Ulrich notifications@github.com wrote:
Hi @jbenet https://github.com/jbenet
in an aggressive hosted environment like hetzner.
I wouldn't call them 'aggressive': I can somehow understand that they consider requests to private networks fishy and assume such hosts to be compromised.
How do you suggest detecting the environment to print out the warning?
The cleanest solution would be to print out the warning if all interfaces of the host have public IPv4 addresses (while ignoring 127.0.0.0/8). Another (flaky) solution could be to check if the subnet mask of all interfaces (excluding lo) is bigger than /24 (most hosters use something like /27 or /28 as their networks are routed)
But i wonder how the private IPs are actually ending up in the DHT: Is this intentional?
Eg: BitTorrents Kademlia implementation doesn't have this issue/feature: A node doesn't need to know its own IP address (but could easily learn it by searching for its own node id):
An announce request only includes the listening port of the node - the remote node (which receives the announce) will then store the remote address of the UDP packet. (after verifying the token to avoid spoofing)
— Reply to this email directly or view it on GitHub https://github.com/ipfs/go-ipfs/issues/1226#issuecomment-164768218.
I'm tired of justifying the addresses points. Look up for more.
You don't have to justify yourself: I had no intention to criticize the decision.
I'm pretty new to IPFS and was just wondering why it behaves like this (i've written my own BitTorrent client so my mind is 'locked' in the mainline DHT world).
I'll read trough https://ipfs.io/ipfs/QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf which will probably answer my questions :-)
No worries, I'm just excusing myself for not giving you a complete answer nor pointers.
Good thing to wonder though :)
Read through issues in this tepo about addresses
+1. Got an abuse message from Hetzner today. Please add ability to disable local peer-discovery!
Please see https://github.com/ipfs/go-ipfs/issues/1226#issuecomment-120494604 and preceeding comments for a solution to this issue.
If you still have an issue with this after trying the address filters, please file a new issue with details of what you have tried and which addresses are being dialed.
These filters are now applied to your config if you initialize ipfs with the 'server' profile:
ipfs init --profile=server
Solution
Use
ipfs init --profile=server
~ Kubuxu
I just installed go-ipfs, did an init, and started the daemon. A couple minutes later, my hosting provider sent me an abuse email indicating that a "Netscan" was coming from my host and asked me to stop. Here is the log they sent me (edited for privacy).
Notice all but 3 destination addresses are internal network destination. There are also many repeats (same destination internal IP) and this all happened in 33 seconds. Nearly all of this was happening on port 4001 as well, reinforcing that this was IPFS doing this.
How does ipfs currently find peers to swarm with? Is there a way to throttle back the peer discovery process? Why is it even trying to scan internal IPs? (I'm on a externally facing machine)