Diplomat MFT is your SFTP Server. Protect it with the Edge Gateway.

DIPLOMAT MFT’s EDGE GATEWAY

Diplomat MFT’s Edge Gateway is an improved and more secure version of the traditional reverse proxy concept when you take advantage of Diplomat MFT’s capabilities as an SFTP server. It is an external-facing listener that runs in your edge-facing (DMZ) network to allow connections from third parties while also securing you against lateral attacks. Your data and sensitive systems remain protected on your trusted internal network.

How do you allow secure file transfers without risking cyber attacks and data loss? Leave a standalone server in the DMZ and hope your data isn’t stolen, or run a server on the internal network and hope you’re not hacked? And how can any of this be compliant? Let’s dive deeper. First we’ll look at traditional options, and then we’ll talk about the Edge Gateway and why it’s clearly better.

All of these approaches presume that some amount of consideration has been taken to maintain at least a minimally viable level of security. Too often we see too much reliance on mechanisms like whitelisting incoming IP addresses on the firewall and other such basic steps that are great to take if you have the option, but they aren’t complete and can be spoofed.

 Top 3 traditional options for servicing external SFTP clients 

OPTION 1: Direct connections

Far too many organizations put all their eggs in the IP whitelisting basket, allowing connections from the internet to be forwarded directly to a target SFTP server on the internal network. This is quick to set up, simple to maintain, and it gets the job done. But it does so at great risk.

The source IP for a given client connection can be spoofed. Time and again that threat vector has been written off as unlikely since it does take some concerted effort, only for organizations to not realize it’s happened until it’s too late. When a bad actor has direct connectivity to a system on your internal network, they not only have access to that system and its attached storage but also to shared storage. And that system is a prime platform for launching attacks against other internal systems. Because internal systems are internal, administrators don’t have their guard up nearly as much, making those targets softer, easier to exploit.

Allowing direct connections from external sources to internal systems of any sort in any context is directly against best practices and should be forcefully avoided. It’s easy, but in every other way it is bad.

OPTION 2: DMZ-based SSH server (store-and-forward or store-and-retrieve)

The most common option most organizations use is to manage run a full-blown SSH server in their DMZ, such as leveraging OpenSSH built in on a Linux VM or installing an application on a Windows Server. One system (or many) internally then reaches out periodically to retrieve any new files uploaded by external clients and uploads new files into the appropriate folders for those clients to come get later. It’s easy to understand, but with it comes numerous major security problems that can be difficult and complex to solve.

An immediately recognizable downside is that you now have an entirely separate system with software to manage, administer, audit, and attempt to secure as best you can. There is little in the way of any centralized visibility, with minimal logging and no auditing of user actions or tracking of admin activity. It becomes yet another system to be monitored and patched and generally worried about.

It’s an autonomous, stand-alone system, so it must necessarily have access to many sensitive resources. It needs at minimum its own private key pair, a list of user accounts, their passwords, their authorized public keys, and their permissions. The files that are uploaded by external clients are stored in that DMZ for some period of time. Files that internal applications put onto that system for later retrieval by the third parties are also stored in that DMZ for a while.

This means all those resources are vulnerable to attack, both directly and from other systems in the DMZ that may be compromised at some point. Bad actors could steal the private key to impersonate your server without your clients knowing. They could add their own public key to the authorized_keys list for each account. They can exfiltrate the files themselves, stealing that data for their own use. Even worse, it is so often a full suite SSH server with numerous attack vectors rather than a narrowly focused SFTP component exclusively.

Even if those files are encrypted, as they should be, that just makes it harder to access the contents, not impossible. And with the rise of quantum computing, the day is soon approaching that it won’t even be all that difficult. Store Now Decrypt Later (SNDL) is an approach that both nation states and criminal organizations have already been using to store encrypted data for an extended period before decrypting it at their leisure.

Running a standalone SFTP server in your DMZ is against best practice for all these reasons, yet in spite of that it remains a common choice today.

OPTION 3: Reverse Proxy

Reverse proxy either requires direct access to user credentials and authentication providers, which means you’re now exposing that to the DMZ anyway, or it simply provides a direct connection to the internal system, making it mostly useless in the first place. Too often it actually gets in the way of valid protocol functions, causing problems that are difficult and painful to troubleshoot, mostly just to prove it’s doing anything at all.

EDGE GATEWAY

Diplomat MFT is a high-value leader in the Managed File Transfer space. It offers not only no-code, streamlined file transfer and encryption automation but also acts as an SFTP server so that your vendors, clients, and SaaS platforms can have a place to send and retrieve files securely. The Edge Gateway enables that capability without sacrificing security.

 What is the Edge Gateway?

The Edge Gateway is not an autonomous system. Instead, it serves as an external-facing extension of Diplomat MFT’s SFTP server capabilities, controlled from the inside out by Diplomat MFT. It represents a smarter, more modern approach to a reverse proxy concept. The Edge Gateway is installed in your DMZ on a hardened Windows Server or Linux system. The Edge Gateway is controlled by the internal Diplomat MFT and instructed to accept connections from external clients without any knowledge of whether those connections are legitimate. It is intentionally kept in the dark, with no access to any sensitive information, so that the Diplomat MFT internally can determine how to instruct the Edge Gateway to interact with the external client.

