SFTP server dmz vs trusted

We're looking to ditch our existing solution and go with a simpler (much cheaper) SFTP server to allow file exchanges with clients. Our network consists of a Trusted and DMZ networks. The current product has this covered by hosting a server on both sides and taking care of the bridging itself. We're looking to switch to WinSSHD, but not sure regarding the placement of the server, DMZ vs. Trusted. We're in the financial space and looking for guidance on best practices, or perhaps good alternatives to meet our requirements.

It certainly feels like we should place it in the DMZ, but then we have to figure out how to move the files from there to the Trusted.

If it is a publicly accessible server, you should place it in the DMZ - this is what zoning is all about. Setting up a server with two interfaces - one in the DMZ, one in the trusted network - just circumvents the very idea of a separate DMZ, making it entirely superfluous.

With the server in the DMZ, in general you should

1. decide if the data placed on it is generally safe to be copied and used within the "Trusted" network
2. if so, allow for a mechanism of data transfer between the server and the trusted network

You can easily implement 2. by just using the same protocol as your clients - connect via SFTP and pull the data off. This way, you'd save yourself the headaches of a risk assessment for an additional protocol suite.

Edit: I'll try to go with the wiki-like style and incorporate your objections into this answer and comment on them:

The data now lives in the DMZ, I would have to seek an answer for this internally to see if it's permissible. The current solution doesn't physically store the data in the DMZ, it just has a DMZ interface.

Of course it is up to whoever designs your security policy to balance the risk of data theft for data "living" in the DMZ against having a publicly-accessible service virtually hosted in your trusted network. In most cases, you would go with the earlier while minimizing the risk of data theft by keeping the data in the DMZ for a limited time only.

Another option would be implementing a proxy solution for SFTP in your DMZ and forwarding the connections to your "trusted" server - but this would have a yet different attack surface, so it again ends up at balancing risks.

how is that more secure than simply hosting the SFTP in the trusted and allowing for direct connections?

A proxy is typically set up to have a "well-behaving" protocol exchange. This mitigates a whole class of attack vectors based on exploiting weaknesses in the protocol implementation at the server side (e.g. buffer overflows). Some proxy setups may allow you to specify restrictions on what a user can or cannot do - a capability used to reduce the attack surface by only allowing necessary operations.

But a proxy is just a piece of code prone to bugs just as is every other piece of code - it will have own attack vectors. The threat modeling and risk assessment for a "water gate" setup with two servers and polling is easier to assess.

I need the process to be automated, so I would have to use a file watching service of sorts to watch for incoming files in the DMZ, then forwarding to yet another SFTP server in the Trusted.

Yes, this would be a reasonable thing to do.

Now I really have to administer 2 SFTP servers on each side of the fence.

Correct, but each of them can be a security boundary in itself - this is probably what is going to be a requirement if you are very concerned about the security of data stored there anyway.

A couple of thoughts here to go along with what syneticon-dj is saying:

EDIT: added Nate's point re: Linux learning curve/Windows trade-off.

• If you're comfortable with Linux and/or are willing to invest some time into learning it for this application, I'd discourage the use of Windows for something that is entirely suited for *NIX operating systems like Linux or FreeBSD. I'm not knocking WinSSHD at all (I recently became aware of it and think it's a great product for tunnelling RDP over SSH among other things), but it's just that *NIX and OpenSSH work so well, why bother with Windows and the cost of licensing? *NIX is arguably more secure out the box, especially with something like a Debian minimal install, which is a nice balance of ease-of-use (apt package management) and small footprint.

• Keep your server in the DMZ. You don't need two SFTP servers, you need an SFTP server and an SFTP client on your trusted network that can pull down your files off your DMZ SFTP server as however the business requirements dictate.

  This could simply be an rsync cronjob that periodically does a sync "pull" say every 15 minutes with the --delete-after argument so that no data is left in the DMZ server once it's been downloaded to your trusted host. Adjusted to your tastes, this can be as robust as you need it to be, and is a pretty common pattern (works for 99% of the POP3 implementations out there). You could add some sanity checks and some business logic (validate the data before deleting it) and it could be optimized with an event driven pattern (only fetch when there's new data), but rsync is very efficient on it's own, so you likely can get away with a simple brute-force method like this, especially if this was a manual process to begin with.

  The nice thing is besides some egress (outgoing) rules to permit your trusted SFTP client host to connect to your DMZ network, your DMZ SFTP server, if compromised, has no direct access to anything in your trusted network.