Managed File Transfer and Security Solutions

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.

DMZ File Transfer Streaming

With regulations such as PCI DSS, Sarbanes-Oxley and HIPAA in effect many companies are now required to put measures in place to ensure that no sensitive data is stored in the DMZ (de-militarized zone).  However, for those businesses who need to provide outside users access to this data, whether it be employees working remotely or trading partners, this poses an interesting problem.  How do you make data available in the DMZ without storing that data in the DMZ?  The answer is DMZ file transfer streaming.

DMZ file transfer streaming is accomplished by using a feature in JSCAPE Secure FTP Server known as a Reverse Proxy. A Reverse Proxy provides a way to create a virtual directory at the user or group level and map it to the account of a remote FTP/S, SFTP or WebDAV server.   

In order to setup DMZ streaming an instance of JSCAPE Secure FTP Server is installed in the DMZ.  A Reverse Proxy is then created in JSCAPE Secure FTP Server that is mapped to an account on any FTP/S, SFTP or WebDAV server located behind the firewall.  A virtual directory is then created at the user or group level that maps to the Reverse Proxy created earlier.

When a user uploads a file it is streamed from client to server in DMZ to server behind firewall.  Similarly when a client attempts to download a file it is streamed from server behind firewall to server in DMZ to client.  This process is completely transparent to the user.  Using DMZ streaming ensures that no data is stored in the DMZ allowing companies to meet compliance requirements while still providing external users access to data.

Phishing looks to FTP to distribute malware

Many phishing emails received today include an attachment or HTTP link designed to get users to install some malware (virus).  Fortunately most system administrators have been able to combat this by using SMTP and HTTP gateway products which detect viruses before they get to the end users system.

However, in this constant battle of good v.s. evil the bad guys have gotten smarter and are now distributing malware via FTP.  This malware distribution is partly enabled by browsers and HTML enabled email clients which support FTP URL's.  FTP URL have the following format:

ftp://user:password@host:port/path

FTP URL's may be used in HTML pages and HTML formatted email messages making them appear just like any other standard HTTP hyperlink.  In order to get around the HTTP and SMTP gateways, phishers have started to use FTP URL's in their email messages.  Since the FTP protocol is not scanned by HTTP and SMTP gateways malware can go undetected by gateway software.

At the source of the issue, many of the FTP servers that are distributing malware are rogue servers compromised using brute force password attacks.  In fact, recently a database of 8,700 compromised accounts was discovered, many belonging to Fortune 500 companies.  Brute force password attacks are automated and try to gain access to an FTP server by using common usernames and passwords.  FTP servers that do not protect against this kind of attack or enforce password policies can be vulnerable to these types of attack.  Additionally, given that brute force attacks may require several thousand login attempts they can be a huge drain on server and network resources.

Using JSCAPE Secure FTP Server you can easily configure your FTP server so it is not vulnerable to this type of attack. 

For information on configuring your server to prevent these types of attacks please see the following documentation links:

http://www.jscape.com/secureftpserver/docs/settingconnectionpreferences.htm

http://www.jscape.com/secureftpserver/docs/defining_password_compliance.htm

Ad Hoc File Transfer Explained

It's 4:30 on a Friday afternoon and you need to send one of your key customers a document before the end of the day. The problem is that the document is several MB in size and sending the document by email attachment is not an option as this would likely be rejected by your customers SMTP server. You could create a temporary FTP account for this customer, but this process takes time working with your IT staff, not to mention the time it may take to make any necessary firewall changes to your and/or your customers network and explain to your customer how to connect and download the file. What do you do?

This is where the Ad Hoc File Transfer module available in JSCAPE Secure FTP Server comes to the rescue. Ad Hoc File Transfer is a method of file transfer designed to avoid the pitfalls of email and FTP based file transfer with your external customers and trading partners.

Process

1. Upload file to JSCAPE Secure FTP Server Web Gateway using secure HTTPS.
2. From JSCAPE Secure FTP Server Web Gateway, select one or more files and/or directories and click "Email File(s)" button.
3. Enter recipient email address, optional message and expiration date of download link.
4. A small email message is sent by JSCAPE server to recipient containing your message and web based link(s) to download file(s).
5. Recipient downloads file using secure HTTPS and download is logged for auditing purposes.

Benefits

• Easily send files too large for email attachments.
• No need for IT staff to create and manage temporary FTP accounts.
• Eliminate firewall issues typical between trading partners when using FTP.
• No client software to install. Sending and receiving of file can be done using a simple web browser.

Password Policies Made Easy

The recent release of JSCAPE Secure FTP Server 3.8 now includes support for password policies.  Password policies may be used to ensure that users select strong passwords, enforce password age requirements and meet certain HIPAA, Sarbanes-Oxley and PCI compliance standards.  Administrators can set a password policy to control minimum password length, required characters (e.g. uppercase, lowercase, numeric, non alpha-numeric), password age and more.

For more information or to download:

http://www.jscape.com/secureftpserver/