Managed File Transfer and Security Solutions

Open up corporate data to your partners

  Exchanging data with business partners is very a common scenario, for diverse businesses this process is crucial for smooth operation. The data not only needs to be transferred on time but also in a secure fashion, many times companies make use of specialized client programs to convert data and then transfer them to external business partners. JSCAPE Secure FTP Server can help solve both issues of time & security by making use of secure file transport protocols such as SFTP, FTPS and HTTPS. When selecting which transport protocol to use it is important to understand how each protocol works and what benefits it offers in any given business scenario.

  FTPS is an addition to the common FTP protocol by adding support for Transport Layer Security (TLS) & Secure Sockets Layer (SSL). FTPS has two formats namely Implicit and Explicit SSL. The difference between the two is that explicit SSL 'explicitly' requests the server to provide a SSL encrypted channel while in implicit SSL no such request is made by the client; the server in implicit mode simply assumes that the client will initiate an encrypted connection. It is important to note that FTPS like FTP operates on two channels namely the control channel and the data channel. The connection channel is used to send commands and the data channel is utilized to transfer the actual data. By default only the connection channel is encrypted and the data channel is left unencrypted, not all servers automatically encrypt the data channel, the server has to be instructed to perform data channel encryption. On JSCAPE Secure FTP Server data channel encryption can be enabled by going to <Domain> -> Services -> FTP tab on the Server Manager. When to use data channel encryption depands on your business needs, if the data is of highly sensitive nature, enabling this option is as easy as clicking your mouse button.

  Another aspect that adds to FTPS is the use of client and server certificates. A client certificate is utilized to identify the client to the server, in other words the client presents a token of authenticity to the server. A server certificate is utilized to identify the server to the client, in other words the server verifies that it is indeed the correct server that the client is connecting to. By utilizing both client and server certificates FTPS is highly secure and extremely reliable mode of transport. On JSCAPE Secure FTP Server FTPS client certificates can be enabled by going to <Domain> -> Services -> FTP tab on the Server Manager.

  SFTP is an alternate to FTPS protocol. Unlike FTPS which is command based, SFTP is a packet based protocol & comprises of only one transfer channel. Note SFTP is not FTP over SSH and certainly not Simple File Transfer Protocol, SFTP is used as a subsystem of the SSH protocol, very often SSH version 2 is utilized. SFTP is always secure, there are no implicit or explicit modes of transfer as in FTPS protocol, it consists of a single, always encrypted channel. SFTP is not necessarily faster than FTPS but instead offers a suitable, equally secure alternative to FTPS protocol.

  SFTP supports public-key authentication which is in some ways similar to FTPS client certificates. Public key authentication involves making use a public-key pair which consists of a private key and public key. The public key is installed on the server while the private key is given out to the end user. Everytime the user needs to interact with the server they will need to provide this private key, optionally the private key can also be protected by a pass-phrase, this offers extra security on top of the security on offer by the private key itself. JSCAPE Secure FTP Server fully supports SFTP public key authentication.

  HTTPS is the default choice if you want to allow your partners to access your data via a web browser. HTTPS adds to HTTP by making use of TLS/SSL to provide encryption and secure identification of the server. HTTPS security is largely based on known certificate authorities such as Verisign. The certificate from a known issuing authority is installed on the server allowing connecting clients to identify the Certificate authorities and hence validating the server identity.

  In addition to secure transfer, JSCAPE Secure FTP Server also supports PGP Encryption & Decryption. The makes it possible to store files on the server in encrypted form, e.g. upon a file upload the file can automatically be encrypted and stored on the server by making use of built-in PGP Encryption on JSCAPE Secure FTP Server. Note that it is not possible to PGP decrypt a file before file download, the decryption has to be performed on the client side using an optional PGP private key in a dedicated PGP client program such as PGP Desktop. Thus JSCAPE Secure FTP Server offers an additional layer of security beyond secure transfer.

