Articles and news

SFTPPlus on the OSI

The OSI model is a model that characterizes and standardizes communication functions. The layers range from layer 1 right through to layer 7. In the OSI, or Open Systems Interconnection model, SFTPPlus sits in the OSI Layer 7 or on the application layer.

The application layer sits at the top of the OSI model and is the software, hence the name application, layer between the end-user and the networking layers underneath.

In order to have a fault tolerant system, SFTPPlus on the upper layer 7 will need to be integrated with the bottom layers.

About high availability

High availability means creating a system that is always available for use. It could be a percentage of 99.99% uptime guaranteed. In this case, you will be looking at a downtime of merely five minutes of time over the course of the year.

There are extra items that one can add to ensure that this system is available at the guaranteed uptime rate. In this case, one can look into active-active or active-passive scenarios. To build a system that is highly available means that there may be an additional cost associated with ensuring this.

Diagram example: Integration for load balancing

Diagram example: Integration for high availability

Active-Passive configurations

Setup: A single Adaptive Server runs either on the primary node or on the secondary node. The Adaptive Server runs on the primary node before a fail over and the secondary node after fail over.

Failover: When a system fails over, the Adaptive Server and its associated resources are relocated to, and restarted on, the secondary node.

Failback: Failback is a planned fail over or relocation of the Adaptive Server and its resources to the primary node. Failback is not required, but can be done for administrative purposes.

Client Connection failover: During failover and failback, clients connect to the same Adaptive Server to resubmit uncommitted transactions. Clients with the failover property reestablish their connections automatically.

How to set up SFTPPlus in active-passive scenarios

In this infrastructure scenario, the second system is offline and only commences when the main SFTPPlus system is down.

Since the server.ini configuration is stored in a single file, you can create a file copy task to keep the system configurations in sync. Make sure to also transfer additional files that are required - such as SSH keys, and SSL keys and certificates - to ensure a smooth transition. When it is time to use the secondary system, the SFTPPlus instance will then read the latest server.ini configuration file.

How to set up SFTPPlus in active-active scenarios

In this infrastructure scenario, both SFTPPlus systems are receiving and processing requests. If one system goes down, the other will handle all the requests.

To implement SFTPPlus in this scenario, a simple file copy will not work. This is because running SFTPPlus instances will not check changes in the local file configuration (server.ini) in order to reconfigure. In addition, there are other files that are also required - such as all SSH keys in use and other related files, all SSL certificates required, any logs that need to be kept for auditing purposes, any externally referenced scripts used in pre- and post- transfer processing, and so on.

One method of achieving an active/active implementation is to manually set up the 2 nodes to rely on a single external authentication method (HTTP or LDAP). In this way, accounts are managed in the single external system, and those accounts will be automatically available for both SFTPPlus instances.

File Transfer Protocol (FTP)

Shortform for File Transfer Protocol, the objectives of FTP are 1) to promote sharing of files (computer programs and/or data), 2) to encourage indirect or implicit (via programs) use of remote computers, 3) to shield a user from variations in file storage systems among hosts, and 4) to transfer data reliably and efficiently.

FTP has had a long evolution over many years starting with its beginnings published as RFC 114 on 16 April 1971. Over time there has been other forms of file transfer protocols made available as there had been vulnerabilities and weaknesses with FTP such as:

• Brute force attacks which is attacking via computing credential combinations.
• FTP bounce attacks which is an exploit enabling an attacker to use the PORT command to request access to ports indirectly through the use of the target machine as a man in the middle request.
• Packet capture through the use of packet capture tools.
• Port stealing where traffic directed at a port is stolen or intercepted by an attacker.
• Spoofing attack where the attacker may use a tool to try multiple instances of an IP address in order to assume the correct, and therefore spoofing, the host address of the target machine.
• Username enumeration is part of the discovery, or enumeration, process prior to an attack of a network or service by obtaining usernames associated with the service.

There are also limitations to the protocol. For example, there is no ability to encrypt data on transit. Data in transit can be sniffed using freely available tools since the transmissions of usernames, passwords, commands and other data is not encrypted. An attacker can run a packet sniffer over the network can sniff out FTP credentials. In addition, there is no integrity checking of files to ensure that data integrity remains since this is not included as a feature of the protocol.

Hypertext Transfer Protocol (HTTP)

