Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

2 Answers 2

up vote 5 down vote accepted

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.

share|improve this answer
    
The 3 issues I see with the server living in the DMZ: 1)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. 2)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. 3)Now I really have to administer 2 SFTP servers on each side of the fence. –  e36M3 May 31 '11 at 15:31
    
I've included your objections into the answer text - feel free to comment... –  the-wabbit May 31 '11 at 15:56
    
The "proxy solution for SFTP" that you refer to, I suppose that's similar to what I have right now, how is that more secure than simply hosting the SFTP in the trusted and allowing for direct connections? –  e36M3 May 31 '11 at 17:13
    
I've incorporated your question and some thought on it into the answer. –  the-wabbit May 31 '11 at 20:12

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.

share|improve this answer
1  
If the OP has experience with Windows and none with Linux, the cost saving in license will be lost on time wasted learning Linux. While linux may be arguable more secure, running a good firewall in front of the DMZ will mitigate most of those exploits. –  Nate May 31 '11 at 21:17
    
@Nate, valid point. Still, substitute Linux + OpenSSH with Windows + WinSSHD and the configuration/advice is still valid. He doesn't need two SFTP servers and the DMZ setup he has is more secure than moving it to the trusted network. –  gravyface May 31 '11 at 21:31
    
@Nate: and I wouldn't call learning a very viable/useful operating system a "waste of time". –  gravyface May 31 '11 at 21:33
1  
Fully agree, single server in the DMZ is the way to go. Both Trusted and External get access to it via SFTP. I didn't say it was a waste of time, I just said the time wasted would cost more money than Windows 2008 R2 Std License. –  Nate May 31 '11 at 22:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.