Access vital corporate documents on the go

 JSCAPE Secure FTP Server is a platform independent managed file transfer server that supports FTP, FTPS, SFTP, HTTP, HTTPS and WebDAV protocols. What this essentially means is that if you have a client program that supports these protocols, you can access the services created on JSCAPE Secure  FTP Server. This includes desktop based client programs & mobile hand-held devices such as iPhones, Windows Mobile and BlackBerries.

  Desktop programs offer a wide variety of client programs which can be used to access JSCAPE Secure FTP Server. An example of a commonly used program is FileZilla which supports FTPS/FTPES, FTP and SFTP protocols. JSCAPE Secure FTP Server supports creating custom HTML forms which can be integrated with the server's built-in web interface. An article describing how to use this feature can be found here .

  Typically the majority of hand-held devices do not have rich client programs which support secure protocols, these programs typically fall in the realm of laptop and desktop based machines. Therefore the first task is to acquire a program which is compatible with your hand-held device. For example an SFTP client program for BlackBerry can be found here . Once the client program is installed you can access the documents on JSCAPE Secure FTP Server just as you would from a client program on a laptop.

  A common concern when accessing documents on mobile devices is the secure transport of the documents, i.e. the documents are not transferred over a clear channel as this may expose private information to prying eyes. It is important to understand that the security of the transfer is dependent on which transfer protocol is employed and not so much on the client or the server. SFTP, FTPS & HTTPS are all secure ways to transfer files. SFTP employs SSH (typically version 2) to encrypt the data packets while FTPS and HTTPS use SSL to encrypt the transfer channel. Keeping this point in mind; rest assured that as long as you use these protocols your data is safe.

  The effectiveness of mobile devices and JSCAPE Secure FTP Server can be illustrated with a simple example. Assume that one of your users has a mobile device with email enabled. You need them to quickly have their signature on a time sensitive document, however your user is at a location where there is no laptop in sight. The way to resolve this is to enable Adhoc Email on the Server Manager and then send an email containing the file link using the web interface to their email address, the link will be delivered to the mobile device where it can download the file, edit it and upload it back to the server. This of course assumes that the client's mobile device has a proper client program installed to upload the file.

  Now imagine that both you and your client are at locations where you cannot access a laptop. With the appropriate dedicated File Upload triggers (for both users) existing on the server you can upload the file to the server using your mobile, this will send out an adhoc email to your client, the client in turn can modify and upload the file using his mobile which will send out an adhoc email back to your mobile device. Moreover this entire scenario can be carried out securely over secure transfer channels provided both you and your client use a SFTP client on the mobile device to send / recieve files and an SMTP server using secure protocol is used (e.g. Gmail's SMTP server operates over SSL or TLS ). Thus one can see that using mobile devices in conjunction with JSCAPE Secure FTP Server features can help towards saving precious business time & provide peace of mind through secure file transfer.

SFTP and Encryption

   SFTP is a network protocol that facilitates file transfer, access and management over a reliable data stream. Do not confuse SFTP with FTP over SSL (FTPS), Simple File Transfer Protocol and FTP over SSH. SFTP is a binary, packet based protocol in which the client and server communicate with each other in the form of packets. It is used as a subsystem of SSH protocol version 2 as the underlying protocol, hence SSH is responsible for providing SFTP with security & authentication.

  When a client attempts to establish a connection via SFTP there are two layers that come into play, these are the Transport & Authentication layers. The Transport Layer handles initial key exchange, server authentication, determines what encryption algorithm to use, decides whether to employ compression & performs integrity verification. The Authentication Layer handles client authentication and employs a number of methods to accomplish this including password, public-key cryptography, keyboard-interactive, GSSAPI authentication using methods such as Kerberos or NTLM.

  When considering encryption & SFTP there are at least two factors you need to take into account: 1) Encryption algorithm for file transfers 2) Public key authentication; if you intend to use it.

Encryption algorithm (ciphers) for file transfers

  The encryption algorithm (cipher) mutually decided upon by the server & client is used to encrypt data packets from the sender and decrypt data packets on the receiver. The choice of the cipher depends on encryption strength, encrypt-decrypt speed and sometimes business requirements.  E.g. Serpent cipher is more secure than the 3DES & runs significantly faster than the DES cipher. Blowfish cipher is faster than 3DES but less secure. The encryption strength and speed is partly dependent on part on the block & key size of the cipher, e.g. AES has a fixed block size of 128 bits and key size of 128, 192 or 256 bits, AES 256 would be more secure than AES 128 but the former would be more secure than the latter.

  Note that you should not compare encryption-decryption speed & strength based on key size when considering different algorithms. E.g. while it may be helpful to compare AES-128 and AES-256, it would not be wise to compare blowfish 256 bit to AES 256 bit cipher without considering the actual implementation of these algorithms.

Public key authentication

  Public-key authentication consists of public-private key pair. The public key is installed on the server and the private key resides with the user. Messages are encrypted using the recipient’s public key and can only be decrypted with the private key. Note that it is near impossible to derive the private key using the corresponding public key therefore the security of the public key authentication mechanism depends largely on the safe keeping of the private key by the user; if it is lost the user account can be compromised. Keys are generated using asymmetric algorithms typically RSA & DSA. While both of these algorithms are secure it is generally accepted that RSA‘s strength is verifying while DSA is faster at key generation. 

