Articles from resource category

SFTPPlus is not affected by the Meltdown and Spectre Vulnerabilities

Wed 21 February 2018 | article security

Meltdown and Spectre are vulnerabilities based on CPU design flaws which require the attacker to be able to execute application code which is created to exploit these vulnerabilities.

SFTPPlus secure file transfers does not allow any arbitrary application code execution. It will only read and write data without executing it. This is standard behaviour for doing file transfers over FTPS or HTTPS.

The SSH implementation of SFTPPlus is only allowed for the SFTP and SCP protocols. Shell access or any other SSH execution is denied. The SCP protocol is implemented using an embedded SCP protocol and no external scp application is called.

For the purpose of managed file transfers, SFTPPlus allows the execution of pre-configured application code with the pre and post transfer hooks. As long as the SFTPPlus is configured with trusted applications, this does not constitute an attack vector.

If you are running SFTPPlus Itanium architectures, for example with HPUX, you are not affected by these vulnerabilities, no mater what other software is in used on those systems.

SPARC architecture (example with Solaris 10) and POWER (example with AIX 7.1) are affected by the Spectre, while not being affected by Meltdown.

The embedded devices based on ARM64 CPUs are also affected by Spectre.

Administrators using the SFTPPlus MFT Client with pre and post transfer hooks should review the configuration and make sure that the hooks will trigger calls to trusted applications.

• • •

Introducing SFTPPlus to high availability and resiliency

Tue 23 January 2018 | article infrastructure

Where does SFTPPlus sit in your IT infrastructure

The SFTPPlus software stands at the OSI Layer 7 or the TCP Layer 4. In order to have a fully fault tolerant system, you need to implement resilience at all the other layers including the OS. SFTPPlus can be integrated with external tools in order to meet the requirements for a fault tolerant infrastructure.

For those not familiar with OSI and TCP please read on.

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.

SFTPPlus on the TCP

In addition to the OSI model, another way of understanding where SFTPPlus plays a role in your infrastructure is via the TCP layer. SFTPPlus sits in the TCP Layer 4 or the application layer. This is the topmost layer which defines the TCP/IP application protocols and how SFTPPlus interfaces with the Transport layer, the layer below the application layer, and other services that use the network.

Installing SFTPPlus in high availability and resilient environments

The following are introductory information for this topic.

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.

About resilience

The following can be deduced as a definition of a resilient control system:

"A resilient control system is one that maintains state awareness and an accepted level of operational normalcy in response to disturbances, including threats of an unexpected and malicious nature"

High availability and resilience tend to be used interchangeably. However, having a highly available system does not necessarily mean that all required functions are still in use and available. This is where having a resilient system come into action. Even if a system has high availability, can it still function to a required level of standard, operational normalcy? You will still wish to utilize a system with the same users, storage and database as found in the usual system.

About fault tolerance

On the event of failure, the system remains available in order to maintain the high uptime. There may be a performance break or slow down but the services are still available.

You may add additional devices or protocols for a fault tolerant system - RAID set up, multiple network paths for fault tolerance (on the event of a failed network path) and load balancers are such examples.

About clustering

Clustering involves creating a cluster of two or more nodes or members that work together in order to perform an action. They can be grouped in the following major types; storage, high availability, load balancing and high performance clusters.

The main clusters that relates to SFTPPlus in a given system are high availability and load balancing types of clusters.

High availability clusters involve the provision of highly available services by ensuring that any single points of failure are eliminated. This is done by failing over services from one cluster node to another should that node be no longer in operation. This ensures the ability to maintain data integrity.

Load balancing clusters sends off network requests to a number of cluster nodes in order to balance the request load among the cluster nodes. This ensures scalability of a network since administrators can match the number of nodes according to load requirements through load balancing algorithms.

How can SFTPPlus be integrated in these environments

Diagram example: Integration for load balancing

Integration for load balancing

Diagram example: Integration for high availability

Integration for high availability

Active-Active and Active-Passive Scenarios

Active-active and Active-passive are two types of cluster configurations in a high availability scenario.

The details between these two scenarios are laid out below from Sybase.

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.

Active-Active configurations

Setup: Two Adaptive Servers are configured as companion servers, each with independent workloads. These companions run on the primary and secondary nodes, respectively, as individual servers until one fails over.

Failover: When fail over occurs, the secondary companion takes over the devices, client connections, and so on from the primary companion. The secondary companion services the failed-over clients, as well as any new clients, until the primary companion fails back and resumes its activities.

Failback: Failback is a planned event during which the primary companion takes back its devices and client connections from the secondary companion to resume its services.

Client Connection failover: During failover, clients connect to the secondary companion to resubmit their uncommitted transactions. During failback, clients connect to the primary companion to resubmit their transactions. Clients with the failover property reestablish their connections automatically.

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.

Installing SFTPPlus for disaster recovery

Disaster recovery is part of business continuity plans (or business continuity and resiliency plans) which is the process of creating systems of prevention and recovery to deal with potential threats to a company. The use of the term “recovery” has also been used when talking about resiliency.

Providing that the server configuration and related configuration files are properly maintained and backed-up, you can integrate SFTPPlus as part of your disaster recovery plans.

Conclusion and next steps

The application of these does not immediately guarantee results in achieving high availability or resiliency. Please consider these guides merely as a layer within multiple others when implementing a high available, resilient and 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.

Evaluating SFTPPlus MFT

SFTPPlus MFT Server supports FTP, Explicit FTPS, Implicit FTPS, SFTP, SCP, HTTP and HTTPS.

Install SFTPPlus MFT today either as an on-premise solution supported on Windows, Linux, AIX, OS X, Solaris, FreeBSD, HP-UX or on the cloud as Docker containers or AWS instances.

Email us at sales@proatria.com to start your evaluation version today.

For licensing queries please contact sales@proatria.com.

Addendum

This resource is written as of SFTPPlus version 3.29.0.

• • •

Choosing the best protocols for securing data and file transfers

Mon 22 January 2018 | article security

Why read this guide

In order to implement a secure managed file transfer system, you will need a good understanding of the supported services and protocols involved.

This article provides an overview of the supported protocols, including the advantages and disadvantages of these protocols as well as situations for the use of these services.

The first part focuses on protocols that we recommend you reconsider in using and the rest of the article is followed by services that we do recommend.

Protocols to reconsider when securing data and file transfers

The following, FTP and HTTP, are covered below as they both pose two services that offer the least advantage in terms of securing data and file transfers.

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.

Situations to use the FTP service:

There is a chance that your initial file transfer system may even be in FTP, depending on the age of the system. However, FTP has many security weaknesses and vulnerabilities as mentioned previously.

Those wishing to continue to use FTP and to do so in a secure manner may find themselves integrating other software to ensure security, creating additional scripts or taking on board additional maintenance. For example, there is no built-in integrity check however scripting work can be done to create a checksum integrity checking process and added at the end of a file transfer. There is also further additional overhead in ensuring that FTP remains secure such as integration with other applications for additional layers of security.

The FTP service is accessible by enabling the service and then configuring the address, port, passive port range, passive address, idle data connection timeout and more.

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.

Situations to use the HTTP service:

HTTP may be used internally within a highly secured network where there are already mechanisms in place to protect the environment.

We offer HTTP based micro-services and endpoints as part of our public API. In this case, the API is used in conjunction with other security mechanisms in place for the environment.

The HTTP service is accessible by enabling the service and then configuring the address, port, idle connection timeout and maximum concurrent connections.

Protocols to consider when securing data and file transfers

The following are protocols and services that we do recommend for securing data and file transfers. This is not an exhaustive list.

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.

Implicit FTPS or FTPS Implicit SSL (FTPIS)

Situations to use the FTPIS service:

Use FTPIS when you wish to use a more secure FTP for file transfer and where SSL does not need to be invoked prior to login. However, if possible, use FTPES as described further below.

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.

Explicit FTPS or FTPS Explicit SSL (FTPES)

Situations to use the FTPES service:

Use FTPES when you wish to use a more secure FTP for file transfer and where SSL needs to be invoked prior to login. However it should be noted that this not ensure that each and every session and data transfer is secure. FTPES is only a tool allowing the client/server to negotiate the accepted level of security with each session.

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.

Situations to use the SFTP service:

The protocol assumes that both ends of the connection have been authenticated and that the connection has privacy and integrity features already in place and that security issues are left to the underlying transport protocol.

Since the protocol provides file system management feature, the server must have the correct access controls in place and implement correct authorization and enforce access controls.

In this case, when you implement SFTP ensure that you are doing so within an AAA (authorization, authentication, auditing/accounting) security design framework on SFTPPlus.

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

Situations to use the HTTPS service:

Since the SFTPPlus file management utility is accessible via the web browser, the HTTPS service is a more secure alternative compared to HTTP.

HTTPS is a must especially when the resource is going to be public (Internet) facing.

The HTTPS service is accessible by enabling the service and then configuring the SSL/TLS options such as the SSL cipher list, allowed SSL/TLS methods, SSL certificate, SSL key, certificate authority, certification revocation list and more.

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.

Evaluating SFTPPlus MFT

SFTPPlus MFT Server supports FTP, Explicit FTPS, Implicit FTPS, SFTP, SCP, HTTP and HTTPS.

Install SFTPPlus MFT today either as an on-premise solution supported on Windows, Linux, AIX, OS X, Solaris, FreeBSD, HP-UX or on the cloud as Docker containers or AWS instances.

Email us at sales@proatria.com to start your evaluation version today.

For licensing queries, please contact sales@proatria.com.

Addendum

This resource is written as of SFTPPlus version 3.29.0.

• • •

Securing data and file transfers between SFTPPlus and third parties

Sun 21 January 2018 | article security

Why read this article

In order to have a fully established file transfer and sharing system, you need to implement integration at all the other layers including the OS. SFTPPlus can be integrated with external tools and third parties in order to help establish these integration requirements.

This article is written for those new to SFTPPlus and those involved in the business function of securing file transfer software. Topics are covered for various levels of knowledge to reach a wider audience.

Where does SFTPPlus sit in your IT infrastructure

The SFTPPlus software stands at the OSI Layer 7 or the TCP Layer 4. SFTPPlus can be integrated with external tools in order to secure data and file transfer with third parties.

For those not familiar with OSI and TCP please read on.

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.

SFTPPlus on the TCP

In addition to the OSI model, another way of understand where SFTPPlus plays a role in your infrastructure is via the TCP layer. SFTPPlus sits in the TCP Layer 4 or the application layer. This is the topmost layer which defines the TCP/IP application protocols and how SFTPPlus interfaces with the Transport layer, the layer below the application layer, services to use the network.

While the above information only provides a brief introduction, this should help you understand how SFTPPlus integrates with the networking components (the file transfer protocols) as well as the components on the application level (other systems).

Introduction to file transfer protocols supported by SFTPPlus

For those making the leap to a managed file transfer service for the first time, they may also be thinking about networking components such as which file transfer protocols to support. If your company is currently using FTP, then you may want to switch to FTPES or FTPIS for better security. Or perhaps SFTP for features such as the security of key exchanges.

File transfers are secured via the support of file transfer protocols such as SFTP, FTPS, FTPS, and HTPS. For those that are not familiar, please read the overview of the supported protocols from our Quick Start section in our documentation.

Logging and monitoring network operations with SFTPPlus

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.

Databases

SFTPPlus can be integrated with external database and logging tools such as SQLite, MySQL, Syslog, Windows Event Log.

These integrations will help in any logging, reporting and auditing obligations as is the case for organizations seeking to meet compliance with bodies such as GDPR, HIPAA, GPG13 and more.

SFTPPlus will keep a detailed log of any file which is transferred and can include details about the initial transfer request and the status of the request finalization, logs status changes to device and configurations, login attempts, connection attempts to and from the server or client, session activities and more.

Email resources for email alerts

Users can set up vital email alerts to monitor for any specific server events.

By creating a new email resource, SFTPPlus formulates outgoing emails as though they were coming from an email client.

Access to an SMTP server is necessary. You may use any email service available on your network (public or private). You may use anonymous SMTP, or a preexisting account on that server/service. A local or private SMTP server may also be used.

Once the email resource and Event Handler are configured, the body of any email sent will consist of a JSON object for the event that triggered the email. The recipient(s) and subject line of the email are configurable items.

Integrating SFTPPlus with third parties via the API

SFTPPlus provides public APIs which extend the identity management, file access, audit functionality and more of the SFTPPlus MFT Server using HTTP based micro-services / endpoints. The HTTP APIs can be used to integrate file transfer processes with disparate systems, such as web applications, that need to interface with SFTPPlus.

While it is targeted to HTTP, the HTTP API is used by integrator only as a layer of operations underneath secured networks such as having the services only available under corporate VPNs or proxies.

For more details about the API, please consult our developer section in the documentation.

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

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.

Integrating SFTPPlus with DMZ and buffer zones

A DMZ (or demilitarized zone) is implemented in order to separate servers and other resources from the external or public-facing facing Internet and their internal, trusted networks will run through a number of different configuration options. The standard example used is two firewalls, one firewall for the external or public facing resources and the other for the internal resources, serving a subnetwork.

Case study with DMZ and buffer zones

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.

Implementing AAA (Authentication, Authorization and Accounting) frameworks

SFTPPlus allows for an AAA system to be implemented. AAA refers to Authentication, Authorization and Accounting. It is a system to mediate and manage network access based on the process of identifying a user (authentication), granting or denying access to the user (authorization) and keeping track of the user’s activities on the network resource (accounting).

Accounting part of the AAA framework

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

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.

The permissions framework can be set up on a global or on a per-path basis

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.

Integrating SFTPPlus with post-processing actions

Integrating SFTPPlus with post-processing actions

SFTPPlus can function suitably when anti-virus applications are installed to protect the environment on the machine. This integration is done as part of the transfer configuration for post-processing actions.

Most anti-virus applications have a real-time protection component that will scan files on creation, when accessed, and on execution. These operations will not affect the overall performance of the system.

Case Study - Virtual machines

Case Study - Virtual machines

To further secure data and file transfers, users can create two installations running in active / passive mode behind a load balancer. These two instances will share the same users, database and storage.

Running in AWS, a new instance is created when one dies to maintain high availability.

SFTPPlus can be integrated with a third party virtual private cloud, as well as load balancers to ensure high availability and resiliency.

Conclusion and next steps

The application of these does not immediately guarantee security. Please consider these guides 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.

Evaluating SFTPPlus MFT

SFTPPlus MFT Server supports FTP, Explicit FTPS, Implicit FTPS, SFTP, SCP, HTTP and HTTPS.

Install SFTPPlus MFT today either as an on-premise solution supported on Windows, Linux, AIX, OS X, Solaris, HP-UX, FreeBSD or on the cloud as Docker containers or AWS instances.

Email us at sales@proatria.com to start your evaluation version today.

For licensing queries, please contact sales@proatria.com.

Addendum

This resource is written as of SFTPPlus version 3.29.0.

• • •