Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Data transfer over a limited number of ports

99 views
Skip to first unread message

Spencer Bliven

unread,
Jul 10, 2024, 10:08:58 AM7/10/24
to Discuss, Spencer Bliven, simon...@psi.ch, Attila Martin Nacsa
I am currently negotiating with our networking team to try to get globus connect personal working from our network. I am primarily concerned with transfers between a GCP client and a normal Globus Connect Server (so no STUN needed). From this page I see that the following ports should be open:
I'm getting push-back from our security team about the 50000-51000 range, which they are concerned is too broad. Is there any way to narrow this to fewer ports? Or does anyone have experience using GCP behind a restrictive firewall?

Cheers,
Spencer

Lev Gorenstein

unread,
Jul 10, 2024, 12:58:52 PM7/10/24
to Spencer Bliven, Discuss, Spencer Bliven, simon...@psi.ch, Attila Martin Nacsa
Hi Spencer,

The catch with narrowing the port range is this: when Globus Transfer service orchestrates sending a chunk from source to destination, it picks a port in the intersection of respective allowed ranges on both sides. This is why we generally discourage changing the default range (imagine side A only allows 50000-51000, and side B only allows 40000-41000, and never the twain shall meet).

Here's a piece of documentation that discusses effects of limiting/restricting various ports for Globus Connect Server: https://docs.globus.org/globus-connect-server/v5.4/gcsv54-restricted-firewall-policy/consequences-of-restricting-gcsv54-firewall-policy/  Things are slightly different for GCP (unlike GCS, GCP uses outbound connections only, so ignore all inbound discussion in that document), but hopefully this will be somewhat useful.

Also, it might be worth noting an important part: the data channel ports are transient and NOT permanently open. Quoting from the above:
there are no GCS processes actively listening on ports 50000 - 51000. Connections on the data channel are initiated only at the start of a data transfer task and are closed at the completion of the transfer. Ports are picked out of that range and used only as needed for inbound data transfers, and are not otherwise listened on by GCS. This is important because it means that not all 1001 ports are actively listening, which substantially changes the security posture.
(again, this speaks of GCS but the mechanics applies to GCP as well).


Lev
--
Lev Gorenstein
Solutions Architect
Globus // University of Chicago
e: l...@globus.org

Karl Kornel

unread,
Jul 10, 2024, 1:28:21 PM7/10/24
to Lev Gorenstein, Spencer Bliven, Discuss, Spencer Bliven, simon...@psi.ch, Attila Martin Nacsa
Hi Spencer,

One other thing you can try is to require encryption for all data transfers.  In that case, mTLS (mutual TLS) is used, with short-lived certificates issued by Globus.  That might also help you!

~ Karl

On Jul 10, 2024, at 9:58 AM, Lev Gorenstein <l...@globus.org> wrote:


To unsubscribe from this group and stop receiving emails from it, send an email to discuss+u...@globus.org.

Spencer Bliven

unread,
Jul 10, 2024, 3:19:56 PM7/10/24
to Discuss, akko...@stanford.edu, Spencer Bliven, Discuss, Spencer Bliven, simon...@psi.ch, Attila Martin Nacsa, l...@globus.org
Thanks for the link, Lev. If I'm reading it right, there is no way to configure GCP to prefer a particular port for outbound connections (assuming the destination GCS uses normal ports). Sounds like I will have to lean more on the security team. I'm not sure exactly the rational for blocking outbound ports.

Karl, does mTLS change the port used for data transfer? If both control and data transfer could go via tcp/443 that would solve my problem. Do you have some links for how to configure this? Is it configured on the GCP side or the server?

-Spencer

Alan Sill

unread,
Jul 10, 2024, 5:01:50 PM7/10/24
to Spencer Bliven, Alan Sill, Discuss, akko...@stanford.edu, Spencer Bliven, simon...@psi.ch, Attila Martin Nacsa, l...@globus.org
The way callbacks work in Globus Connect is that they originate from within your network and are outbound only. I'm not sure why your security team would think that a single port for these is more secure than multiple ports.

The practical impact of having a more restricted number of ports is that multiple transfers can interfere with each other and even throttle your bandwidth. It might not even work at all. 

If I were you I'd try to talk with your security team to alleviate their concerns about these outbound connections. the software works and as mentioned by others earlier, there are other things you can do to tighten security on the transfers if you are concerned. 

Alan

Karl Kornel

unread,
Jul 10, 2024, 7:34:15 PM7/10/24
to Alan Sill, Spencer Bliven, Alan Sill, Discuss, Spencer Bliven, simon...@psi.ch, Attila Martin Nacsa, l...@globus.org

Hi Spencer,

 

mTLS—which is enabled through the “Encrypt Transfer” transfer option—does not change the ports that are used.  Globus will still choose one of the data-transfer ports (normally 50000-51000) for the transfer.

 

As Alan mentioned, all connections from Globus Connect Personal to Globus Connect Server are outbound connections.  But, it sounds to me like your Security folks are firewalling outbound connections.  Is my guess correct?

 

~ Karl

Spencer Bliven

unread,
Jul 18, 2024, 5:37:37 AM7/18/24
to Karl Kornel, Alan Sill, Spencer Bliven, Discuss, simon...@psi.ch, Attila Martin Nacsa, l...@globus.org

Yes, outbound connections are firewalled. They are concerned about malicious services using open unmonitored ports for data exfiltration in the event of a breach. I'm not in a position to argue about the likeliness of that scenario.

As a compromise they have agreed to whitelist servers that we want to connect to. This is a hassle, but at least it seems to be working.

-Spencer

Backeberg, David

unread,
Jul 18, 2024, 10:13:03 AM7/18/24
to Spencer Bliven, Karl Kornel, Alan Sill, Spencer Bliven, Discuss, simon...@psi.ch, Attila Martin Nacsa, l...@globus.org
We had a similar battle with InfoSec for a high security service…

The compromise we came up with is that the server has no outbound restrictions, but it doesn’t mount our production storage…

Instead, it has a small storage pool, only containing whatever is actively being sent or received, and it requires an extra step for a second server to stage-in / stage-out that data on a server that can see the temp pool and the regular storage.

Still not as useful as a regular Globus server, but this at least lets the person closest to the data decide the amount of “risk” they are willing to take with the relevant portion that needs to be transferred.

This model makes a lot of sense to reduce the potential disclosure in the case of a breach.
--
David Backeberg <david.b...@yale.edu>
(203) 444-7089  Yale Center for Research Computing

Lev Gorenstein

unread,
Jul 18, 2024, 10:33:26 AM7/18/24
to Spencer Bliven, Karl Kornel, Alan Sill, Spencer Bliven, Discuss, simon...@psi.ch, Attila Martin Nacsa
While definitely painful and unsustainable for "normal" Globus endpoints, in the case of GCP on instrument PCs such an approach ("unrestricted within campus network, allow-listed for few select outside destinations") may indeed be a sensible compromise. It's a campus instrument, it mostly talks to campus storage/HPC/facilities, very rarely does it need to go outside (because downstream sharing and collaboration usually happens from other storage systems)... so could end up being relatively painless for you.

Lev
Reply all
Reply to author
Forward
0 new messages