Streamlining web uploads with ZIP archives

JSCAPE Secure FTP Server offers both HTML and Java applet based user interfaces.  One of the advantages of the Java applet interface is that it can be used to transfer entire directories recursively.  This is in comparison to the HTML interface which requires that each file must be selected prior to upload.  Additionally, the Java applet interface includes a ZIP Upload feature which is the focus of this article.

ZIP Upload

The ZIP Upload feature, available only in the Java applet interface, allows you to select one or more local files/directories for upload.  These files are compressed into a single ZIP archive prior to upload.  The advantages of this feature are:

1.  Single connection.  When uploading multiple files without using ZIP Upload a new connection for each file must be made prior to upload.  For a large number of files this can take some time given that each file requires it's own connection.  In the case of very small files (e.g. < 5KB) you can find that the amount of time to make the connection can exceed the amount of time needed to transfer the data.   Using the ZIP Upload feature all files are compressed into a single archive before transfer.  This means that only a single connection is needed to transfer the file.  Compare this to several hundred connections needed for an equal number of files when not using the ZIP Upload feature.

2.  Data compression.  Your files will be compressed prior to transfer.  This compression makes your files smaller and ultimately reduces the amount of time needed to perform a transfer.  The amount of data compression depends largely on the source files.  For example, text files tend to offer much better compression than binary files. 

Using ZIP Upload

To use the ZIP Upload feature perform the following:

1.  After login, switch to Java applet interface.  Note, you must be running Enterprise edition of JSCAPE Secure FTP Server and have WebDAV service enabled for this option to be made available.  Next, select the local files and/or directories to be uploaded.  The ZIP Upload icon is then enabled.

2.  Next you will be presented with a dialog that prompts you for the name to use when creating the ZIP archive.  This will also be the name used when storing the archive on the remote server.  Enter the desired destination filename and click OK.

 

3.  The selected files are automatically compressed and uploaded to server using the filename provided in previous dialog.

Using regular expressions in complex trigger conditions

Introduction

       The purpose of this article is to demonstrate how one can use regular expressions to create complex trigger conditions in JSCAPE Secure FTP Server. Regular expressions provide a concise means for identifying strings of interest e.g. words or pattern of characters. JSCAPE Secure FTP Server follows the regular expression rules as defined by the Java programming language, a complete guide to Java regular expressions can be found here.

Demonstration & Examples

       This feature is best illustrated by providing concrete examples demonstrating what can be achieved with this feature. Starting with a timed trigger example, we will upload all text files from a specific directory starting with "John" every 15 minutes to a server location.

1) Start JSCAPE Secure FTP Server Manager.

2) Create a trigger as follows :

    Select "CurrentTime" from the Event Type dropdown. Type in an appropriate name and click 'Next'. The next screen is demonstrated below :

   

    Look at the condition specified : Minute MATCHES REGEX 0|15|30|45

    What does this mean? This means that the trigger action will occur every 15 minutes. What if I wanted to execute the trigger action every half hour, for this latter requirement one would use the following regular expression : 0|30

   Click on 'Next' button and setup a 'Ftps Regex File Upload' trigger action, for this to work you would have to setup Ftp Implicit or Explicit SSL service, this latter step can be done through the Server Manager. The important property of the trigger condition is the 'Regular Expression' field, fill it in with "John.*.txt" (without the quotation marks).

    The expression is : John.*\.txt

    This means : "John" followed by any number of any characters including the space char. Filename must end with ".txt". Therefore "John Lenon.txt" is valid, "John Abraham.txt" is valid, "John.txt" is valid but "Simon Lenon.txt" is not valid.

    Apply the condition triggers so the server can begin uploading the files every 15 minutes. For verification go to the local directory where the server is installed and verify that files are uploaded, verification can also be done by looking at the server logs as it will record all files uploaded and the fact that the trigger action was executed.

    For all Johns with second name starting with either with A or a B and absolutely no other letters. For this I would use the regular expression :   John [AB].*\.txt 

    For all names ending with "Roland" I would use the following regular expression :    .*\ Roland.txt

    A more complex example :  John [AB].*\(Lennon){1}.txt   

   John followed by a space character, second name starting with either A or B, followed by any number of characters, followed by 1 "Lennon", ending with ".txt". Therefore "John Abraham Lennon.txt" is valid, "John Abraham Lennon Lennon.txt" is also valid. Why is the second name valid? - because there is one "Lennon" in the whole name, however "John Abraham.txt" is not valid since it does not contain a "Lennon".

    As you can probably see that any regular expression which can be used in Java can be used in JSCAPE Secure FTP Server trigger / action mechanism. Where is this example useful? One common scenario could be database backups where you could set the trigger to fire every 24 hours and filter which database files to upload to a remote server location based on the regular expression used in the Ftps Regex File Upload 'Regular Expression' field. You could have multiple triggers for different name groups backing them up to a different server location, E.g. one trigger / FTPS regex upload action which could handle all files starting with A, another trigger / FTPS regex upload action which could handle all files starting with B to a different location.

   The business functionality which can be constructed around these trigger / action / regular expression combo can be quite significant, consider doing this in a traditional coding application route : you would have to write significant code to handle all this, on top of that if you are adamant about using a tier architecture for coding as is the norm in large web / commercial applications it could mean a lot of work. Instead JSCAPE Secure FTP Server can really come in handy here for these data handling jobs. Once the triggers / actions are setup the user can just leave it running and it continue to perform it's work, meaning there is little work for the server administrator in such a scenario.

   It should come as no surprise that regular expressions can be used in other scenarios such as File Downloads / File Uploads. For example the following screen shows how a multiple condition for File Uploads can be setup in JSCAPE Secure FTP Server :

 

    We can see here that there are two conditions :

