Aspera Ecosystem Security Best Practices

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. To be automatically notified when a new version of your product has been released, go to the Aspera Support website (http://support.asperasoft.com) and locate the "Release Notes" section for your product. Click Follow this section. You will receive an email each time this section is updated.
If using, keep OpenSSH up to date. The server security instructions require that OpenSSH 4.4 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 Connect Server on Linux, keep your Apache server up to date. If you are using Connect Server on Windows, keep your IIS 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. To be automatically notified when a new security bulletin is published to the Aspera knowledge base, go to http://support.asperasoft.com, click Announcements > Security Bulletins > Follow this section.

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.

Enterprise Server and Connect Server

Configure your SSH Server.
1. Open the SSH configuration file for editing.
  C:\Program Files\Aspera\\etc\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
```
  Connect Server 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.
  - To remotely access the server by using SSH, server administrators should specify ssh -p 33001.
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.
  - 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.
7. Review your logs periodically for attacks.
  For information on identifying attacks, see IBM Aspera Enterprise Server Admin Guide: Securing Your SSH Server.
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. If you create the Active Directory service account user after installation, see the following knowledge base article for instructions on how to configure security policies for the acount.
https://support.asperasoft.com/hc/en-us/articles/216125388-OpenSSH-in-Active-Directory-Environments
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 Connect Server, TCP/8080 and TCP/8443. If you only use HTTPS, only open TCP/8443.
- If your clients access the Connect Server web UI, TCP/80 (for HTTP) or TCP/443 (for HTTPS).
For Connect Server, 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:
```
> asconfigurator -x "set_server_data;ssl_protocol,tlsv1.2"
```
If Connect Server's asperanoded is exposed to internet traffic, run it behind a reverse proxy.
If your Aspera server must expose the Aspera NodeD service to the internet, such as when setting it up as a Files node, Aspera strongly recommends protecting it with a reverse proxy. Normally, asperanoded runs on port 9092, but nodes that are added to Files 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.
Install Aspera FASP Proxy in a DMZ to isolate your Enterprise Server or Connect Server from the Internet.
For more information, see IBM Aspera FASP Proxy Admin Guide

Faspex and Shares

Configure your Faspex or Shares server firewall to allow inbound access to TCP/443, the default HTTPS port.
Faspex and Shares nodes should be configured as described for Enterprise Server.
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 Enterprise Server older than 3.4.6), outbound TCP/40001 and inbound TCP/4406. For security and reliability, Asepra strongly recommends upgrading all nodes to the latest version.

Securing the Aspera Application

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.

Enterprise Server and Connect Server

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.
Windows users are automatically assigned to aspshell when they are configured as transfer users in the GUI.

Restrict Aspera transfer users to a limited part of the server's file system or bucket in object storage.

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.

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:///C:\*
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"

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"
```
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.
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.
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.
Configure SSH fingerprinting for Connect Server.
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 app 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.
1. Retrieve the server's SHA-1 fingerprint.
  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.
Install properly signed SSL certificates.
Though your Aspera server automatically generates self-signed certificates, Aspera recommends installing valid, signed certificates.

Faspex

Many of the settings for Faspex are the same as for Enterprise Server, including SSH server configuration, firewall settings, and signed SSL certificate installation. The following recommendations augment or are additional to the recommendations described for Enterprise Server.

Restrict transfers by all users except "faspex".
If your system is a dedicated Faspex server - the Enterprise Server 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"
```
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
```
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.
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.
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.
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.
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.
Click Update when you have completed updating settings on the Security page to activate your changes.
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 1.9.x

The Shares server and its nodes should be secured as described for Enterprise Server, 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.

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.
When setting up the email server (Admin > SMTP), select Use TLS if available.
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;
```
Configure secure transfer settings.
Go to System Settings > Transfers and set the following:
1. Require a minimum Aspera 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.
Go to System Settings > Web Server and select Enable SSL/TLS.
This setting requires that the Shares server has a valid, signed SSL certificate.
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 Aspera Drive and Aspera CLI
When adding nodes to Shares, select Use SSL (required by Shares) and Verify SSL (requires that the node has a valid, signed SSL certificate).
When authorizing a user or group to a share (share_name > Authorizations), set the minimum permissions required based on their Shares use.

Shares 2.x

The Shares 2.x server and its nodes should be secured as described for Enterprise Server, including configuring the SSH server, firewall settings, and installing valid, signed SSL certificates. You can also secure the Share application and its network of nodes by restricting user permissions. Set the following settings globally and then edit the settings for specific users, groups, and administrators.

Configure Shares security settings.
Go to System Administration > Configuration > User Security and set the following:
1. Set a non-zero session timeout.
2. Set an access token lifetime of 8 hours.
3. Enable refreshing of expired access tokens, with a lifetime of 7 days.
Go to System Administration > Configuration > Local User Security and set the following:
1. Require strong passwords.
2. Set a password expiration interval of 30 days.
3. Lock users out after five failed login attempts within five minutes.
4. Prevent reuse of the last three passwords and require strong passwords.
When setting up the email server (System Administration > Configuration > SMTP), select Use TLS if available.
Configure secure transfer settings.
Go to System Administration > Configuration > Transfers and set the following:
1. Require a minimum Aspera Connect version of 3.6.1.
2. For Encryption, select AES-128 (or higher, if needed).
3. If possible in your workflow, set Encryption at Rest to Yes.
  See the next section, "Securing Content in your Workflow," for information about encryption at rest.
Go to System Administration > Configuration > Web Server and select Enable SSL/TLS.
This setting requires that the Shares server has a valid, signed SSL certificate.
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;
```
When adding nodes to Shares, select Use SSL (required by Shares) and Verify SSL (requires that the node has a valid, signed SSL certificate).
When authorizing a user or group to a share, set the minimum permissions required based on their Shares use.

Console

Console nodes should be secured as described for Enterprise Server, 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:

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.
When setting up the email server (Notifications > Email Server), select Use TLS if available.
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.
When adding managed and unmanaged nodes, set the SSH port to 33001 and ensure SSH connections are encrypted with AES-128 or higher.
When adding a managed cluster, select Use HTTPS to connect to node and Require signed SSL certificate.
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

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 Aspera Enterprise Server or Connect Server).
- 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"
```
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).
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.
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 Connect Server 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.
For particularly sensitive content, do not store unecrypted content on any computer with network access.
Enterprise Server, Connect Server, Point-to-Point Client, 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:
```
> set ASPERA_SCP_FILEPASS=password
> 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:
```
> set ASPERA_SCP_FILEPASS=password
> asprotect -o filename filename.aspera-env
```

Parent topic: Appendix