It securely coordinates SFTP services between your Diplomat MFT and the internet, ensuring that no files are ever stored in your DMZ and requiring no inbound holes in the internal firewall.

No user data, authentication data, or keys are ever stored in the DMZ — even temporarily. Instead, the Edge Gateway coordinates with Diplomat MFT to exchange secure packets with the external SFTP Client. You remain compliant with both internal policies and external regulations while your data is securely protected with no theft from the DMZ possible.

Failover and Load Balancing

In addition to providing a secure method to offer SFTP connectivity to external trading partners, the Edge Gateway also offers built-in load balancing and failover management. Active-Active high availability requires no additional equipment or configuration or management teams. Failover HA is built in as well, whether locally for an active-passive implementation or across availability zones or datacenters.

Coupled with Diplomat MFT’s extensive JSON REST API for programmatic control, the Edge Gateway enables full automatic integration with systems management and datacenter management platforms for seamless high availability of SFTP connectivity — even across datacenters. Smooth daily operation, scalable load handling capacity, and even disaster recovery plans are made far simpler and more reliable by the Edge Gateway.

How it works 

Initially the Edge Gateway operates as a layer 3 (network layer in the OSI model) proxy server, analogous to a traditional reverse proxy server. The genius of the Edge Gateway is that it also contains a layer 7 element (application layer). Instead of an ignorant layer 3 proxy that takes traffic from one side of a firewall and forwards it in to the other, our Edge gateway contains the application element that selects which incoming data connections are brokered through to the Diplomat MFT based upon application logic. Furthermore, because of the construction of our Edge Gateway, it can broker the data from the Internet side to the Diplomat MFT side without requiring any inbound holes in the firewall—not just for the transport protocol but to authentication providers as well. This capability of Diplomat MFT and the Edge Gateway is highly secure and very powerful, and it is something that CANNOT be done with a proxy at layer 3 only. This capability also drives the Edge Gateway’s failover and load balancing high availability.

The Edge Gateway is software installed on a virtual machine in the edge-facing layer of your network, usually referred to as the DMZ. You use a simple, internal-only web interface to configure the  IP address and port the Edge Gateway will use to listen for incoming external SFTP client connections and the IP address and pair of ports to use to listen for incoming internal connections from the internally protected Diplomat MFT:

• One port for receiving “control” messages from Diplomat MFT, called the “Peer Notification Channel”, or “PNC”

• One port for “data” messages from Diplomat MFT, called the “Data” port

Diplomat MFT is configured to connect out to the Edge Gateway using the PNC port. This creates a bi-directional PNC over which Diplomat MFT and Edge Gateway communicate regarding incoming SFTP connection requests, and that connection persists at Diplomat MFT’s discretion. This channel includes periodic messages to ensure that the communications are valid and working. If there is ever any failure, Diplomat MFT continuously attempts to re-connect until it is successful, overcoming issues like temporary network outages or restarts on the Edge Gateway.

When an incoming SFTP client connection arrives at the Edge Gateway, a message is sent from Edge Gateway to the Diplomat MFT using that bi-directional PNC that includes the client IP address of the incoming SFTP connection. Diplomat MFT initiates a new outbound TCP/IP connection to the Edge Gateway over the Data port and includes the unique session identifier so that Edge Gateway knows which SFTP client this connection is for. The Edge Gateway then associates the two connections between the incoming SFTP client socket and the newly created Diplomat MFT data socket. All communications are relayed from one side to the other without any breaking of the encryption.

From that point forward, the SFTP client is communicating with the Diplomat MFT SFTP Server through that Edge Gateway, which at this point is acting primarily like a Layer 3 proxy, passing back and forth with encryption retained. This means that all decryption, authentication, file storage, and other operations are handled by the protected Diplomat MFT server, without any file storage nor credentials accessible to the Edge Gateway. Diplomat MFT is aware of the SFTP client IP address, so that it can validate IP address restrictions and audit client operations properly. This capability is unique to our layer 3 / layer 7 combination. Traditional reverse proxies or load balancers do not have this ability.

Why it’s better

The Edge Gateway gives you the best possible combination of streamlined administration, minimal threat vectors, and maximum security. It is the best of all words, as close as possible to letting you have your cake and eat it, too. It eliminates the need for direct connections from the outside world. Rather than a separate SFTP server in the DMZ requiring extensive management and monitoring along with numerous band-aids placed to stop the many sources of potential bleeding, it prevents those problems altogether. And unlike a traditional reverse proxy, it does not require access to user credentials, serve as a conduit for direct connections, or get in the way of a properly operating protocol.

The Gateway is left entirely in the dark, very much on purpose to eliminate the possibility of bad actors being able to gain access to read or modify the data stores or even operational configuration. The data, regardless of whether it is encrypted by PGP or OpenPGP, is never stored in the DMZ—even “temporarily” as most do for a store-and-forward or store-and-retrieve approach.

The Edge Gateway minimizes costs and complexity. It provides for active-active highly available load balancing or failover configurations of multiple internal Diplomat MFT systems. Its streamlined and separated design cleverly avoids the kinds of pitfalls that have led to so many security breaches over time.