1) The file must be successfully uploaded.

2) The file name must satisfy the regular expression : John [AB].+\(Lennon){1}.txt

    The regular expression has the following meaning :

    John followed by a space character, followed by either A or B, followed by atleast one other character,
followed by one "Lennon" word group, followed by ".txt". E.g. John ArLennon.txt is valid according to this expression but John ALennon.txt is not valid since there are no characters after "A".

    A similar setup can also be done for File Download scenarios :

    

  We can see here that there is the condition :

*) The file name must satisfy the regular expression : [ABC].*\

    The regular expression has the following meaning :

    The username must begin with A, B or C followed by any number of any characters.

    Where can one use this? If the business functionality requires that a confirmation of the download is sent to the user once he / she downloads a file this trigger can be used together with a "Send Email" action to send a confirmation of the download to the user which has a username satisfying the regular expression. Thus a email will be sent to the user with a username of "Abacus" but it will not be sent to a user with a username of "Zeus".

    Another scenario where this process can be useful is the "Directory Monitor File Changed" where the action which could possibly be a File Regex Upload  can filter files by a providing regular expression. Directory Monitor File Changed trigger is fired when a file in a monitored directory is changed.

    Thus we can see that the business functionality that can be constructed is virtually limitless, a knowledge of Java regular expressions is perhaps the only limiting factor here. The link provided in the "Introduction" should help in this regard. Also note that JSCAPE Secure FTP Server has a built in "Test Expression" feature which allows you to confirm whether the expression is correct or not, this on the fly feature can make life very easy and greatly help in expediting the process of setting up this functionality.

 

Using custom forms to automate business processes

        JSCAPE Secure FTP Server 5.2 (link) introduces a new 'forms' feature which can be used in conjunction with the existing Web Based file transfer option. The aim of this feature is to provide custom information with web based file uploads. This can be used to carry out a specific business function. In this article will demonstrate how this can be achieved by a simple example : to provide custom shipping options for order processing.

The following steps will be carried out :

1) Create a custom form in JSCAPE Secure Server Manager to manage the shipping options.
2) Create a File Upload trigger in JSCAPE Secure Server Manager. This trigger will have a 'Send Email' action which will be executed on a successful file upload.
3) Upload an electronic receipt of the order via the existing web based interface of JSCAPE Secure FTP Server.
4) Set the options in the form created in step 1)
5) Confirm that the forms work by verifying the sent and received emails.

NOTE : WebDav and HTTP services must be present in the 'Services' tab of the Jscape Secure FTP Server to carry out this example.

The above steps will be illustrated with the proper screenshots :

Create a custom form in JSCAPE Secure Server Manager to manage the shipping options

Go to Services -> HTTP, press the 'Forms' button to bring up the following screen :

Click on the 'Add' button :

    Enter the 'Name' and 'Description' field to describe the business function. Make sure the 'Enabled'
