Aspera Ecosystem Security Best Practices

Edit online

Your Aspera applications can be configured to maximize system and content security. The following sections describe the recommended settings and practices that best protect your content when using IBM Aspera High-Speed Transfer Server and IBM aspera High-Speed Transfer Endpoint.

Contents

Securing the Systems that Run Aspera Software

Securing the Aspera Application

Securing Content in your Workflow

Securing the Systems that Run Aspera Software

Edit online

The systems that run Aspera software can be secured by keeping them up to date, by applying security fixes, and by configuring them using the recommended settings.

Updates

Aspera continually improves the built-in security of its products, as do the producers of third-party components used by Aspera, such as Nginx, and OpenSSH. One of the first lines of defense is keeping your products up to date to ensure that you are using versions with the latest security upgrades:

  • Keep your operating system up to date.
  • Keep your Aspera products up to date.
  • If using, keep OpenSSH up to date. The server security instructions require that OpenSSH 4.4 or newer (Aspera recommends 5.2 or newer) is installed on your system in order to use the Match directive. Match allows you to selectively override certain configuration options when specific criteria (based on user, group, hostname, or address) are met.

Security Fixes

Rarely, security vulnerabilities are detected in the operating systems and third-party components that are used by Aspera. Aspera publishes security bulletins immediately that describe the affected products and recommended remediation steps.

Security Configuration

Recommended security settings vary depending on the products you are using and how they interact. See the following subsections for your Aspera products.

HSTS (and HSTE)

Edit online
  1. Configure your SSH Server.
    Aspera recommends that you:
    • Open TCP/33001 and keep TCP/22 open until users are notified that they should switch to TCP/33001.
    • Once users are notified, block TCP/22 and allow traffic only on TCP/33001.

    The following steps open TCP/33001 and block TCP/22.

    1. Open the SSH configuration file. 
      /etc/ssh/sshd_config

      If you do not have an existing configuration for OpenSSH, or need to update an existing one, Aspera recommends the following reference: https://wiki.mozilla.org/Security/Guidelines/OpenSSH.

    2. Change the SSH port from TCP/22 to TCP/33001.
      Add TCP/33001 and comment out TCP/22 to match the following example:
      #Port 22 
Port 33001

      HSTS admins must also update the SshPort value in the <WEB...> section of aspera.conf.

      Once this setting takes effect:

      • Aspera clients must set the TCP port to 33001 when creating connections in the GUI or specify -P 33001 for command line transfers.
      • Server administrators should use ssh -p 33001 to access the server through SSH.
    3. Disable non-admin SSH tunneling.
      SSH tunneling can be used to circumvent firewalls and access sensitive areas of your company's network. Add the following lines to the end of sshd_config (or modify them if they already exist) to disable SSH tunneling:
      AllowTcpForwarding no
Match Group root 
AllowTcpForwarding yes

      Depending on your sshd_config file, you might have additional instances of AllowTCPForwarding that are set to the default Yes. Review your sshd_config file for other instances and disable if necessary.

      Disabling TCP forwarding does not improve security unless users are also denied shell access, because with shell access they can still install their own forwarders. Aspera recommends assigning users to aspshell, described in the following section.

    4. Disable password authentication and enable public key authentication.
      Public key authentication provides a stronger authentication method than passwords, and can prevent brute-force SSH attacks if all password-based authentication methods are disabled.
      Important: Before proceeding:
      • Create a public key and associate it with a transfer user, otherwise clients have no way of connecting to the server.

        For instructions on using public key authentication, see Creating SSH Keys and Setting Up a User's Public Key on the Server.

      • Configure at least one non-root, non-transfer user with a public key to use to manage the server. This is because in the following steps, root login is disabled and transfer users are restricted to aspshell, which does not allow interactive login. This user and public key is what you use to access and manage the server as an administrator.

      Add or uncomment PubkeyAuthentication yes and comment out PasswordAuthentication yes:

      PubkeyAuthentication yes
#PasswordAuthentication yes
PasswordAuthentication no
      Note: If you choose to leave password authentication enabled, be sure to advise account creators to use strong passwords and set PermitEmptyPasswords to "no".
      PermitEmptyPasswords no
    5. Disable root login.
      CAUTION:
      This step disables root access. Make sure that you have at least one user account with sudo privileges before continuing, otherwise you may not have access to administer your server.

      Comment out PermitRootLogin yes and add PermitRootLogin No:

      #PermitRootLogin yes 
PermitRootLogin no
    6. Restart the SSH server to apply new settings. Restarting your SSH server does not affect currently connected users. 
      $ sudo stopsrc -s sshd 
$ sudo startsrc -s sshd
      isi services -a sshd disable
# isi services -a sshd enable
    7. Review your logs periodically for attacks.
      For information on identifying attacks, see IBM Aspera IBM Aspera High-Speed Transfer Server Admin Guide: Securing Your SSH Server.
  2. Configure your server's firewall to permit inbound access to only Aspera-required ports.

    Aspera requires inbound access on the following ports:

    • For SSH connections that are used to set up connections, TCP/33001.
    • For FASP transfers, UDP/33001.
    • If you use HTTP and HTTPS fallback with HSTS, TCP/8080 and TCP/8443. If you only use HTTPS, only open TCP/8443.
  3. For HSTS, require strong TLS connections to the web server.
    TLS 1.0 and TLS 1.1 are vulnerable to attack. Run the following command to require that the client's SSL security protocol be TLS version 1.2 or higher:
    # /opt/aspera/bin/asconfigurator -x "set_server_data;ssl_protocol,tlsv1.2"
  4. If asperanoded is exposed to internet traffic, run it behind a reverse proxy.
    If your Aspera server must expose asperanoded to the internet, such as when setting it up as a IBM Aspera on Cloud (AoC) node, Aspera strongly recommends protecting it with a reverse proxy. Normally, asperanoded runs on port 9092, but nodes that are added to AoC must have asperanoded run on port 443, the standard HTTPS port for secure browser access. Configuring a reverse proxy in front of asperanoded provides additional protection (such as against DOS attacks) and resource handling for requests to the node's 443 port.
  5. Install Aspera FASP Proxy in a DMZ to isolate your HSTS from the Internet.
    For more information, see IBM Aspera FASP Proxy Admin Guide

Securing the Aspera Applications

Edit online
Your Aspera products can be configured to limit the extent to which users can connect and interact with the servers. The instructions for Shares 1.9.x and Shares 2.x are slightly different; see the section for your version.

HSTS

Edit online
  1. Restrict user permissions with aspshell.
    By default, all system users can establish a FASP connection and are only restricted by file permissions. Restrict the user's file operations by assigning them to use aspshell, which permits only the following operations:
    • Running Aspera uploads and downloads to or from this computer.
    • Establishing connections between Aspera clients and servers.
    • Browsing, listing, creating, renaming, or deleting contents.

    These instructions explain one way to change a user account or active directory user account so that it uses the aspshell; there may be other ways to do so on your system.

    Run the following command to change the user login shell to aspshell:

    # sudo usermod -s /bin/aspshell username

    Confirm that the user's shell updated by running the following command and looking for /bin/aspshell at the end of the output:

    # grep username /etc/passwd
username:x:501:501:...:/home/username:/bin/aspshell
    Note: If you use OpenSSH, sssd, and Active Directory for authentication: To make aspshell the default shell for all domain users, first set up a local account for server administration because this change affects all domain users. Then open /etc/sssd/sssd.conf and change default_shell from /bin/bash to /bin/aspshell.
  2. Restrict Aspera transfer users to a limited part of the server's file system or bucket in object storage.
    1. For on-premises servers, set a default docroot to an empty folder, then set a docroot for each user: 
      # asconfigurator -x "set_node_data;absolute,docroot"
# asconfigurator -x "set_user_data;user_name,username;absolute,docroot"

      Replace username with the username and docroot with the directory path to which the user should have access.

    2. For cloud-based servers, set a default restriction to an empty folder, then set a restriction for each user: 
      # asconfigurator -x "set_node_data;file_restriction,|storage_path"
# asconfigurator -x "set_user_data;user_name,username;file_restriction,|storage_path"

      Replace username with the username and storage_path with the path to which the user has access. Restriction syntax is specific to the storage:

      Storage Type Format Example
      local storage file:////*
      S3 and IBM Cloud Object Storage s3://*
      Swift storage swift//*
      Azure storage azu://*
      Azure Files azure-files://*
      Google Cloud Storage gs://*
      Hadoop (HDFS) hdfs://*

      The "|" is a delimiter, and you can add additional restrictions. For example, to restrict the system user xfer to s3://s3.amazonaws.com/bucket_xyz/folder_a/* and not allow access to key files, run the following command: 

      # asconfigurator -x "set_user_data;user_name,xfer;file_restriction,|s3://s3.amazonaws.com/bucket_xyz/folder_a/*|!*.key"
  3. Restrict users' read, write, and browse permissions.
    Users are given read, write, and browse permissions to their docroot by default. Change the global default to deny these permissions: 
    # asconfigurator -x "set_node_data;read_allowed,false;write_allowed,false;dir_allowed,false"

    Run the following commands to enable permissions per user, as required:

    # asconfigurator -x "set_user_data;user_name,username;read_allowed,false"
# asconfigurator -x "set_user_data;user_name,username;write_allowed,false"
# asconfigurator -x "set_user_data;user_name,username;dir_allowed,false"
  4. Limit transfer permissions to certain users.
    Set the default transfer permissions for all users to deny:
    # asconfigurator -x "set_node_data;authorization_transfer_in_value,deny"
# asconfigurator -x "set_node_data;authorization_transfer_out_value,deny"

    Allow transfers for specific users by running the following commands for each user:

    # asconfigurator -x "set_user_data;user_name,username;authorization_transfer_in_value,allow"
# asconfigurator -x "set_user_data;user_name,username;authorization_transfer_out_value,allow"
    Note: For a user that is used by Shares or Faspex (usually xfer), allow transfers only with a token by setting authorization_transfer_{in|out}_value to token.
  5. Encrypt transfer authorization tokens.
    When a client requests a transfer from a server through an Aspera web application, an authorization token is generated. Set the encryption key of the token for each user or group on the server:
    # asconfigurator -x "set_user_data;user_name,username;token_encryption_key,token_string"
# asconfigurator -x "set_group_data;group_name,groupname;token_encryption_key,token_string"

    The token string should be at least 20 random characters.

    Note: This is not used to encrypt transfer data, only the authorization token.
  6. Require encryption of content in transit.
    Your server can be configured to reject transfers that are not encrypted, or that are not encrypted with a strong enough cipher. Aspera recommends setting an encryption cipher of at least AES-128. AES-192 and AES-256 are also supported but result in slower transfers. Run the following command to require encryption:
    # asconfigurator -x "set_node_data;transfer_encryption_allowed_cipher,aes-128"

    By default, your server is configured to transfer (as a client) using AES-128 encryption. If you require higher encryption, change this value by running the following command:

    # asconfigurator -x "set_client_data;transport_cipher,value"

    You can also specify the encryption level in the command line by using -c cipher with ascp and async transfers. ascp4 transfers use AES-128 encryption.

  7. Configure SSH fingerprinting for HSTS.
    For transfers initiated by a web application (such as Faspex, Shares, or Console), the client browser sends the transfer request to the web application server over an HTTPS connection. The web application requests a transfer token from the target server. The transfer is executed over a UDP connection directly between the client and the target server and is authorized by the transfer token. Prior to initiating the transfer, the client can verify the server's authenticity to prevent server impersonation and man-in-the-middle (MITM) attacks.

    To verify the authenticity of the transfer server, the web application passes the client a trusted SSH host key fingerprint of the transfer server. The client confirms the server's authenticity by comparing the server's fingerprint with the trusted fingerprint. In order to do this, the host key fingerprint or path must be set in the server's aspera.conf.

    Note: Server SSL certificate validation (HTTPS) is enforced if a fingerprint is specified in aspera.conf and HTTP fallback is enabled. If the transfer "falls back" to HTTP and the server has a self-signed certificate, validation fails. The client requires a properly signed certificate.

    If you set the host key path, the fingerprint is automatically extracted from the key file and you do not extract it manually.

    Retreiving and setting the host key fingerprint:

    1. Retrieve the server's SHA-1 fingerprint. 
      # cat /etc/ssh/ssh_host_rsa_key.pub | awk '{print $2}' | base64 -d | sha1sum
    2. Set the SSH host key fingerprint in aspera.conf. (Go to the next step to set the host key path instead). 
      # asconfigurator -x "set_server_data;ssh_host_key_fingerprint,fingerprint"

      This command creates a line similar to the following example of the <server> section of aspera.conf:

      <ssh_host_key_fingerprint>7qdOwebGGeDeN7Wv+2dP3HmWfP3 
</ssh_host_key_fingerprint>
    3. Restart the node service to activate your changes.
      Run the following commands to restart asperanoded:
      # /etc/rc.d/init.d/asperanoded restart
      isi services -a asperanoded disable
# isi services -a asperanoded enable

    Setting the host key path: To set the SSH host key path instead of the fingerprint, from which the fingerprint will be extracted automatically, run the following command:

    # asconfigurator -x "set_server_data;ssh_host_key_path,ssh_key_filepath"

    This command creates a line similar to the following in the <server> section of aspera.conf:

    <ssh_host_key_path>/etc/ssh/ssh_host_rsa_key.pub
</ssh_host_key_path>

    Restart the node service to activate your changes, as described for "Retreiving and setting the host key fingerprint".

  8. Install properly signed SSL certificates.
    Though your Aspera server automatically generates self-signed certificates, Aspera recommends installing valid, signed certificates. These are required for some applications.

Securing Content in your Workflow

Edit online
  1. If your workflow allows, enable server-side encryption-at-rest (EAR).
    When files are uploaded from an Aspera client to the Aspera server, server-side encryption-at-rest (EAR) saves files on disk in an encrypted state. When downloaded from the server, server-side EAR first decrypts files automatically, and then the transferred files are written to the client's disk in an unencrypted state. Server-side EAR provides the following advantages:
    • It protects files against attackers who might gain access to server-side storage. This is important primarily when using NAS storage or cloud storage, where the storage can be accessed directly (and not just through the computer running HSTS).
    • It is especially suited for cases where the server is used as a temporary location, such as when one client uploads a file and another client downloads it.
    • Server-side EAR can be used together with client-side EAR. When used together, content is doubly encrypted.
    • Server-side EAR doesn't create an "envelope" as client-side EAR does. The transferred file stays the same size as the original file. The server stores the metadata necessary for server-side EAR separately in a file of the same name with the file extension .aspera-meta. By contrast, client-side EAR creates a envelope file containing both the encrypted contents of the file and the encryption metadata, and it also changes the name of the file by adding the file extension .aspera-env.)
    • It works with both regular transfers (FASP) and HTTP fallback transfers.

    Limitations and Other Considerations

    • Server-side EAR is not designed for cases where files need to move in an encrypted state between multiple computers. For that purpose, client-side EAR is more suitable: files are encrypted when they first leave the client, then stay encrypted as they move between other computers, and are decrypted when they reach the final destination and the passphrase is available. See Step 4 of this section for more information on client-side encryption.
    • Do not mix server-side EAR and non-EAR files in transfers, which can happen if server-side EAR is enabled after the server is in use or if multiple users have access to the same area of the file system but have different EAR configurations. Doing so can cause problems for clients by overwriting files when downloading or uploading and corrupting metadata.
    • Server-side EAR does not work with multi-session transfers (using ascp -C or node API multi_session set to greater than 1) or Watch Folders (versions prior to 3.8.0 that do not support URI docroots).

    To enable server-side EAR:

    1. Set users' docroots in URI format (local docroots are prepended with file:///). 
      # asconfigurator -x "set_user_data;user_name,username;absolute,file:///path"
    2. Set the server-side EAR password.
      Set a different EAR password for each user:
      # asconfigurator -x "set_user_data;user_name,username;transfer_encryption_content_protection_secret,passphrase"
      Important: If the EAR password is lost or aspera.conf is compromised, you cannot access the data on the server.
    3. Require content protection and strong passwords.
      These settings cause server-side EAR to fail if a password is not given or if a password is not strong enough. For example, the following asconfigurator command adds both these options for all users (global):
      # asconfigurator -x "set_node_data;transfer_encryption_content_protection_required,true"
# asconfigurator -x "set_node_data;transfer_encryption_content_protection_strong_pass_required,true"
  2. Never use "shared" user accounts.
    Configure each user as their own Aspera transfer user. Sharing Aspera transfer user account credentials with multiple users limits user accountability (you cannot determine which of the users sharing the account performed an action).
  3. Use passphrase-protected private keys.
    The ssh-keygen tool can protect an existing key or create a new key that is passphrase protected.

    If you cannot use private key authentication and use password authentication, use strong passwords and change them periodically.

  4. If your workflow allows, require client-side encryption-at-rest (EAR).
    Aspera clients can set their transfers to encrypt content in transit and on the server, and the server can be configured to require client-side EAR. You can combine client-side and server-side EAR, in which case files are doubly encrypted on the server. Client-side encryption-at-rest is not supported for ascp4 or async transfers.

    Client configuration

    The client specifies a password and the files are uploaded to the server with a .aspera-env extension. Anyone downloading these .aspera-env files must have the password to decrypt them. Users can enable client-side EAR in the GUI or on the ascp command line.

    GUI: Go to Connections > connection_name > Security. Select Encrypt uploaded files with a password and set the password. Select Decrypt password-protected files downloaded and enter the password.

    Ascp command line: Set the encryption and decryption password as the environment variable ASPERA_SCP_FILEPASS. For uploads (--mode=send), use --file-crypt=encrypt. For downloads (--mode=recv), use --file-crypt=decrypt.

    Note: When a transfer to HSTS falls back to HTTP or HTTPS, client-side EAR is no longer supported. If HTTP fallback occurs while uploading, then the files are NOT encrypted. If HTTP fallback occurs while downloading, then the files remain encrypted.

    Server configuration

    To configure the server to require client-side EAR and to require strong content protection passwords, run the following commands:

    # asconfigurator -x "set_node_data;transfer_encryption_content_protection_required,true"
# asconfigurator -x "set_node_data;transfer_encryption_content_protection_strong_pass_required,true"
    Note: These commands set the global configuration. Depending on your work flow, you might want to require client-side EAR and strong passwords for only specific users.
  5. For particularly sensitive content, do not store unecrypted content on any computer with network access.
    HSTS, HSTE, and Desktop Client include the asprotect and asunprotect command-line tools that can be used to encrypt and decrypt files. Use an external drive to physically move encrypted files between a network-connected computer and an unconnected computer on which the files can be unencrypted.
    • To encrypt a file before moving it to a computer with network access, run the following commands to set the encryption password and encrypt the file:
      # export ASPERA_SCP_FILEPASS=password
# /opt/aspera/bin/asprotect -o filename.aspera-env filename
    • To download client-side-encrypted files without decrypting them immediately, run the transfer without decryption enabled (clear Decrypt password-protected files downloaded in the GUI or do not specify --file-crypt=decrypt on the ascp command line).
    • To decrypt encrypted files, run the following commands to set the encryption password and decrypt the file: 
      # export ASPERA_SCP_FILEPASS=password
# /opt/aspera/bin/asprotect -o filename filename.aspera-env