HTTP, shortform for Hypertext Transfer Protocol, is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks.

HTTP, in use by the World-Wide Web global initiative since 1990, is a protocol used in many tasks related to common usage of the web such as browsing websites. This is relevant to SFTPPlus since we offer a browser-based file management utility.

Without SSL/TLS, there is no way to encrypt data in transit. Other downsides to HTTP, in the context of SFTPPlus, include:

• Packet capture through the use of packet capture tools.
• Man-in-the-middle attack where the attacker intercepts and relays false malicious content between two parties.
• Credentials are sent in a plain text encoding when using the SFTPPlus HTTP Basic Auth API.

Implicit FTPS or FTPS Implicit SSL (FTPIS)

FTPIS, or implicit FTPS, is the use of the FTP protocol where secure data transfer is invoked via SSL as soon as the connection starts or after the OK reply is sent by the server. In implicit mode, an FTPS client is expected to “immediately expected to challenge the FTPS server with a TLS ClientHello message. If such a message is not received by the FTPS server, the server should drop the connection.” This means that the use of SSL is implied. This is illustrated in the diagram above.

The advantage is that this service is safer than the use of the FTP protocol due to implementing SSL meaning that data transmission is encrypted.

Explicit FTPS or FTPS with Explicit SSL (FTPES)

In explicit mode, an FTPS client must “explicitly request” security from an FTPS server and then step up to a mutually agreed encryption method. If a client does not request security, the FTPS server can either allow the client to continue in insecure mode or refuse the connection.

The advantage is that this service is safer than the use of the FTP protocol due to implementing SSL. Prior to user connection, both the server and client must negotiate the level of security used.

Notes for both FTPES and FTPIS

Since both are FTPS (FTP over TLS/SSL), they share some common advantages as listed, non-exhaustively, below:

• The advantages afforded by SSL is used - certificate authorities, certification revocation lists, transmission encryption and more.
• Certain regulations and compliance obligations may require data transmissions to be encrypted but it should be noted the difference between FTPES and FTPIS when it comes to which stage the encryption occurs.
• The protocols make use of TLS (Transport Layer Security) encryption. It should be noted that in SFTPPlus, the TLS version can be used

SSH File Transfer Protocol or Secure File Transfer Protocol (SFTP)

SFTP is a network protocol that allows for file access, transfer and management capabilities over the SSH (Secure Shell) protocol channel.

The advantages for SFTP include:

• Designed to be used to implement a secure remote file system service and also a secure file transfer service.
• Runs over a secure channel, SSH, so that the server has already authenticated the client. The identity of the client user should also be available to the protocol.
• Data is encrypted based on a configured cipher list agreed upon by the server and client.
• There is the option to implement user access via SSH keys only or via a combination of password and SSH keys. If authenticating via SSH keys, the client does not need to go through password recollection so long as the SSH key is correctly configured on the server.
• Certain regulations and compliance obligations may require data transmissions to be encrypted.

The SFTP protocol follows a simple request-response model where each request and response contains a sequence number and multiple requests may be pending simultaneously.

HTTP over SSL/TLS (HTTPS)

HTTPS, shortform for HTTP over TLS, provides security measures in using HTTP via SSL and its successor, TLS.

The HTTP protocol is further secured via SSL and its successor, TLS (Transmission Layer Security), thus this is referred to as HTTPS. HTTPS provides end-to-end security for browser-based applications.

Other advantages to using HTTPS:

• TLS can harden TCP against Man-in-the-middle attacks where clients and servers exchange certificates which are issued and verified by a trusted third party called a certificate authority (CA).
• HTTP Public Key Pinning (HPKP) allows HTTPS website to overcome impersonation via the use of fraudulent certificates.
• Certain regulations and compliance obligations may require data transmissions to be encrypted

Conclusion and next steps

The application of one protocol over the other does not immediately guarantee security. Please consider these services merely as a layer within multiple others when implementing a secure managed file transfer solution.

Since features are constantly changed, we did not touch on any specifics within SFTPPlus. Please consult our documentation for the configuration and operations information, as well as practical users guides.

This resource is written as of SFTPPlus version 3.29.0.

SFTPPlus on the OSI

The OSI model is a model that characterizes and standardizes communication functions. The layers range from layer 1 right through to layer 7. In the OSI, or Open Systems Interconnection model, SFTPPlus sits in the OSI Layer 7 or on the application layer.