checkbox is checked, this will make sure the forms popup dialog is displayed in the web interface when uploading files.

   Add fields to the form by pressing the 'Add' button :

   This field is 'COD', whether the customer will pay when the order is delivered. We can see that this field will be displayed as 'DropDown' with two values : true or false. Note that the values must be comma-separated. 'Required' checkbox is ticked to indicate that the value must be specified.

    In this manner one can add as many fields as required. The various 'Type' fields allow many kinds of values to be entered according to whatever business logic is used to create such a form.

Setup File Upload Trigger and Send Email action

  The first step is to setup the File Upload trigger as you would normally do. After this is done create a 'Send Email' action which has the following fields. In this example I send an email from my gmail account to my alternative email. For this to work the fields under 'Send Email' should be as follows :

Hostname : smtp.gmail.com
Port : 587
Connection-Type : START_TLS
Username  : username@gmail.com
Password  : ************
From : username@gmail.com
To : to@jscape.com
Subject : Shipping Options
Body : %UploadForm.ShippingOptions.COD (Cash on Delivery)%
           %UploadForm.ShippingOptions.Packaging%
           %UploadForm.ShippingOptions.Signature%

When entering the 'Body' data click on 'Add Variable' button and you will see the various Form fields you created in the step 1). This makes it convenient to embed data in the email.

Attachment : %LocalPath%

When entering Attachment select %LocalPath% from the 'Add Variable' options. This will provide access to the uploaded file.

   For this example I have HTTPS running on port 443 in JSCAPE Secure FTP Server Manager. Keeping this in mind I go to by using my browser : https://localhost:443/action/login? . After selecting a file for upload and pressing the 'Upload' button the following popup is displayed. We can clearly see the ShippingOptions form is present in the popup :

 

Press 'OK' to bring up the options :

 

We can see here that the fields shown correspond to what we created in step 1. Select the appropriate options and click 'OK' to upload the file and send the email. To confirm check the 'Sent' folder of the sending email. Confirm the receiving email receives the email containing a print-out of the options selected in this pop-up form.

 

Public key authentication with SFTP

Overview

         The purpose of this article is to demonstrate public-key authentication in SSH/SFTP. SSH uses public-key cryptography to allow the remote computer to authenticate the user. SSH is typically used to log into a remote machine and to execute commands (e.g. logging into a remote unix machine). It can also be used to transfer files using the SFTP protocol. An SSH client program is typically used for establishing connections to an SSH server accepting remote connections (e.g. AnyClient).

Key Authentication

         First, a pair of cryptographic keys is generated. The first of these keys is the public key and this resides on the remote server and is used by SSH to authenticate users who have the correct matching private key. The private key resides with the user and can be protected by a passphrase. When a user connects to the remote server both the private key and the passphrase are required in addition to the username/password combination. An SSH server, by default, listens on the standard TCP port 22.

         In the following demonstration we are going to use Jscape Secure FTP Server as the remote server and AnyClient as the local client. This is laid in a series of steps :

Step 1 (Generating a client key)

        Go to 'File -> Key Manager'. This will bring up the following screen :

Click on the 'Generate' button. This will bring up the following screen :

 

'Alias' is simply a name given to the generated key. These names can then be used to assign keys to
specific user(s). (The tutorial will show how to do this at a later stage)

'Period' - The number of days this key is valid.

'Common Name' - The name you wish to assign this key.  For a client key this is typically the full name of the user e.g. John Smith.

'Organizational Unit' - The unit within the users organization that this key will be used for e.g. IT.

'Organization' - The users organization name.

'Locality' - The users city.

'State/Province' - The users state or province.

'Country code' - The users 2 character country code e.g. US.

Press the 'Ok' button after you have provided all of the above fields. This will bring up the following screen :

'Private key file' - The file you wish to export the private key to. This should be a valid 'PEM' file (e.g. license.pem). SSH authentication at this time only supports 'PEM' file types.

'File password' - The password used to protect private key.  Leave blank for no password.

'Certificate file' - The file you wish to export certificate to. (This is not a required step)

'File type' - The format in which you wish to export certificate.

'Public key file' - The file you wish to export public key to.

'File type' - The format in which you wish to export public key.

When the 'Ok' button is pressed the license file is generated and saved to the specified location. However at this stage it cannot be used to connect from a client program. It needs to be assigned to user account(s) on the server. The article will demonstrate how to do this next :

