FTP / DMZ Gateway

Posted on 2011-10-27
Medium Priority
Last Modified: 2013-12-02
I have set up a PC with an FTP client  in our DMZ, but to meet PCI compliance rules it appears that I need to set up a ‘DMZ Gateway’ so that :-
a) the files to be transferred to the remote server are not stored on our FTP client and
b) the FTP client does not have access to the files stored on the main network (apart from using the DMZ Gateway)

We are currently using CuteFTP Pro, but I don’t believe this product offers the functionality that we require. GlobalScape do their EFT software, which does come (at quite an additional cost) with this functionality – see http://www.globalscape.com/eft/dmz_gateway.aspx

Our FTP usage is pretty minimal, so I’d rather not have to incur the cost of the EFT software if possible. Is there other more ‘cost effective’ software that we could use to achieve this?
Question by:Michael986
  • 3
  • 2
LVL 16

Accepted Solution

AlexPace earned 2000 total points
ID: 37046611
Well it sounds to me like requirements specify the GlobalScape product by name.  Did someone from GlobalScape write your them?

Anyway, if you want to save some money you could "roll your own" solution using the GlobalScape product page as a guide.  Specifically, do the things that they say their product will save you from doing

Eliminates the need for compensating methods of securing data in the DMZ, such as file encryption, store-and-forward systems, or polling for changes.

So you have an FTP client instead of a server so we can scratch the "store-and-forward" item because it doesn't apply.  That leaves encryption and polling for changes and that’s not so hard to do on the cheap.

First, set up a secure server on a computer inside your network.  It could be SFTP or FTPS and this takes care of the encryption.  Set up the server software so it runs in the security context of a local user account (not a domain account) and this local account shouldn't really have permissions to much besides the root folder.  If someone manages to take over the server software, they won't have permission to do anything on the computer, and they won't be able to access your network.

Second, in the server software, set it up so that it only accepts incoming connections from the IP address of your DMZ computer.  Third, create a user account that authenticates with a username and a client SSH key (SFTP) or client certificate (FTPS) instead of the traditional username + password.  Fourth, go to the "root" of your secure server and create one subfolder for each of your FTP partners... so one folder for every FTP server you send files to.  Each of these folders should have two subfolders, one named "sent" and another named "error"

Fifth is to configure the firewall between the DMZ and your network.  This should be configured to allow the SFTP or FTPS connection between the DMZ and your secure server.  If you chose SFTP as your secure server this is very easy because everything goes over one port (default 22) but if you chose FTPS you'll need to open one for the control channel (default 21) and a range of ports for the data channel.  Your secure server will allow you to specify a range so you don’t have to just open everything north of 1024 like the FTP spec says.  Just pick a small range of ports off in the middle of nowhere like 22211 to 22222 and configure this in both the secure sever and the firewall.

Sixth is the FTP client that runs in the DMZ.  It needs to be able to run a script that does this: (a) poll the folders on the internal secure server for new files and (b) download them as they are found then (c) upload the file to the appropriate partner according to the subfolder.  It should then (d) delete the local temporary copy of the file and (e) after validating that the upload was successful it should (f) move the original file on the secure internal server to the "sent" or "error" folder as appropriate.  If you need additional delivery confirmation you could have the script logic request a directory listing from the remote server that shows the uploaded file sitting there on the remote site.  The directory listing could be saved as a text file and also returned to the "sent" folder on the secure internal server.

Cute FTP Pro has some scripting capabilities, or at least macros but I’m not sure if it can do all of these things.  I would probably use Robo-FTP installed as a Windows Service on the DMZ machine because its scripting language has good error handling and you can do stuff like have it automatically retry a failed transfer X number of times before giving up.

As for the internal secure server I’d say if you already have something that you are comfortable with then use it.  Microsoft IIS is free but it can’t do SFTP and I’m not sure if you can use client certificates for authentication on FTPS.  FileZilla is also free and it can do SFTP and FTPS but setting up client SSH keys is a pain and IIRC requires external tools, maybe PuTTYgen or something… I don’t recall.  Robo-FTP also has a server but it is not free.  It is however extremely easy to set up in SFTP mode because it can generate its own SSH encryption keys.  
1. Download from here: http://www.robo-ftp.com/download/
2. Install the software then run the "Server Console" ... click thru the 30day eval stuff at the beginning.
3. Click the "Install" button to start it as a Windows Service under the default Network Service account
4. Click the "SFTP Server" menu, switch to Server Keys tab, create both keys then click "Apply" button
5. Switch back to "General Settings" tab, choose root folder then click "Start SFTP" button
6. Click the "Users" menu, click "New" button, type user name, select SFTP radio button
7. Select "SSH public key" in the SFTP authorization method dropdown.
8. Click the "Manage SSH Public Keys" button and import the client key then click "OK" then "Apply"