The application layer sits at the top of the OSI model and is the software, hence the name application, layer between the end-user and the networking layers underneath.

Introduction

When you create file transfer systems that interact with services, protocols, databases, users and data, it is important to ensure that the system is being protected and monitored from unauthorized modifications, use, access or destruction.

Ensuring that activities are under proper monitoring and logging is also an important aspect of secure file transfer infrastructures. Should there be access attempts from that particular IP range? Should this file transfer service port be in use at all? Are there subsets of data that are critical enough that an alert mechanism be put in place for failed transfers in that source? The answers to questions like these will help provide the basis for meeting logging and auditing requirements for your infrastructure through our audit and logging mechanisms.

Potential use case for HTTP Authorization

A potential use case for the API is utilizing the HTTP Authorization for SFTPPlus. This is deployed in a DMZ where certificate-based authentication cannot be used, only a username/password authentication with a time limit expiration.

Case study with load balancers and HTTPS push from third party via SFTPPlus API

This case study involves integrating with a third party. In this case, the third party is a web application functioning as the client.

Through the HTTPS service that is available with SFTPPlus, the third party developer works with the SFTPPlus HTTP API to authenticate the users and to allow them to upload content (push) to the SFTP servers.

Subsequently the corporate, or internal network, are authenticating via the SSH key exchange (as one of the possible methods) and pulling content from the servers.

While the topic is covered in another article, the servers are also set up for high availability and resilient environment via a load balancer. In this case, the load balancer is utilizing the weighted round-robin algorithm depending on the server ‘weight’.

Ensuring high availability is also a pathway to secure file transfer operations by making sure that critical data is constantly available. Load balancers can be used with SFTPPlus to set up high availability.

Through a combination of choosing secure file transfer protocols, smart use of the SFTPPlus API and structuring file transfer operations to function in a high availability environment, you can further secure your data and file transfers with your company.

Case study with DMZ and buffer zones

For a case study on how SFTPPlus is integrated with a DMZ, see above for an example of an internal company user transferring files towards external, public-facing servers.

In this case, the FTP/SFTP ‘Inbox’ folder which resides within the DMZ will utilize the SFTPPlus file-dispatcher Event Handler to dispatch files to the ‘Outbox’ folder within the DMZ.

The file-dispatcher event handler has been configured to move files from the SFTPPlus Inbox folder to the SFTPPlus Outbox folder based on a matching expression - either global or regular expression. In this instance, we can say that the matching expression is for all PDF files. All of this happens with the DMZ which acts as a buffer zone between the media PC in an internal network to external servers.

From the SFTPPlus Outbox folder, which serves as a cache of matched files, users can initiate a client transfer to the external public facing servers outsize the DMZ.

Accounting part of the AAA framework

As SFTPPlus operates, it will emit a set of events which contains a unique ID and defines a specific operation carried out by the server. A common action for an event is to send it to one of the supported logging systems. This covers the Accounting requirement of the AAA (Authentication, Authorization, and Accounting) security design framework.

Utilizing an accounting, also seen as auditing, framework is a way to ensure that any compliance or logging obligations and requirements are met.

Authorization part of the AAA framework

The use of authorization is one of the fundamental aspects of network and resource management security. By building an authorization framework, you can ensure that users have correct access to network resources.

In the above diagram, we have two users in the same department or user group but both of these users have different access requirements. After authentication via the authentication server, how does an administrator ensure that the correct authentication framework is applied? One user can only have read-only rights to shared folder and full-control for a common home folder. Whereas another user has full-control-allowed access to both the common folder and all other folders underneath, including a shared folder with the first user.

In the above diagram, the permissions framework can be set up on a global or on a per-path basis, including fine-grain details such as permissions for matching expressions.

Even after a user group is authenticated and the correct users are in their respective accounts, a solid authorization framework will ensure that any additional user access rights policies are applied.

Authentication part of the AAA framework

The server-side security of SFTPPlus is designed based on the Authentication, Authorization and Accounting (AAA) components. Authentication can be integrated with external third parties - Windows Domain Accounts - or with external resources such as via the domain controller, via the SSH RSA/DSA keys or SSL certificates.

When compiling how you will secure your system, it is important to take stock of how you are mediating and managing network access based on meeting authentication, authorization and accounting requirements.