Over the past few weeks, both my colleagues and I have been getting a number of requests for information around whitelisting Citrix ShareFile in a customer environment. Seems people these days are becoming more and more security conscious – after all, with all of the attacks we’ve seen over the past few years seeming to increase, who wouldn’t want to protect their network?!
Most times, this request is simple – we send you (Mr./Mrs. Customer) a link to our Knowledge Base article, you forward said link on to your networking team and they make the appropriate changes to allow ShareFile on the domain.
Sometimes, though, it’s not so simple… bummer.
More and more often, we have customers requesting information on how to further lock down ShareFile in their environment – both to improve their network security and to help their clients/third parties accept documents from them that are sent through ShareFile. I have previously written about firewall port forwarding and basic rules here, but that’s not the focus of this post.
Today, we’ll break down the steps to configure your network’s firewall to allow ShareFile traffic in and out.
Because all networks are different and can utilize a number of different applications for firewall configuration, load balancing, content redirection, etc., we will be specifically talking about external firewall configurations for an on-premises ShareFile environment utilizing the US control plane (please see the KB article for EU control plane information).
ShareFile Architecture Overview:
First and foremost, it’s important for us to cover the architecture of ShareFile Enterprise on-prem:
As a SaaS (Software as a Service) application, ShareFile’s control plane is hosted by Citrix; meaning that all connections to ShareFile must be open to said control plane, including the StorageZone Controller (SZC).
When a user navigates through ShareFile, they will utilize an application (Sync, Drive Mapper, Desktop, etc.) or the web application to locate the files they request – while doing this, they interact with the control plane. Once the item they wish to share/download is selected, the calls are made to the on-prem file repository that is managed by the StorageZone Controller.
A common misconception around ShareFile is that the application allows traffic to enter your network – in fact, what occurs when users interact with ShareFile is that they browse the data in the control plane, they select the information/files needed and ShareFile’s service does the rest! The connection from the control plane to the StorageZone Controller is configured with a secret trust upon configuration and a service account is configured to access the share that is hosting the back-end data creates a proxy-like experience from the SZC server to the file server. Once the file object is obtained from the file server, the SZC merges the metadata to the object and sends the file(s) directly to the end-user.
This diagram demonstrates the flow of traffic in an environment running ShareFile on-prem with two Citrix NetScalers and two StorageZone Controllers configured in a High Availability pair:
Again, ShareFile is a SaaS application hosted by Citrix – all Citrix SaaS products are configured to work outbound through ports 80 and 443. ShareFile tools all operate over port 443; port 80 is used for healthcheck.
By that logic, we have to ensure that port 443 is open for traffic coming IN and going OUT from the StorageZone Controller. For some, that is enough – if you’re looking to further lock down traffic to/from ShareFile, keep reading!
IP Ranges are probably the easiest method for whitelisting ShareFile, as all of the ShareFile services and domains fall within our range. Additionally, for those like me who may not have advanced networking backgrounds (at least, not yet J), you can simply take this chart and hand it to your networking team(s) as mentioned above!
These ranges will allow traffic from ShareFile to reach your network. To keep it simple, an excel document with the IP ranges can be found here.
An alternative (or complimentary) method for whitelisting ShareFile is through utilizing the domains associated with the service. Here is a list of (most of) the domains that ShareFile utilizes:
That’s a lot, right? Let’s break it down to the domains that are 100% needed, versus those that are for specific features of ShareFile (i.e. *.sharefileftp.com).
- *.sharefile.com // *.sharefile.eu – Depending on your target control plane (US or EU), this domain is required for communication to the control plane (obviously).
- *.sf-api.com // *.sf-api.eu – Again, dependent on the target control plane (US or EU), this domain is used to make the calls between the control plane and the StorageZone, as well as the ShareFile tools that users know and love.
- *.sf-event.com – This domain is utilized to trigger connections based on events and changes within the UI.
- sf-cv.sharefile.com – This domain is for ShareFile’s content viewer that is built into the “New” ShareFile (released late 2016) and is required for rendering previews (on-prem or cloud) of files prior to download.
In a ‘just getting by’ mentality, these are the four that would be necessary to operate ShareFile on-prem. Should you wish to get more specific of which domains are utilized, or if wildcards are not accepted, you can modify the domain to read your subdomain (<subdomain>.sharefile.com; <subdomain>.sf-api.com, etc.).
Please note: When utilizing specific subdomains, please note that this will not allow other ShareFile accounts to be utilized, so, if you work with another company that utilizes their ShareFile account instead of yours, you will be unable to interact with their account while on the network configured to these settings.
Citrix hosted storage:
When utilizing Citrix-managed StorageZones, the four above domains are necessary, as are the IP ranges. However, if you wish to lock your connections down to the bare minimum, you can further the limitations around what Amazon or Azure servers are able to deliver data to your network. This requires a bit more leg work to get done.
After limiting your domain whitelists to the subdomain of your account, we’ll need to use the ShareFile API to find out which servers are making the back-end connections.
First, we would need to obtain the ZoneID by running a GET request under the “Zones” entity of the API to see what Citrix-managed StorageZone the account is utilizing. From there, we can run the GET request to obtain the StorageCenters from the ZoneID we just retrieved under the “StorageCenters” entity.
his call will return the addresses for the storage servers within the Zone, thereby locking down the network only to work with the specified servers that your ShareFile account uses.
If you have questions around any of the above, would like assistance in your configuration or would like to discuss this information further, please contact your Citrix representative and they can help get you connected with the right resource!
Again, this was a high-level of the whitelisting of ShareFile. The KB article referenced above also goes into