Step 2 (Assigning generated keys to a user account)

        Go to the 'Users' node under the server node. This will display a 'Users' tab displaying the users for this account. Select the account you want a assign a authentication key to and click the 'Edit' button. This will bring up the following screen :

        Select the 'Info' tab as shown above. As you can see in the 'Client keys' section there are two keys available. I created these keys when writing this tutorial. You can select as many keys as you want to assign to the user. Remember that each key will have a separate valid PEM file that resides with the client (the user that connects to the remote server). Click the 'Ok' button to finish and save the assignment of keys.

        This finishes the creation and assignment of authentication keys. Next we will show how to actually use this authentication key from a client program (AnyClient).

 
        Start AnyClient on your PC. Go to 'File -> Site Manager'. This will bring up the following screen :

 

           We will need a site to connect to the remote server. Click on the 'New' button on the screen above.  This will bring you to the following screen :

   

   I created a site called 'TestSite' with the settings shown.

   'Host' - the name of the remote server. Port 22 is used for SSH connections.

   'Username' - username of the account on the server.

   'Password' - password of the account on the server.

   'Connection Type' - Set this to 'SFTP/SSH' for the purposes of this tuorial. This will enable extra     authentication options that must be provided before a successful connection can be made :

     -) 'Private Key File' - this is the private key file generated from Step 1 above.

     -) 'Key Password' - this is the private key file passphrase set in Step 1 above.

     -) 'Use public key authentication' - Select this checkbox to use public key authentication.

     -) 'Use password authentication' - Select this checkbox to use password enabled authentication.

   The last two of the above options depend on the type of authentication the server expects for SFTP/SSH connections. This can be controlled by performing the following steps :

     1) Select 'Services' node under Jscape Secure FTP Server.

     2) Select SFTP service under the Services tab.

     3) Click the 'Edit' button.

    This will bring up the following screen :

   

    Note that I used 'password AND publickey' option for the 'Authentication' category. Hence I need to select both 'Use public key authentication' and 'Use password authentication' checkboxes on the AnyClient connect option screen (previous screenshot). Click 'Connect' on the AnyClient screen, provided you have completed all steps correctly and provided all the right credentials AnyClient will forward you to it's file transfer interface screen.

 

 

Best Practices for Configuring Your FTP Server

As a developer of secure file transfer software we frequently have customers ask us what the best practices are when configuring their FTP server software.  The following are a set of best practices we ask each customer to consider during setup and configuration.  These best practices are catered primarily to users of JSCAPE Secure FTP Server but should be considered regardless of what server software vendor you are using.

Transport Services and Security

The first question you should ask yourself is what file transfer services you want to offer.  There are several file transfer services available including FTP, FTPS (FTP over SSL), SFTP, HTTP/S and WebDAV.  Which services you choose may depend on several variables which include but are not limited to: existing processes or software, availability of client software, firewall restrictions and network security. 

If you have existing processes that rely on certain services then short of rewriting those processes the decision has already been made for you.  Rewriting processes is typically only necessary if you are wanting to move from an insecure protocol such as FTP to a secure protocol such as FTPS or SFTP and vary in complexity.

Most file transfer clients today support FTP, FTPS and SFTP protocols so locating compatible client software is generally not an issue.  However, supporting these clients and the costs associated with them can be expensive.  If possible it is best to standardize your users on a single client in order to reduce support costs.  If you are hoping to avoid client software altogether you may consider using a browser based client such as the HTML and Java based clients provided in JSCAPE Secure FTP Server.  These clients require no installation and no per-user license fees reducing your support and licensing costs considerably.

If your server is behind a strict firewall that restricts most inbound traffic it is recommended that you stick to SFTP, HTTP/S and WebDAV services if possible.  FTP is less firewall friendly than the above mentioned services due to the fact that separate ports must be used for data and command channels.  This does not mean that you should not use FTP/S, just that if you or your clients have a firewall be prepared to open a range of ports v.s. a single port for SFTP, HTTP/S and WebDAV services.

If you need to secure your user credentials and data (the only reason not to is to support existing processes) it is important that you select a secure file transfer service.  FTPS, SFTP, HTTPS and WebDAV/S are all secure services that encrypt both your data and user credentials as it travels over the network.  It is important to note however that there are two types of FTPS.  These are known as FTPS explicit SSL and FTPS implicit SSL.  An explanation of their differences can be found here, however suffice it to say that if you are using FTPS you should go with FTPS implicit SSL or FTPS forced explicit SSL.  Both of these methods ensure that users must login using an SSL encrypted session whereas the standard FTPS explicit SSL may allow both encrypted and unencrypted sessions.

Account Permissions

