I’m behind a strict firewall that drops all IN and OUT traffic unless whitelisted. I need a list of all ports that I need to open OUT traffic and port forwardings I need to do for IN traffic. I know that a node operator may choose to use other than the recommended standard port and this creates the case where ideally I will have to open ALL outgoing traffic. This I will not do. If a node operates in a non standard / recommended port it will be unreachable for me.
I’m asking for the standard recommended ports (and IPs if any specific for a port).
Customers may connect to your nodes from any ports, nobody is in position to dictate them what port numbers they initiate their connection from. Libuplink, the client library, probably just asks the client OS for whatever free port the OS can offer. This alone is a hard requirement.
Consider that each storage node is handling customer traffic essentially in the same form as a web server: it has to accept customer connections from anywhere for uploads and downloads.
Understood. So port forwarding is only needed for the port I have configured it to listen to.
But I had to open for example 7777 outbound in order to have connection with the satellites, allow 35.224.44.57 outgoing in order to get an identity, etc.
I told you I need to white list every port and/or IP that the storagenode uses. Either inbound or outbound.
I’m asking for a detailed list of these IPs and/or ports in order to make this happen.
Oh, I classified these as outgoing as well. My mistake, indeed they are initiated by the node/identify code. You’ll need to wait for an answer from Storj. I don’t think this information has been explicitly stated anywhere, or that there are any assumptions this information would not change at any time.
Now, the github one that will be a pain, because that list is probably fairly long and frequently changing. It’s necessary because that’s where the updater gets new versions of the node software from. You might be in a position to control DNS and always hand back a single IP for github.com, so that the node will always use that IP. That would work for a while, but even that will probably fail eventually.
Finally, the node may try to contact other hosts in order to verify the TLS certificates of the above hostnames. This might include x1.c.lencr.org, crl.identrust.com, and others. To get the full list, you’d need to fetch the full certificate chain for all of the above hostnames and whitelist any CRL or OCSP distribution points. I’m not 100% sure whether curl, wget, or golang’s tls library do their own revocation checking or if things will break when those can’t be completed.
That’s all I can think of or find at the moment.
P.S. Please note that we don’t have the resources to support a constantly up to date or comprehensive outgoing access policy. There may be more outgoing connections that need to be added over time- maybe lots more- and we might not update this post when it happens. Your setup might break at any time. I personally can try to keep you updated, but I might miss some change, and we don’t yet have anything automated to check for outgoing connections.