Is it possible for Storj to publish the list of IP address ranges that clients should expect to communicate with when using the hosted S3 gateway? This is helpful for security and auditing configurations. As an example, Backblaze B2 and Cloudflare R2 both openly publish this information for their services:
@thepaul may be able to help as they posted about outbound rules for a node operator - Exact settings on a strict firewall - #8 by thepaul
Welcome to the forum!
You may try to collect them this way (until our team may consider to publish such a list):
Please note - returned IPs may rotate and depends on your location, so need to run it several times.
Another one - is the satellite URL. There are three customer-facing satellites:
You also likely would need these ones:
@Alexey, thanks for the follow-up.
It appears as though the mentioned .storjshare.io DNS names return IP addresses within AS211541 (currently only 220.127.116.11/24), and that AS is currently the only one that shows up when performing an ASN search for “storj.” Furthermore, basic S3 interaction with gateway.storjshare.io only seems to interact with addresses in that same range, at least under a short test. It would be helpful if Storj could confirm intent to operate that way (hosted S3 gateway only utilizing endpoints within Storj’s AS) and publish the address range(s) when they change as some other providers do.
The .storj.io satellite and version DNS names as well as return addresses in Google Cloud Services ASN(s), involving much larger address spaces. Is it safe to assume those can be ignored when just using the S3 hosted gateway (as opposed to using the uplink client, web interface, or self-hosted gateway)?
I would suggest you just try
This is not a weird request. With any external party we exchange data with at my work we are required to use limited whitelisting of IPs. While I have no problem with suggesting people try things for themselves, I think in this case it’s worth investing some time into figuring out how it’s set up on your end and publishing the IP-ranges to whitelist. Of course this only applies to gateway use cases as native implementations can never work with IP whitelisting.
I am pretty ignorant of how our system looks on the operations side. (The outbound rules had more to do with the software.) So I don’t have an answer here, but I know someone is putting together a list for you. Also we’ll be investigating how feasible it would be to provide a live, dynamically updated list as well.
I’ve compiled the list of all of the IP addresses our gateway and linksharing services use or might be using. I hope this gets useful for auditing and security.
That said, we can’t guarantee this list is always kept up to date. That means, if, for instance, you’d like to whitelist Storj traffic using these IP addresses, then it’s probably not the best idea as these IPs might change and users behind your firewalls will experience intermittent access. If you’re absolutely sure your case requires it, please reach out to the support - we might provide some alternative solutions.
@hydr, thank you for looking into this, much appreciated. Just to confirm I understand: if I’m just performing S3 interaction with the Storj-hosted S3 gateway, this full list of potential addresses is in play? Or does this list account for additional services (e.g. you mentioned linksharing)? If there’s a reduced subset for the S3 storj-hosted gateway, can you please identify that?
@hunter All storj-hosted services (gateway, linksharing…) are using all these IP addresses. So in your gateway example - yes, this is the full list of potential addresses.