Since, in this case, you would be in control of both the client and the server, there would be no harm in using the Robo-FTP server software to generate the authentication SSH keys for the client, even if you don’t use Robo-FTP client.  If you choose one of the other servers you can use PuTTYgen for this purpose.
LVL 16

Expert Comment

ID: 37046800
So anyway, once you do all that you send a file to your FTP partners by dropping them into the appropriate folder.  The files will be fetched by the FTP client and sent automatically so it becomes a sort of messaging system built on files and folders.

Author Comment

ID: 37054681
Thanks for your very comprehensive answer.

Since asking, it looks like we're actually going to need an FTP server as well as the client running in the DMZ, as we're now looking to receive as well as send sensitive cardholder data. This may push me more towards the GlobalScape EFT solution.

However, just wanted to clarify one thing - in the 'sixth' section, point b) is to download the file to the DMZ server before it is FTP'd and then deleted. However this storing of the file locally (for however short a period) seems to me to contravene the PCI requirements - ie that 'sensitive' data cannot be held / saved / stored in the DMZ.

Is there any (easy) way around this? or should I accept that I'm going to have to buy the EFT / DMZ Gateway software or something siimilar? Is there something similar that you're aware of?
LVL 16

Expert Comment

ID: 37058196
The PCI-DSS require a setup like this:

Internet <> Firewall <> DMZ  <> Firewall <> Cardholder data

So computers on the Internet can't connect directly to computers with cardholder data, the connection needs to be proxied through the DMZ.

Now you might reasonably ask, "If I put cardholder data in the DMZ, doesn't the DMZ now become part of my data environment?" but computers in the DMZ are exempt from 1.3.3 and 1.3.5 so no.  So then you ask "Why don't I just put everything in the DMZ and be done with it?" and this is the point where the PCI consultant makes a joke about you over-analysing everything and tries to move on without answering the question but the real answer is that this is a problem with PCI itself.  Just read this part of the PCI-DSS for yourself and you'll see what I mean.  Do some googling for forums where people discuss these exact issues.

The file forwarding logic I discussed above is more secure than the proxy solution contemplated by PCI-DSS because the user (or process) sending the file needs no information about the remote host server.  A person can't be tricked into giving up a connection credentials if they don't know the credentials.  The people just know "when I want to send a file to Acme Corp, I put it in the folder named Acme Corp and when I want to send a file to Happy Bank, I put it in the folder named Happy Bank.  Also, you won't hvae to worry about the user downloading anything they should from the remote site be while they were supposed to be just uploading a file.

These same factors are also true if you use a forwarding FTP server in the DMZ.  The internet computers that connect to upload files will only have login credentials to the FTP server in the DMZ.  There wont be any other files that internet users could download improperly because files are forwarded to the internal server immediately upon upload and then deleted off the DMZ server so in this way it acts like a mail slot or night deposit box where you can put stuff in but not take anything out.

Author Closing Comment

ID: 37059954
Thanks - I had already questioned our PCI assessor with regard to this section of the requirements, and with your comments I will push a little harder to get him to explain exactly where (and why) we fall fould of the requirements with this sort of setup

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Have you ever stumbled upon a software that is so great that you just love? It happened to me. Love at first sight. Filezilla Server.   Ok its not the most advanced ftp server I've came across. But its a fairly simple piece of software to get the …
This article was originally published on Monitis Blog, you can check it here . Today it’s fairly well known that high-performing websites and applications bring in more visitors, higher SEO, and ultimately more sales. By the same token, downtime…
Michael from AdRem Software outlines event notifications and Automatic Corrective Actions in network monitoring. Automatic Corrective Actions are scripts, which can automatically run upon discovery of a certain undesirable condition in your network.…
In this video, Percona Director of Solution Engineering Jon Tobin discusses the function and features of Percona Server for MongoDB. How Percona can help Percona can help you determine if Percona Server for MongoDB is the right solution for …
Suggested Courses

840 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question