User accounts should limit users only to the data they need to see and to the actions they need to perform.  For example, if a user only needs the ability to upload files then all other functionality such as the ability to download or delete files should be removed for this user. For ease of user manageability it is generally a good idea to create a group or user template which defines the permissions for a group of common user roles.  Users and their permissions can be defined in the Users section of JSCAPE Secure FTP Server Manager.

Password Policies

Part of good network security is making sure that your users choose strong passwords.  This protects accounts against brute force dictionary attacks or easily guessed passwords.  Strong passwords should be a minimum of 8 characters in length and contain uppercase, lowercase, numeric and non-alpha-numeric characters.  Furthermore, users should be forced to change passwords on a regular basis (i.e. every 90 days).   Password compliance settings may be found in the Compliance section of JSCAPE Secure FTP Server Manager.

Trusted Access Lists

If possible it is a good idea to restrict access to your file transfer services to only trusted networks.  This can be accomplished defining a white-list in your firewall or by using the IP Access section available in JSCAPE Secure FTP Server Manager.  Using a white-list you can restrict access to trusted networks, preventing possible DOS (Denial of Service) or brute force password attacks from untrusted networks. 

Detect and Respond to Rogue Activity

Brute password attacks can come from both trusted and untrusted networks.  If you have defined a white-list then this significantly reduces your risk.  You are however still open to attack from your trusted networks.  These attacks can come from your employees, your customers employees and hackers that have gained access to your trusted networks.  To address this risk you should automatically detect and respond to these types of attacks.  A common method of handling this is to automatically block the client IP address from further access in the event client has failed authentication several times within a short period of time.  These options may be set in the Connections section of JSCAPE Secure FTP Server Manager.  In the event that an IP address is blocked an IP Blocked event is raised and client IP is automatically added to IP Access list in JSCAPE Secure FTP Server Manager as a denied client IP.  Furthermore, it is also a good idea to capture the IP Blocked event using a Trigger and respond to that event by sending an email message (using the Send Email action) to a system administrator for further investigation. 

Activity Logging

It is very important that you log all server activity.  After all, in the event your server is compromised it is this log data that will tell you what data was exposed.  If your company is subject to SOX or HIPAA compliance then this is an absolute requirement.  Without this log data then in the event of an intrusion you have to assume that ALL data on the server has been exposed.  For very secure environments you may consider writing your log files to a tamper proof database on a remote server.  The database account used by the server to write log data should have permissions that limit it to appending records only.  This will ensure that database records cannot be updated or deleted to hide activity.  Both file and database logging support are provided and may be defined in the Logging section of JSCAPE Secure FTP Server Manager.

What is the difference between passive and active FTP?

To explain the difference between passive and active transfers it is necessary to cover some of the details of how the FTP protocol works. The FTP protocol uses multiple channels for communication. These channels are known as the command channel and the data channel.

Command Channel

The command channel is responsible for accepting commands from an FTP client and typically runs on port 21 for standard FTP and encrypted FTP using explicit SSL, or port 990 for encrypted implicit SSL connections. The command channel is also responsible for sending replies back to the FTP client in response to client commands. An example of a command sent by an FTP client might be "PWD" asking the server for the current remote directory. The server will respond with a response code followed by the current remote directory such as "257 /home/users/jsmith"

Data Channel

The data channel is used for transferring files and for performing directory listings. Unlike the command channel, the data channel does not run on a single persistent port. Instead whenever a file transfer or directory listing is performed a new (typically random) port is is opened for sending the data (either by the client or server) and the data transfer is performed. Once the data transfer is complete the port is closed. The port on which the data channel is performed and additionally whether the client or server is responsible for opening this port depends on the data transfer mode used. There are two data transfer modes available in FTP. These data transfer modes are known as passive and active a.k.a non-passive. These data transfer modes should not be confused with "binary" and "ASCII" which relates to the format in which data is transferred and not the method in which data is transferred.

Passive Mode

In passive mode the server is responsible for opening the listening port and telling the client what server-side listening IP/port to connect to in order to perform the transfer. To start a passive transfer the client sends the "PASV" command. The server then responds with the IP address and port that the client should connect to in order to perform the transfer. Once the transfer is complete the port is closed by the server.

Active (Non-Passive) Mode

In active mode the client is responsible for opening the listening port and telling the server what IP/port to connect to in order to perform the transfer. To start an active transfer the client sends the "PORT" command along with arguments telling the server what client-side listening IP/port the server should connect to in order to perform the transfer. Once the transfer is complete the port is closed by the client.

Which one should I use?

