Aspera Ecosystem Security Best Practices

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, IBM Aspera Faspex,IBM Aspera Shares, and IBM Aspera Console.

Contents

Securing the Systems that Run Aspera Software

Securing the Aspera Application

Securing Content in your Workflow

Securing the Systems that Run Aspera Software

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 Apache, 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 (You should use 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.
  • If you are using the HSTS web UI, keep Apache serverIIS up to date.

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

  1. Configure your SSH Server.
    • 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.
      C:\Program Files\Aspera\\etc\sshd_config
      /etc/ssh/sshd_config

      If you do not have an existing configuration for OpenSSH, or need to update an existing one, see 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 Administrators 
      AllowTcpForwarding yes 
      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. Assign users to aspshell, as 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.
      • 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.
      Click Start > Control Panel > Administrative Tools > Services. Locate the OpenSSH Service and click Restart.
      # systemctl restart sshd.service
      or for Linux systems that use init.d:
      # service sshd restart
    7. Review your logs periodically for attacks.
  2. For Aspera servers on Windows in an Active Directory Domain, create the Active Directory user account to use as the Aspera service account before installing your Aspera server software. This ensures that the correct security settings are applied to the user.
  3. 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 (or a range, see below).
    • If you use HTTP and HTTPS fallback with HSTS, TCP/8080 and TCP/8443. If you only use HTTPS, only open TCP/8443.
    • If your clients access the HSTS web UI, TCP/80 (for HTTP) or TCP/443 (for HTTPS).
  4. 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"
  5. If Aspera Node D is exposed to internet traffic, run it behind a reverse proxy.
    If your Aspera server must expose Aspera Node D to the internet, such as when setting it up as an IBM Aspera on Cloud (AoC) node, protect it with a reverse proxy. Normally, Aspera Node D runs on port 9092, but nodes that are added to AoC must have Aspera Node D run on port 443, the standard HTTPS port for secure browser access. Configuring a reverse proxy in front of Aspera Node D provides additional protection (such as against DOS attacks) and resource handling for requests to the node's 443 port.

    The following instructions describe how to set up Nginx as a reverse proxy and require that you have valid, CA-signed SSL certificates in .pem format for the server. Other reverse proxies might be supported on your server.

    1. Set up a system user with Node API credentials on your server.
    2. Download and install Nginx.
    3. Configure the HTTPS port for Aspera Node D.
      # asconfigurator -x "set_server_data;https_port,9092"
    4. Open the Nginx configuration file in a text editor.
      Open C:\nginx\conf\nginx.conf and ensure the following include directive is present in the http section. If it is not present, add it to the file:
      http {
      …
      include /etc/nginx/conf.d/*.confC:\nginx\*.conf;
      }
    5. Create a file named aspera_node_proxy.conf and save it in the following location:
      C:\nginx\conf\sites-enabled\aspera_node_proxy.conf

      Create the sites-enabled folder if it does not exist.

    6. Paste the following content into aspera_node_proxy.conf:
      #
      # Aspera configuration - reverse proxy for asperanoded
      #
      server {
             listen 443;
             server_name your.servername.com;
             ssl_certificate "C:/Program Files/Aspera/Enterprise Server/etc/aspera_server_cert.pem";
             ssl_certificate_key "C:/Program Files/Aspera/Enterprise Server/etc/aspera_server_key.pem";
      
             ssl on;
             ssl_session_cache builtin:1000 shared:SSL:10m;
             ssl_protocols TLSv1.2;
             ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;
             ssl_prefer_server_ciphers on;
      
             access_log          C:\Logs\nginx\node-api.access.log;
      
             location / {
                 proxy_pass https://127.0.0.1:9092;
                 proxy_read_timeout 60;
                 proxy_redirect https://127.0.0.1:9092 https://your.servername.com;
      
                 proxy_set_header Host               $host:$server_port;
                 proxy_set_header X-Real-IP          $remote_addr;
                 proxy_set_header X-Forwarded-For    $proxy_add_x_forwarded_for;
                 proxy_set_header X-Forwarded-Proto  $scheme;
             }
      }
      Note: Configure SSL ciphers as required. The preceding sample is not configured for backwards compatibility, and the recommended list of secure ciphers might change. Review and stay current with the list provided in https://cipherli.st/.

      In this configuration, Nginx listens externally on port 443, not 9092. Replace your.servername.com with your server's domain name.

    7. Restart Aspera Node D.
      # systemctl restart asperanoded
      or for Linux systems that use init.d:
      # service asperanoded restart
      > net stop asperanoded
      > net start asperanoded
    8. Restart Nginx.
      > nginx -s reload
    9. Run Nginx as a Windows service.
      When you install Nginx on a Windows OS, it is installed as an application that runs only when the user who installed the application is logged in. However, for HSTS nodes that are added to AoC, you should run Nginx as a service so that its function is not tied to a specific user.

      For instructions, see https://ibm.ibmaspera.com/helpcenter/admin/nodes/configuring-an-aspera-transfer-server-as-a-node-for-aspera-on-cloud.

  6. Install Aspera FASP Proxy in a DMZ to isolate your HSTS from the Internet.
    For more information, see IBM Aspera FASP Proxy Admin Guide

Faspex and Shares

  1. Configure your Faspex or Shares server firewall to allow inbound access to TCP/443, the default HTTPS port.
  2. Faspex and Shares transfer nodes should be configured as described for HSTS.
    The transfer user that is used by Faspex and Shares (usually xfer) must be configured on the node to only allow transfers with a token:
    > asconfigurator -x "set_user_data;user_name,xfer;authorization_transfer_in_value,token"
    > asconfigurator -x "set_user_data;user_name,xfer;authorization_transfer_out_value,token"

    Set the token encryption key to a string of at least 20 characters:

    > asconfigurator -x "set_user_data;user_name,xfer;token_encryption_key,token_string"

    Do not use UUIDs for this key because they might not be generated using cryptographically secure methods.

Console

Configure the firewall of the computer on which Console is installed to only allow Aspera-required connections to the following ports:
  • For HTTP or HTTPS access for the web UI, inbound TCP/80 or TCP/443.
  • For SSH connections, outbound TCP/33001 to managed nodes.
  • For Node API connections, outbound TCP/9092 to managed nodes.
  • For connections to legacy nodes (those running HSTS older than 3.4.6), outbound TCP/40001 and inbound TCP/4406. For security and reliability, upgrade all nodes to the latest version.

Securing the IBM Aspera Applications

Your IBM Aspera products can be configured to limit the extent to which users can connect and interact with the servers.

HSTS

  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.

    Windows users are assigned to aspshell automatically when you configure the user in the GUI and specify a non-empty docroot. If you do not specify a docroot or configure users from the command line, you must manually set the users' shell as aspshell.exe in C:\Program Files\Aspera\\etc\passwd.

    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:////*file:///c%3A/Documents/*
      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. Set 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 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 - | sha1sum
      On the server, run a local ascp transfer. The transfer does not need to complete successfully in order for the remote host-key fingerprint to appear in the log.
      > ascp source_file username@localhost:destination

      Open C:\Program Files\Aspera\\var\log\aspera-scp-transfer.log. Search for "remote host-key fingerprint". The line appears similar to the following, in which 19f7cf4d495234ng4342ha062f5d98b5a9d665 is the SHA-1 fingerprint:

      2017-12-08 12:04:53.024 [1888-0000264c] LOG [asssh] remote host-key fingerprint 19f7cf4d495234ng4342ha062f5d98b5a9d665
    2. Set the SSH host key fingerprint in aspera.conf.
      > 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.
      Go to Control Panel > Administrative Tools > Services, click Aspera NodeD, and click Restart.Run the following commands to restart asperanoded:
      > systemctl restart asperanoded
      or for Linux systems that use init.d:
      > service asperanoded restart

    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, you should install valid, signed certificates. These are required for some applications.

Faspex

Many of the settings for Faspex are the same as for HSTS, including SSH server configuration, firewall settings, and signed SSL certificate installation. The following recommendations augment or are additional to the recommendations described for HSTS.
  1. Restrict transfers by all users except "faspex".
    If your system is a dedicated Faspex server - the HSTS installed as part of your Faspex installation is used only for Faspex transfers - prohibit transfers by all users except "faspex". If you have not already, deny transfers globally by default:
    > asconfigurator -x "set_node_data;authorization_transfer_in_value,deny"
    > asconfigurator -x "set_node_data;authorization_transfer_out_value,deny"

    Allow transfers for "faspex" by running the following commands:

    > asconfigurator -x "set_user_data;user_name,faspex;authorization_transfer_in_value,token"
    > asconfigurator -x "set_user_data;user_name,faspex;authorization_transfer_out_value,token"
  2. Configure the Nginx server to allow only strong TLS.
    The default configuration of Faspex has TLS 1.0, 1.1 and 1.2 enabled. Older browsers require the older and less secure versions (TLS 1.0 and 1.1). You can disable support for older browsers by removing TLS 1.0 and TLS 1.1 from the configuration.
    1. Open the Nginx configuration file on the Shares server for editing:
      C:\Program Files\Common Files\Aspera\Common\apache\conf\extra/httpd-ssl.conf
    2. Locate the following line:
      SSLProtocol ALL -SSLv2 -SSLv3
    3. Replace the line with the following and save your change:
      SSLProtocol TLSv1.2
    4. Restart Apache to activate your change:
      > asctl apache:restart
  3. Limit admin logins to those from known IP addresses.
    Faspex admins have the ability to execute post-processing scripts on the server. If an admin account is compromised, this capability can be a serious threat to your server's security. You can add additional protection by allowing admin logins from only specific IP addresses.
    1. In the Faspex UI, go to Accounts and select the admin account.
    2. In the Permissions section, locate the Allowed IP addresses for login field and enter the IP addresses or IP address range to allow.
    3. Click Save to activate your changes.
  4. Configure Faspex account security settings.
    Go to Server > Configuration > Security and set the following global default configurations in the Faspex accounts section, then edit configurations for individual users, as needed:
    1. Set a non-zero session timeout.
    2. Lock users out after five failed login attempts within five minutes.
    3. Enable Prevent concurrent login.
    4. Set a password expiration interval of 30 days.
    5. Prevent reuse of the last three passwords and require strong passwords.
    6. Set Keep user directory private to Yes.
    7. Disable Allow all users to send to all other Faspex users.
    8. Disable Users can see global distribution lists.
    9. Disable Ignore invalid recipients.
    10. Disable Allow users to change their email address.
    Stay in Server > Configuration > Security for the next step.
  5. Configure Faspex account registration settings.
    In Server > Configuration > Security, set the following configurations in the Registrations section:
    1. Set Self-registration to None.
      When self-registration is enabled, it can be used to find out whether a certain account exists on the server. That is, if you attempt to self-register a duplicate account, you receive a prompt stating that the user already exists.
    2. Select Require external users to register.
      By requiring external users to register, you can better track their Faspex activity.
    Stay in Server > Configuration > Security for the next step.
  6. Configure outside email address settings.
    In Server > Configuration > Security, set the following global default configurations in the Outside email addresses section, then edit configurations for individual users, as needed:
    1. Disable Allow inviting external senders.
    2. Enable Invitation link expires and set an expiration policy.
    3. Disable Allow public submission URLs.
    4. Disable Allow sending to external email addresses.
    5. Set a package link expiration.
    6. Disable Allow external packages to Faspex users.
    Stay in Server > Configuration > Security for the next step.
  7. Configure Faspex encryption.
    In Server > Configuration > Security, set the following configurations in the Encryption section:
    1. Enable Encrypt transfers.
    2. If possible in your work flow, set Use encryption-at-rest to Always.
      See the next section, "Securing Content in your Workflow," for information about encryption at rest.
    3. Disable Allow dropboxes to have their own encryption settings.
  8. Click Update when you have completed updating settings on the Security page to activate your changes.
  9. Hide your server's IP address from email notifications.
    If Faspex is configured to identify itself by IP address (rather than by domain name), then the URLs in your notification emails contain your IP address (for example, "https://10.0.0.1/aspera/faspex"). Configure an alternate IP address or domain name for users who are external to your organization.
    1. Go to Server > Configuration > Web Server.
    2. Select Enable alternate address then click Add alternate address.
    3. Enter the address name and description, and select Show in emails.
    4. Click Update to activate your change.
    5. Customize your email notification templates to use the alternate address.
      Go to Server > Notifications.

Shares

The Shares server and its nodes should be secured as described for HSTS, including SSH server configuration, firewall settings, and valid, signed SSL certificate installation. You can also secure the Shares application and its network of nodes by restricting user permissions. Set the following settings globally, then edit the settings for specific users and groups.
  1. Configure Shares security settings.
    On the Admin page, click User Security and set the following:
    1. Set a non-zero session timeout.
    2. Require strong passwords.
    3. Set a password expiration interval of 30 days.
    4. Lock users out after five failed login attempts within five minutes.
    5. Do not allow self registration by setting Self Registration to None.
  2. When setting up the email server (Admin > SMTP), select Use TLS if available.
  3. Configure the Nginx server to allow only strong TLS.
    The default configuration of Shares has TLS 1.0, 1.1 and 1.2 enabled. Older browsers require the older and less secure versions (TLS 1.0 and 1.1). You can disable support for older browsers by removing TLS 1.0 and TLS 1.1 from the configuration.
    1. Open the Nginx configuration file on the Shares server for editing:
      C:\Shares\nginx\conf\nginx.conf
    2. Delete TLSv1 and TLSv1.1 from the following line:
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  4. Configure secure transfer settings.
    Go to System Settings > Transfers and set the following:
    1. Require a minimum Connect version of 3.6.1.
    2. For Encryption, select AES-128.
    3. If possible in your workflow, set Encryption at Rest to Required.
      See the next section, "Securing Content in your Workflow," for information about encryption at rest.
  5. Go to System Settings > Web Server and select Enable SSL/TLS.
    This setting requires that the Shares server has a valid, signed SSL certificate.
  6. When adding new users to Shares, disable API Login if users do not need to use the Shares API.
    The Shares API is used by clients connecting through IBM Aspera Connect and IBM Aspera Command-Line Interface
  7. When adding nodes to Shares, select Use SSL (required by Shares) and Verify SSL (requires that the node has a valid, signed SSL certificate).
  8. When authorizing a user or group to a share (share_name > Authorizations), set the minimum permissions required based on their Shares use.

Console

Console nodes should be secured as described for HSTS, including SSH server configuration, firewall settings, and valid, signed SSL certificate installation. If possible for your workflow, limit Console and its nodes to your internal network.

You can also secure the Console application and its network of nodes by restricting user permissions:

  1. Configure secure Console defaults.
    Go to Configuration > Defaults and set the following:
    1. In the drop-down menu for Default SSH encryption, select a default SSH encryption algorithm of at least AES-128 for non-Console nodes.
    2. For Transport Encryption, select AES-128.
    3. Disable Smart Transfer Sharing.
    4. Set a non-zero session timeout.
    5. Lock users out after five failed login attempts within five minutes.
    6. Enable Prevent concurrent login.
    7. Enable Suppress logging of transfer tokens to prevent tokens from being written to the Console database.
    8. Set a password expiration interval of 30 days.
    9. Prevent reuse of the last three passwords and require strong passwords.
  2. When setting up the email server (Notifications > Email Server), select Use TLS if available.
  3. Restrict Console users' permissions.
    1. When creating a new user (Accounts > Users > New User), disable user login until their permissions are set by clearing Active (allow user to log in). Click permissions and enable only the permissions that the user requires. Once permissions are configured, allow the user to login by going to Accounts > Users, clicking the user, and selecting Active (allow user to log in).
    2. Assign users to Console Groups with only the required transfer paths and permissions allowed.
      Create a group (Accounts > Groups > New Group) and restrict the group's transfers by clicking Add Transfer Path. Assign specific endpoints to the group's transfer path, rather than Any, which grants permission to transfer to all nodes. Limit the direction of the path, if the group's workflow allows.
  4. When adding managed and unmanaged nodes, set the SSH port to 33001 and ensure SSH connections are encrypted with AES-128 or higher.
  5. When adding a managed cluster, select Use HTTPS to connect to node and Require signed SSL certificate.
  6. When adding SSH endpoints, use SSH public key authentication rather than password authentication.
    The key file on the node should not be a shared key; it should be a "private" key in the specified user account.

Securing Content in your Workflow

  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:
      > setexport 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:
      > setexport ASPERA_SCP_FILEPASS=password
      > /opt/aspera/bin/asprotect -o filename filename.aspera-env