FTP / DMZ Gateway

Posted on 2011-10-27
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

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
    LVL 16

    Accepted Solution

    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:
    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

    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

    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

    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

    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

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    How to run any project with ease

    Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
    - Combine task lists, docs, spreadsheets, and chat in one
    - View and edit from mobile/offline
    - Cut down on emails

    Introduction People like FTP.  It's a solid, stable, robust protocol for quickly transferring files between two hosts using TCP/IP.  In most cases it's much faster than SMB or CIFS, and certainly much easier to set up between organizations.  This…
    Preface There are many applications where some computing systems need have their system clocks running synchronized within a small margin and eventually need to be in sync with the global time. There are different solutions for this, i.e. the W3…
    Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
    This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor ( If you're looking for how to monitor bandwidth using netflow or packet s…

    737 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

    Need Help in Real-Time?

    Connect with top rated Experts

    16 Experts available now in Live!

    Get 1:1 Help Now