-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Peer whitelist #6565
Comments
Caveat, IPFS Cluster does not have a connection based whitelist but a rpc authorization whitelist. All other limiting of connections between IPFS Cluster peers occurs via the fact that they are on a separate libp2p network, aka private network. In the case of IPFS, would the peer with the whitelist be able to create connections to peers outside of its whitelist? What benefit does this provide over a straight private network or what is the use case that private networks don't solve but this does? |
@lanzafame The peer with the whitelist would not be able to create connections to peers outside of its whitelist. The problem with private IPFS networks is that if the private secret gets exposed at all, any peer that knows of the secret can connect. By having the ability to whitelist peers, private networks would be able to have much more control over who can participate in the network. |
Depends on libp2p/go-maddr-filter#15. In general, I'm all for this. Ideally it would use IPNS over pubsub to distribute authenticated access control lists. |
So does that mean that this feature would only apply to private networks? I am struggling to understand how this would be able to work in conjunction with the public network. Note, I am just trying to determine the scope of this feature, not in anyway implying it isn't needed. |
I believe this is meant to be a separate feature (although you could also share a swarm key). Having a whitelist like this would allow peers to form private clusters where membership can easily be revoked. |
@Stebalien - Yes, that's the thought process behind things. This conversation might also be fairly relevant to the conversation happening in this issue: #6097 |
From speaking with @raulk this seems to already be a feature in libp2p via the "Filters" functionality: https://godoc.org/github.com/libp2p/go-libp2p#Filters It sounds like there might be a simple solution here of just exposing this functionality via the config file. |
We could make use of PeerId based filtering when testing go-ipfs... i want to replay gateway traffic from a production node to a test node, and have the test node not connect to the prod node. The IP addresses of the production nodes can change, while the peerIDs remain stable, so it'd be nice to be able to filter on a Peer ID rather than an IP. |
+1 for this whitelist/allow list feature. Even though I want to contribute extensively to the IPFS public network, I also want to block some inconvenient PeerIDs. I have noticed that every time I launch a new peer through the Docker container, my home router receives a port scan. However, this does not happen when I launch the same image from my office. This occurs even if the daemon is started locally. So, there is a sense of port scanning based on the IP address range. Whether it is an IP of an ISP for a corporation or an IP of an ISP for home users. Port scans are routine and unavoidable. However, when comparing the IP address of the scanner with the peer connected, by We are currently blocking them with a blacklist/deny list on our firewall from time to time, but I have a feeling we will probably hit the limit in the near future. Since the peer disappears in a few days. It would be useful to simply be able to set the Allow Peer List of the home node by referencing the Peer List of the office node, which is relatively stable. P.S. |
@KEINOS Peer whitelisting is already possible using Private Networks. Bare in mind that this would also prevent connecting to the default bootstrap nodes, you may want to look at Peering if you want a looser way of managing this. Peer blacklisting isn't yet implemented as far as I'm aware though. |
Indeed. Private networks are the best option if we want strict control over who joins the network. My understanding is that it is allow-to-join rather than allow-to-connect. But the thing is that I didn't want to keep it private. And to contribute caching to the IPFS public network. In doing so, I wanted to exclude naughty PeerIDs from the connecting peer list. But deny listing would be weaselly, so I come to Until the AllowList is implemented, my plan is to use one of my peers for observation and from there create a list of PeerIDs that have made similar contributions over time. This is because I personally believe that the PeerIDs that have been around for a long time are more reliable. |
You can use resource manager for this, setting defaults values of allowed inbound connections to 0 and setting it to 1 for whitelisted peer: https://github.com/ipfs/kubo/blob/4f303d3208babbe7f5bb40a312a24d73dbf9c9dd/docs/libp2p-resource-management.md#user-supplied-override-limits |
if this configuration changes on disk, does kubo need to be reloaded? if so, is there a way around this? |
it would also be great to have an example of how to do this.
|
News on that? |
@morandalex
where the gater should reject the connection after the timestamp, and the timestamp 0 means "never expire"
|
@sevenrats I missed this #6565 (comment) I didn't thought about hot reloading. |
Feature Request: A way to whitelist the peers that your node can connect to.
This would ideally work similarly to the way that IPFS-cluster has a whitelist of cluster peers that you can connect to, except at an IPFS level instead of a cluster level.
The text was updated successfully, but these errors were encountered: