Articles from resource category

Secure File Transfer and Business Continuity Planning

Fri 06 July 2018 | article

Introduction

What is business continuity planning (BCP)?

According to Wikipedia, business continuity planning is the process of creating systems of prevention and recovery to deal with potential threats to a company.

Business Continuity Planning also includes these five components as defined by the SANS Institute. These components are:

  • Business Resumption Plan
  • Occupant Emergency Plan
  • Continuity of Operations Plan
  • Incident Management Plan
  • Disaster Recovery Plan (DRP)

We have decided to provide a high level overview for this article. While secure file transfer is just a component of business continuity planning, it is still an important component of it. We hope that after reading this post, that you also recognize secure file transfers to be part of the Business Continuity Planning process.

Assigning risk ratings

Planning involves conducting a risk assessment of your organization. In this case, planning involves determining what is considered IT risk versus Business risk.

By conducting a risk analysis, you can identify portions of your business resources, identify known risks to these business resources, and assign a risk rating.

According to the Cisco Systems Network Security Policy Best Practices White Paper, the following are rating guidelines based on a three-tier risk level. These are examples from purely a network security level and there are other models and guidelines available that cover a more generalized approach.

The following are excerpts from the above whitepaper:

Low Risk

These are systems or data that if compromised (data viewed by unauthorized personnel, data corrupted, or data lost) would not disrupt the business or cause legal or financial ramifications. The targeted system or data can be easily restored and does not permit further access of other systems.

Medium Risk

These are systems or data that if compromised (data viewed by unauthorized personnel, data corrupted, or data lost) would cause a moderate disruption in the business, minor legal or financial ramifications, or provide further access to other systems. The targeted system or data requires a moderate effort to restore or the restoration process is disruptive to the system.

High Risk

These are systems or data that if compromised (data viewed by unauthorized personnel, data corrupted, or data lost) would cause an extreme disruption in the business, cause major legal or financial ramifications, or threaten the health and safety of a person. The targeted system or data requires significant effort to restore or the restoration process is disruptive to the business or other systems.

From the perspective of secure file transfer, you will need to consider at which level your assets (such as the assets covered in the scope of file transfers) fall under which of these risk categories.

Establishing a business continuity structure / policy

Part of the planning process also involves establishing a business continuity structure.

Having a business continuity policy will require building a team and a governance structure around it. Within the policy, ensure to outline the roles and responsibilities of those that are going to be impacted by this document.

Within the context of secure file transfers, the policy could outline the role of the secure file transfer administrator and to make aware that it is their responsibility to ensure successful Continuity of Operations. In this example, the same administrator could also be the support or testing lead to ensure that the failover file transfer system is tested and verified should there be an issue with the main server.

On that note, for those interested in more details about how SFTPPlus can help administrators meet Continuity of Operations demands, please read our introduction to SFTPPlus and high availability or resiliency environments.

In conclusion, the business continuity policy should ensure that the organization has been provided a general understanding of the policy, purpose, guidelines and definitions around the business continuity plan.

Incident Management and Incident Response

Part of business continuity planning is around incident management and incident response.

What is the relationship between Business Continuity Planning and Incident Management Plan? According to NIST Security Incident Handling guide (the National Institute of Standards and Technology), “organizations should ensure that incident response policies and procedures and business continuity processes are in sync. Computer security incidents undermine the business resilience of an organization. Business continuity planning professionals should be made aware of incidents and their impacts so they can fine-tune business impact assessments, risk assessments, and continuity of operations plans.”

Within the context of secure file transfers, SFTPPlus emits an audit trail for administrators to monitor events and for audit assurance purposes, which can help assist in incident management and response. For further readings about procedures, we recommend the NIST Security Incident Handling guide. Our documentation on the audit trail also provides a useful starting point on how you can administer SFTPPlus to be compliant to your auditing needs.

Implementation

Implementation is the practice stage. The importance of implementation is the prevention of business risk.

The recovery point objective (RPO) and recovery time objective (RTO) are baseline data that administrators should be aware of when implementing the business continuity plan.

For example, a secure file transfer administrator can ask themselves questions such as "What is the recovery time actual (RTA) in contrast to the recovery time objective (RTO) for the file transfer application during an actual disaster or exercise?"

The Business Impact Analysis should uncover which systems are mission critical and non-critical, which can further impact the RPO and RTO, as an example. In this example, you may need to ensure an active-active high availability setup is in place with the backup server in the cloud rather than on-premise. In this scenario, you may be targeting 100% Recovery Consistency Objective (RCO) for a business process.

Exercise / Testing / Action

Part of business continuity plan should include a review process to modify the existing policy. This process should be able to adapt to lessons learned - either from an actual disaster event or from an exercise.

The review process ensures that the policy, posture and practices are being re-evaluated accordingly.

The Business Continuity Plan should end up being a dynamic document that can adapt to the constantly changing business and IT environment and needs. This dynamic should also include education and evaluation of staff skills involved.

ISO guidelines for further reading

Continual improvement with your business continuity plan are also covered by guidelines such as ISO 22301 "Societal security -- Business continuity management systems --- Requirements". This guide “specifies requirements to plan, establish, implement, operate, monitor, review, maintain and continually improve a documented management system to protect against, reduce the likelihood of occurrence, prepare for, respond to, and recover from disruptive incidents when they arise.”

And for those focusing on the information security management system, the ISO/IEC 27001:2013 standard “specifies the requirements for establishing, implementing, maintaining and continually improving an information security management system within the context of the organization. It also includes requirements for the assessment and treatment of information security risks tailored to the needs of the organization.”

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, Solaris, AIX, HP-UX, MacOS and FreeBSD or on the cloud as Docker containers, AWS instances etc.

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.34.1.

The details in this resource is for guidance only. Influences such as own security policies, requirements, and threat models should be considered when adopting this type of guidance.

• • •

IPv6 support for HTTP/S, FTP/S, SFTP and SCP File Transfer Services

Mon 04 June 2018 | article infrastructure

Why get ready for IPv6?

According to the Akamai Q1 2017 State of the Internet Connectivity Report, "approximately 5 million IPv4 addresses were depleted from available pools at the Regional Internet Registries in the first quarter, leaving approximately 39 million addresses remaining."

In response to the steady depletion of IPv4 addresses, we see greater adoption of many large mobile and broadband networks actively rolling out IPv6 connectivity. According to World IPv6 Launch, among the top 10 participating networks with more than half IPv6 deployment rates include Comcast, ATT, Verizon Wireless and Deutsche Telekom AG.

Now is a good time to brush up on your knowledge of deploying IPv6 in your organization. For those with a lack of knowledge or training in IPv6 implementation, there is an even greater urgency when addressing the potential security impact of the rollout in the organization. Such scenarios are amplified when administrators do not have the required level if minimal expertise in IPv6 to ensure there is protection against threats. If you are in the front-line of IPv6 deployment and file transfers in your own organization, you will find this post of useful interest.

A brief introduction to IPv6

IPv6 was first introduced by IETF in 1998, via RFC 2460, which has since been updated via RFC 8200 published in July 2017. This is the new version of the Internet Protocol and a successor to IPv4.

The main updates are as follows:

Expanded addressing capabilities

This involves increasing the IP address size from 32 bits to 128 bits. This allows greater support in addressing hierarchy, more addressable notes, scalability of multicasting, and addition of anycast address.

Simplified header formats

This involved dropping or making optional some of the IPv4 header fields.

Improved support for extensions and options

The way IP header options are encoded allows for more efficient forwarding and greater flexibility for new options.

Flow labeling capability

This allows sender requests to be treated in the network as a single flow.

Authentication and privacy capabilities

Extensions are added in order to support authentication, data integrity, data confidentiality.

While it has been some length of time since the first introduction, each day brings forward the pressing need to implement IPv6 as IPv4 addresses become exhausted. Greater adoption for IPv6 by vendors, including increase in knowledge and support, means that deployment is now more feasible for administrators than ever before.

IPv6 and SFTPPlus

Enabling IPv6 on SFTPPlus for HTTP/S, FTP/S, SFTP and SCP

SFTPPlus supports configuring IPv6 addresses for the HTTP, HTTPS, FTPS, FTP, SFTP and SCP file transfer services.

We have written a starter guide with details on how you can enable IPv6 with SFTPPlus. Please to go to the documentation section on IPv6 support.

When configuring a new service on SFTPPlus, an IPv6 address can be used. To accept connections on all available IPv6 interfaces, simply use the :: address like the simplified test configuration below:

[services/ftps]
enabled: Yes
name: FTPS Service on an IPv6 address.
address: ::1
port: 10021

Please consult the configuration documentation for more details about each type of file transfer service.

Enabling IPv6 on SFTPPlus Local Manager

Similar to enabling IPv6 on file transfer services, you can set the SFTPPlus Local Manager to listen in on an IPv6 address via the same address field as the services.

Administrators can add this via the SFTPPlus Local Manager Services section:

FTPS service including IPv6 address option.

Enabling authentication methods with IPv6

We support IPv6 address when authentication file transfer accounts via the ldap authentication method and via the HTTP API authentication method.

IPv6 implementation and security considerations

The following are some considerations in implementing IPv6 securely.

Conduct an inventory audit

Tag which file transfer scenarios (server, client, protocol) require IPv6 implementation and support.

Communicate with your vendors

Notify your vendors as to what level of support is provided for IPv6. If not supported, inquire if there will be plans on the product roadmap for the support.

We have added IPv6 support for file transfer services, as of SFTPPlus version 3.33.0, in response to customer needs to roll out such support.

Conduct a security-focused audit on IPv6 deployment

Both IPv4 and IPv6 share similar properties when it comes to security. In this case, take an audit of which of these properties can be carried over within an IPv6 deployment.

Last but not least - do not overlook security risks and requirements for IPv6

Network administrators overlooking the effects of IPv6 in their network will face security risks. IPv6 packets is susceptible to attacks like MITM (Man-in-the-Middle) attacks. Bad actors may also attempt to eavesdrop by making use of upper-layer protocols such as TLS (Transport Layer Security) or SSH (Secure Shell). Another potential security threat is bypassing IPv4-only firewalls and ACLs using functional IPv6 tunneling protocols as described in the Carnegie Mellon University CERT/CC blog post here.

IPv6 troubleshooting

The following are introductory advice for those troubleshooting IPv6 within a file transfer scenario.

  • Ensure that the protocols to be used are fully tested with SFTPPlus.
  • Ensure that FTP proxies, firewalls and other layer 7 technologies properly support IPv6.
  • Ensure that any other boundary facing technologies are implementing IPv6 correctly.

It is also good to keep note of future changes to the protocol. For example, design changes to the new IPv6 extension header could mean security implications based on how the new changes work with existing extension headers.

Those evaluating SFTPPlus and customers with a valid support contract can leverage help from the SFTPPlus Support team for queries in regards to SFTPPlus and IPv6 deployment.

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, Solaris, AIX, HP-UX, MacOS and FreeBSD or on the cloud as Docker containers, AWS instances etc.

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.34.0.

The details in this resource is for guidance only. Influences such as own security policies, requirements, and threat models should be considered when adopting this type of guidance.

• • •

Understanding the exchange between SFTP Client and SFTP Server

Thu 08 March 2018 | article

Why read this?

As part of meeting the Accounting component of the AAA (Authorization, Authentication and Accounting) framework, each event and action on the server and/or the client-side are recorded by SFTPPlus. These events have an associated Event ID which is also publicly searchable both on our website and on the internal documentation included in the software package that you have downloaded.

System and network administrators touching on logs - be it in the most verbose format or not - may find this article describing the breakdown of such logs helpful.

For this example, we will be touching on SFTPPlus SFTP transfers from both the client-side and server-side only. Please do not hesitate to get in touch with us if you are interested in learning more about other file transfer protocols.

SFTPPlus SFTP Server-side Perspective

Initial configuration notes

If you are currently evaluating SFTPPlus, please follow our documentation to learn more about how you can configure your database and event handlers to suit your specifications.

Read more about configuring databases with SFTPPlus.

Read more about configuring event handlers. These provide further ways to configure SFTPPlus to create logging actions based on the events recorded.

Even if you are an existing customer, you can follow our documentation links above in order to refresh your knowledge on configuring SFTPPlus version 3. For those on legacy versions, please consult the documentation relevant to your version.

Example logs from SFTPPlus

The following are snippets when logging in for the first time from a GUI client to an SFTPPlus 3.30.0 SFTP server.

A new connection has been made to the service sftp-1. Knowing the service name is useful in case there are multiple other SFTP services running:

| 30014 2018-02-27 17:28:53 sftp-1 Unknown 127.0.0.1:58032
  New SSH connection made.
| 2018-02-27 17:28:53 30014 New SSH connection made.

The following are authentication methods associated with the server and confirmation of which methods are not active. There may be more methods, depending on how many of these are set up and enabled. To simplify the login process, please make sure to disable all unused authentication methods.:

| 20138 2018-02-27 17:28:55 some-http-auth-uuid Unknown 127.0.0.1:58032
  Ignoring http authentication "auth-over-remote-http" for "user" since it
  is not active.
| 2018-02-27 17:28:55 20138 Ignoring http authentication "auth-over-remote-http"
  for "user" since it is not active.
| 20138 2018-02-27 17:28:55 ldap-uuid Unknown 127.0.0.1:58032 Ignoring
  ldap authentication "LDAP against local test server" for "user" since it
  is not active.

The following logs list out a successful authentication of user using the ssh-key:

| 20137 2018-02-27 17:28:55 test-server-uuid Unknown 127.0.0.1:58032
  Account "user" of type "application" authenticated as "user" by
  application authentication "Application Accounts" using ssh-key.
| 2018-02-27 17:28:55 20137 Account "user" of type "application"
  authenticated as "user" by application authentication "Application
  Accounts" using ssh-key.

The following log message confirms the type of permissions allowed for the account and an active transfer that is already running:

| 20182 2018-02-27 17:28:55 Process user 127.0.0.1:58032 Account "user"
  logged in with permissions [[u'allow-full-control'], [u'/main_folder/*', u'allow-full-control'],
  [u'*.PDF', u'allow-read']]. Files uploaded as: test.txt

The following confirms that the user has logged into and now has access to the folder as the root ("/") folder:

| 30011 2018-02-27 17:28:55 Process user 127.0.0.1:58032 Subsystem SFTP
  successfully started in "/root/home/node/user/" as "/".
| 2018-02-27 17:28:55 30011 Subsystem SFTP successfully started in
  "/root/home/node/user/" as "/".
| 30060 2018-02-27 17:28:55 Process user 127.0.0.1:58032 Canonical file
  name requested for ".".
| 2018-02-27 17:28:55 30060 Canonical file name requested for ".".
| 30060 2018-02-27 17:28:55 Process user 127.0.0.1:58032 Canonical file
  name requested for "/.".
| 2018-02-27 17:28:55 30060 Canonical file name requested for "/.".
| 30019 2018-02-27 17:28:55 Process user 127.0.0.1:58032 Listing folder "/".
| 2018-02-27 17:28:55 30019 Listing folder "/".
| 30020 2018-02-27 17:28:55 Process user 127.0.0.1:58032 Successfully
  listed folder "/".
| 2018-02-27 17:28:55 30020 Successfully listed folder "/".

SFTPPlus SFTP Client-side Perspective

Initial configuration notes

If you are currently evaluating SFTPPlus, please follow our client side documentation.

The SFTPPlus Client software utilizes the command-line client-shell to access remote file servers using the interactive shell.

Even if you are an existing customer, you can follow our documentation links above in order to refresh your knowledge on configuring SFTPPlus version 3. For those on legacy versions, please consult the documentation relevant to your version.

Example logs from SFTPPlus

Let's connect with SFTPPlus Client using the SFTP protocol on port 10022. The following log details the UUID of the sftp service and confirms the connections:

| $ ./bin/client-shell.sh sftp://user@localhost:10022 -p pass
  --ssh-server-fingerprint 06:cb:46:2b:9a:9a:c4:10:54:f0:ea:2f:b6:05:cb:a0
| SFTPPlus (3.31.0) file transfer client shell
| > connect
| 20140 2018-03-05 16:40:59 51e1db00-8214-4b68-96fe-58470b8b2fc5 Process
  0.0.0.0:0 Connecting resource "sftp".
| 30072 2018-03-05 16:40:59 Process user localhost:10022 Location sftp
  connected to the SSH server.
| 30076 2018-03-05 16:40:59 Process user localhost:10022 Client SFTP
  subsystem initialized for location sftp.
| 20141 2018-03-05 16:40:59 51e1db00-8214-4b68-96fe-58470b8b2fc5 Process
  0.0.0.0:0 Resource "sftp" successfully connected.
| 20156 2018-03-05 16:40:59 51e1db00-8214-4b68-96fe-58470b8b2fc5 Process
  0.0.0.0:0 Successfully started location "sftp" of type sftp.

On the event that the SFTP connections fails, the log will state a number of details. The event ID is 30073. The event will communicat the host key algorithm that is in use to identify the server-side, the cipher used to receive data, the HMAC for both sent and received data, key exchange algorithm, cipher used for sent data and the name of the location associated for this event. Below is an example of the event that has been emitted has part of this new SFTP connection.:

| 30073 2018-03-05 16:36:16 Process user localhost:10022 Connection to
  SSH server was lost for location sftp. Protected using host-key:ssh-rsa key-exchange:
  diffie-hellman-group-exchange-sha256 in-hmac:hmac-sha2-256
  in-cipher:aes256-ctr out-hmac:hmac-sha2-256 out-cipher:aes256-ctr

Providing that the SFTP connection succeeds, supported actions are logged as either a success like below:

| > gattrs remote_get
| 60071 2018-03-05 16:41:22 Process Process 0.0.0.0:0 Successfully got
  attributes for "Reports_2018" on "sftp".
| name: Reports_2018
| path: Reports_2018
| size: 128
| modified: 2018-02-16 16:15:21
| is_file: False
| is_folder: True

Or error details are caught with an explanation message as to why:

| > get unknown_file
| 20145 2018-03-05 16:42:08 Process Process 0.0.0.0:0 Failed to resolve
  text for event id "60054" with data "{'path': 'unknown_file\xc8\x9bu',
  'location': u'sftp', 'avatar':
  <chevah.server.identity.avatar.ProcessAvatar object at 0x10efc3110>,
  'details': "'ascii' codec can't decode byte 0xc8 in position 9: ordinal
  not in range(128)"}". 'ascii' codec can't decode byte 0xc8 in position
  9: ordinal not in range(128)

SFTPPlus SFTP Exchange - Detailed Verbose OpenSSH Logs

Initial configuration notes

Following from that, you can use the built-in the client-side or server-side software that you are utilizing. SFTPPlus offers logging functionalities both for the client-side and server-side. Network administrators using other software, such as sftp -vvv, for client or server may wish to use additional logging functionalities.

Example with sftp -vvv output

These lines mean that SSH protocol 2.0 is being utilized with the version of OpenSSH:

debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.6

This line indicates which protocol version is in use service-side and which version:

debug1: Remote protocol version 2.0, remote software version SFTPPlus_3.30.0

This indicates which algorithms are preferred. You may opt to only select the strongest availability supported in your system first. In this case the ordering is logical as it moves from the more secure algorithm down to a less secure algorithm.:

| debug3: order_hostkeyalgs: prefer hostkeyalgs:
  ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa

These are the key exchange algorithms that are available.:

| debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,
  ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,
  diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,
  diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,
  diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c

These are the host key algorithms.:

| debug2: host key algorithms: ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,
  rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,
  ecdsa-sha2-nistp384-cert-v01@openssh.com,
  ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,
  ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519

These are the ciphers used from client to server (ctos) and from server to client (stoc):

| debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,
  aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

| debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,
  aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

These are the ciphers used from client to server (ctos) and from server to client (stoc):

| debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,
  hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,
  hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,
  hmac-sha2-256,hmac-sha2-512,hmac-sha1

| debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,
  hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,
  hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,
  hmac-sha2-256,hmac-sha2-512,hmac-sha1

These are the compression algorithms used from client to server (ctos) and from server to client (stoc):

debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib

This is the key exchange initialized proposal from the host server:

| debug2: peer server KEXINIT proposal
| debug2: KEX algorithms: diffie-hellman-group-exchange-sha256,
  diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1,
  diffie-hellman-group14-sha1
| debug2: host key algorithms: ssh-dss,ssh-rsa
| debug2: ciphers ctos:
  aes256-ctr,aes256-cbc,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,
  3des-ctr,3des-cbc
| debug2: ciphers stoc:
  aes256-ctr,aes256-cbc,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,
  3des-ctr,3des-cbc
| debug2: MACs ctos: hmac-sha2-256,hmac-sha1
| debug2: MACs stoc: hmac-sha2-256,hmac-sha1
| debug2: compression ctos: none,zlib
| debug2: compression stoc: none,zlib

These are the key exchange algorithms used from server to client and client to server:

| debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
| debug1: kex: host key algorithm: ssh-rsa
| debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256
  compression: none
| debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256
  compression: none

This is the SSH version 2 key exchange Diffie-Hellman Group Exchange request. This specifies the size of the SSH prime moduli being calculated by the SFTP server as indicated in the SFTPPlus /configuration/ file. When you first initialize SFTPPlus version 3, the Time Type Tests Tries Size Generator Modulus is generated and saved in ssh-service.moduli. This file contains primes ranging in size from 1023 to 8191 bits. An example of the contents for the .moduli file is below:

| 20060827134212 2 6 100 3071 2
  D3230D237572ECE9F92358715EBAC3A4D89F2D6B4DC39F056450263BEF1665FBD
  7B93916ABC867B7064802159D273C7EB01C5F9281A3D6DCCB7CF997D385998EC0E1FA3319AFE771A90ADBACEB414A02
  0630D7C7F161FAFEC6C9FC06D3205C712AAE8848A1B2C21DFF301C7FFC0B75D13F060A313C32AFEEAF1493F641760EB
  EF38829B3371699D2A3264D0ECEB4E5C19581ED8C57699F559B9828BBFE147952E289F0E171C9C60335DD2F492CB409
  A4DB97BDF86E2DBA605064DB040A3DF5678E24F66718CA115C95C892FF7AEDFAABC2E6414716298CEC1A604270FEADF
  191B7C8A59C238C395A65442C0B963BF83025BED3951A271B7440EC7687C31DE63355DA7FEAC15DC962C7BF7614EB59
  B077B9889AD8703DFE98AC99615B722A0ABE89956D1058E025C7733420CB51D7E1608EFF2C0A30C9A5EB77CCA02C6B0
  0CE781B172001C6C458630890062E27CE307D513A7686A69D1D548DE8334B13136D9E842A5E17FD67522C93823E03F0
  8AEE8024AF5D88B2EE01D4D9980084EFD5D943

In the following example below, a SSH moduli prime from 2048 to 8192 bits are used. Specifically, a moduli with a range from 4092 to 8192 are sent for the SSH message key exchange Diffie-Hellman group exchange request as indicated on debug1 line below (SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192)) Once sent, the server uses the moduli file, the same file that was initialized as part of the SFTPPlus installation steps, in order to crack the shared secret. The server provides its host key back to the client along with the algorithm used as indicated by the final line as Server host key: ssh-rsa SHA256:hdSfa7gb2O984malHerkwerj3m20dHb6Yuwl0&hbxFj.

See the rest of the output below:

| debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent
| debug3: receive packet: type 31
| debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
| debug2: bits set: 4092/8192
| debug3: send packet: type 32
| debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
| debug3: receive packet: type 33
| debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
| debug1: Server host key: ssh-rsa
  SHA256:hfSfa0gb2O884malLerkwerj3m20dBb6Yuwl0&hbxGj

The client then checks to see if the host key is located within the known_hosts file:

| debug3: hostkeys_foreach: reading file "/root/home/node/.ssh/known_hosts"
| debug3: record_hostkey: found key type RSA in file
  /root/home/node/.ssh/known_hosts:8
| debug3: load_hostkeys: loaded 1 keys from [12.345.678.90]:10022

A few more steps occur to verify this server host name and port:

ddebug1: Host '12.345.678.90]:10022' is known and matches the RSA host key.
ddebug1: Found key in /root/home/node/.ssh/known_hosts:8

This is the server rekey interval:

debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks

The following are SSH keys found:

debug2: key: imported-openssh-key (0x7e403ff95550), agent
debug2: key: /root/home/node/.ssh/id_rsa (0x0)
debug2: key: /root/home/node/.ssh/id_dsa (0x0)
debug2: key: /root/home/node/.ssh/id_ecdsa (0x0)
debug2: key: /root/home/node/.ssh/id_ed25519 (0x0)

The following are authentication methods that can continue, the preferred authentication order, remaining preferred:

| debug3: send packet: type 5
| debug3: receive packet: type 6
| debug2: service_accept: ssh-userauth
| debug1: SSH2_MSG_SERVICE_ACCEPT received
| debug3: send packet: type 50
| debug3: receive packet: type 51
| debug1: Authentications that can continue: password,publickey
| debug3: start over, passed a different list password,publickey
| debug3: preferred publickey,keyboard-interactive,password
| debug3: authmethod_lookup publickey
| debug3: remaining preferred: keyboard-interactive,password
| debug3: authmethod_is_enabled publickey
| debug1: Next authentication method: publickey
| debug1: Offering public key: RSA
  SHA256:F8zPRFytcYU8PERggkPDs+D32TRgvVm4H3BBJduo+de
  /root/home/node/.ssh/id_rsa
| debug3: send_pubkey_test
| debug3: send packet: type 50
| debug2: we sent a publickey packet, wait for reply

The server will go through the exchange to authenticate until the final preferred method is reached - the password method. Upon success, the client enters an interactive session with the server.

There will also be additional verbose logs after entering an interactive session, such as a brief snippet below:

debug2: fd 6 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x08
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug3: Ignored env _system_type
debug1: Sending env LANG = en_CA.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env _system_arch
debug3: Ignored env XPC_FLAGS
debug3: Ignored env _system_version
debug3: Ignored env XPC_SERVICE_NAME
debug3: Ignored env rvm_version
debug3: Ignored env _system_name
debug1: Sending subsystem: sftp

Evaluating SFTPPlus MFT

This article was written as of SFTPPlus version 3.31.0.

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 or fill in the form below to start your evaluation version today.

• • •

SFTPPlus is not affected by the Meltdown and Spectre Vulnerabilities

Wed 21 February 2018 | article security

Security advisory about the Meltdown and Spectre are vulnerabilities

SFTPPlus is not affected by the Meltdown and Spectre Vulnerabilities

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.

This article was written as of SFTPPlus version 3.31.0.

• • •

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.

• • •