This depends largely on the FTP server capabilities and configuration. From the client perspective the first question you need to ask yourself is "Does the server support passive connections?". There are some FTP servers, especially those running on older mainframe systems that do not support passive connections. It's also possible that while the server supports passive connections the server may have this feature disabled. This is usually due to an aggressive firewall policy on the server side that disallows passive connections. Naturally, if the server doesn't support/allow passive connections then you will be forced to use active mode. The easiest way to test whether a server supports passive mode is to simply connect using passive mode and perform a directory listing to see what happens. If you get back a directory listing without error then the server supports passive mode. If however you get an error like "500 PASV command not supported" or "500 PASV command disabled" then you will need to use an active connection. In general you should always default to using a passive connection when possible. It is much more firewall-friendly to clients than active mode given that most Internet users today are behind firewalls using NAT software.

From the perspective of an FTP server administrator you should make it as easy as possible for your clients to connect. This means enabling passive mode on your server so that clients who are behind a firewall or router that uses NAT software, can connect easily.

Client Software

AnyClient is a free platform-independent client that supports FTP, FTPS (implicit SSL and explicit SSL) and SFTP protocols.

Server Software

JSCAPE Secure FTP Server is a platform-independent server that supports FTP, FTPS (implicit SSL and explicit SSL), SFTP, HTTP/S and WebDAV protocols.

What is the difference between FTP, FTPS and SFTP?

The most common protocols for file transfer in use today are FTP, FTPS and SFTP.  While these protocols may sound the same, there are some key differences among them.  Learning these differences can eliminate some of the common problems experienced when performing a file transfer.

FTP

The FTP (File Transfer Protocol) protocol has been around for quite some time.  The protocol itself is described in RFC 959 which was last updated in 1985.  The FTP protocol consists of two channels, the command channel and data channel.  These channels are responsible for exchanging commands and data in an FTP client session.

The command channel typically runs on server port 21 and is responsible for handling the exchange of simple commands between FTP server and client.  The USER and PASS commands used for authenticating an FTP user are examples of commands that are exchanged on the command channel.  The command channel remains open until the client sends the QUIT command to disconnect or the server forcibly disconnects the client.

The data channel runs on temporary random ports listening on the server (passive mode) or on the client (active mode) and are responsible for exchanging data in the form of file transfers and directory listings.  The LIST command used for getting a FTP server directory listing is an example of a command that opens a data channel.  Unlike the command channel which remains alive during the entire FTP session, the data channel automatically shuts down once the transfer of data is complete.

FTPS

When the FTP protocol was initially drafted security was not a primary concern.  Since then many things have changed and sending data over the Internet or any other insecure network without encryption is considered a big no-no.  In order to address this issue a set of security extensions to the original FTP protocol were proposed in RFC 2228 that protect FTP data as it travels over the network using SSL encryption.  However, just to make things more complicated, FTPS is available in two forms known as FTPS Implicit SSL and FTPS Explicit SSL.

FTPS Implicit SSL

In implicit SSL mode a required SSL session is established between client and server before any data is exchanged.  In other words, the use of SSL is implied because any attempt made by a non-SSL client would automatically be refused by the server.  Typically FTPS implicit SSL services run on port 990.

FTPS Explicit SSL

In explicit SSL mode the client can optionally switch from unencrypted mode to SSL.  This is useful in that the server can support both unencrypted FTP and encrypted FTPS sessions on a single port, typically port 21. In an explicit SSL session the client first establishes an unencrypted connection to FTP service.  Prior to sending user credentials, the client then requests that the server switch the command channel to an SSL encrypted channel using the client AUTH TLS or AUTH SSL commands.  Upon successful setup of the SSL channel the client then sends user credentials to the FTP server.  These credentials along with any other commands sent to server during the FTP session are automatically encrypted by the SSL channel. 

SFTP

SFTP is most often confused with FTPS and vice-versa.  However, unlike FTP and FTPS these protocols are not at all related.  SFTP is actually a sub-system of the SSH (Secure Shell) protocol and typically runs on port 22.  Unlike FTP/S, SFTP does not have the concept of separate command and data channels.  Instead both data and commands are transferred in specially formatted packets via a single connection.  Furthermore, unlike FTPS explicit SSL, SFTP encrypts the entire session and does not offer the ability to switch between unencrypted and encrypted mode.

Client Software

AnyClient is a free platform-independent client that supports FTP, FTPS (implicit SSL and explicit SSL) and SFTP protocols.

Server Software

JSCAPE Secure FTP Server is a platform-independent server that supports FTP, FTPS (implicit SSL and explicit SSL), SFTP, HTTP/S and WebDAV protocols.