Secure your SSH server to prevent security risks.
Keeping your data secure is critically important. Aspera strongly recommends taking additional steps to set up and configure your SSH server so that it's protected against common attacks. Most automated robots try to log into your SSH server on Port 22 as root with various brute force and dictionary combinations in order to gain access to your data. Furthermore, automated robots can put enormous loads on your server as they perform thousands of retries to break into your system. This topic addresses steps to secure your SSH server against potential threats, including changing the default port for SSH connections from TCP/22 to TCP/33001.
Why Change to TCP/33001?
It is well known that SSH servers listen for incoming connections on TCP Port 22. As such, Port 22 is subject to countless, unauthorized login attempts by hackers who are attempting to access unsecured servers. A highly effective deterrent is to simply turn off Port 22 and run the service on a seemingly random port above 1024 (and up to 65535). To standardize the port for use in Aspera transfers, we recommend using TCP/33001.
The following explains how to change the SSH port to 33001 and take additional steps to secure your SSH server. The steps all require root access privileges.
The SSH configuration file can be found in the following location:
The OpenSSH suite included in the installer uses TCP/22 as the default port for SSH connections. Aspera recommends opening TCP/33001 and disabling TCP/22 to prevent security breaches of your SSH server.
To enable TCP/33001 while your organization is migrating from TCP/22, open port 33001 from your sshd_config file (where SSHD is listening on both ports). As demonstrated by this exercise, SSHD is capable of listening on multiple ports.
... Port 22 Port 33001 ...
Once your client users have been notified of the port change (from TCP/22 to TCP/33001), you can disable port 22 in your sshd_config file. To disable TCP/22 and use only TCP/33001, comment out "Port 22" in your sshd_config file.
... #Port 22 Port 33001 ...
To make an impromptu connection to TCP/33001 during an ascp session, specify the SSH port (33001) with the -P (capital P) flag. Note that this command does not alter ascp or your SSH server's configuration.
$ ascp -P 33001 ...
In OpenSSH versions 4.4 and newer, disable SSH tunneling to avoid potential attacks; thereby only allowing tunneling from root users. To disable non-admin SSH tunneling, open your SSH Server configuration file, sshd_config, with a text editor.
Add the following lines to the end of the file (or modify them if they already exist):
... AllowTcpForwarding no Match Group root AllowTcpForwarding yes
Depending on your sshd_config file, you may have additional instances of AllowTCPForwarding that are set to the default Yes. Review your sshd_config file for other instances and disable as appropriate.
Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders. Review your user and file permissions, and see the instructions below on modifying shell access.
Public key authentication can prevent brute-force SSH attacks if all password-based authentication methods are disabled. For this reason, Aspera recommends disabling password authentication in the sshd_config file and enabling private/public key authentication. To do so, add or uncomment PubkeyAuthentication yes and comment out PasswordAuthentication yes.
... PubkeyAuthentication yes #PasswordAuthentication yes PasswordAuthentication no ...
OpenSSH defaults to allowing root logins; however disabling root access helps you to maintain a more secure server. Aspera recommends commenting out PermitRootLogin yes in the sshd_config file and adding PermitRootLogin No.
... #PermitRootLogin yes PermitRootLogin no ...
Administrators can then utilize the su command if root privileges are needed.
When you have finished updating your SSH server configuration, you must restart or reload the SSH service to apply your new settings. Note that restarting or reloading SSH does not impact currently connected users.
To restart or reload your SSH server, run the following commands:
$ sudo service sshd restart
$ sudo service sshd reload
$ sudo /etc/init.d/ssh restart
$ sudo /etc/init.d/ssh reload
Restricting user access is a critical component of securing your server. By default, all user accounts are allowed to browse and read all files on the server. To limit a user's access to a portion of the system, set the account's shell to the Aspera secured shell (aspshell) and create a document root (docroot) for that user. The aspshell permits only the following operations:
The following instructions describe how to change a user account so that it uses the aspshell. Keep in mind that this is an example, and there may be other ways to do so for your system. Open the following file with a text editor:
Add or replace the user's shell with /bin/aspshell. For example, to apply aspshell to the user aspera_user_1, use the following settings in the passwd file:
... aspera_user_1:x:501:501:...:/home/aspera_user_1:/bin/aspshell ...
You can also restrict a user's file access by setting a document root (docroot). You can set a user's docroot by editing the aspera.conf file (/opt/aspera/etc/aspera.conf). The following template displays access options:
<file_system> <access> <paths> <path> <absolute>/sandbox/aspera_user_1</absolute> <!-- Absolute Path --> <read_allowed>true</read_allowed> <!-- Read Allowed --> <write_allowed>true</write_allowed> <!-- Write Allowed --> <dir_allowed>true</dir_allowed> <!-- Browse Allowed --> </path> </paths> </access> ... </file_system>
Once you've set the user's shell and docroot, you can further restrict access by disabling read, write, and/or browse using <path> settings in aspera.conf, as shown in the example above.
|Absolute Path||The area of the file system (path) that is accessible to the Aspera user. The default empty value gives a user access to the entire file system.||Path or blank|
|Read Allowed||Setting this to true allows users to transfer from the designated area of the file system as specified by the Absolute Path value.||
|Write Allowed||Setting this to true allows users to transfer to the designated area of the file system as specified by the Absolute Path value.||
|Browse Allowed||Setting this to true allows users to browse the directory.||
The asp-check tool performs the following secure checks:
To run the asp-check tool, run the following on the command line:
$ sudo /opt/aspera/bin/asp-check.sh
Search results are displayed as in the following example. If potential issues are identified, review your users' settings before proceeding.
Users with full access: 22 (not considered insecure) Restricted users: 0 Insecure users: 0 - no restricted shell (aspshell): 0 - docroot above home directory: 0 - ssh tunneling enabled: 0
Aspera recommends reviewing your SSH log periodically for signs of a potential attack. Locate and open your syslog—for example, /var/log/auth.log or /var/log/secure. Depending on your system configuration, syslog's path and file name may vary.
Look for invalid users in the log, especially a series of login attempts with common user names from the same address, usually in alphabetical order. For example:
... Mar 10 18:48:02 sku sshd: Failed password for invalid user alex from 184.108.40.206 port 1585 ssh2 ... Mar 14 23:25:52 sku sshd: Failed password for invalid user alice from 220.127.116.11 port 1585 ssh2 ...
If you identify attacks, do the following:
For transfers mediated by a web application (such as Faspex, Shares, or Console), the client browser sets up the context for the transfer using an HTTPS connection to the server, and then delegates the transfer to the Aspera FASP engine. The FASP engine then connects to the transfer server. In so doing, it needs to ensure the server's authenticity in order to protect the client against 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. When connecting to the transfer server, the client confirms the server's authenticity by comparing the server's fingerprint with the trusted fingerprint.
To configure transfer server authentication, open the transfer server's aspera.conf file:
Locate the <server> section, and add the <ssh_host_key_fingerprint> or the <ssh_host_key_path> option.
Use this option to specify the fingerprint itself:
To retrieve the SSH fingerprint, locate the transfers server's public or private key, and run the following command on a Linux, Mac, Isilon, or other UNIX computer:
# cd /etc/ssh # cat ssh_host_rsa_key.pub | cut -d' ' -f2 | base64 -d | sha1sum | cut -d' ' -f1
The following is an example SSH fingerprint:
By convention, Aspera uses a hex string without the colons ( : ""). For example:
The aspera.conf setting for this key would then be as follows:
Use the key-path option to specify the transfer server's public or private key file and its location. The fingerprint is extracted automatically.
On most Linux systems, the SSH keys are located in /etc/ssh. On OSX, the SSH keys are located in /etc. The following example uses a Linux server's public RSA key:
After modifying aspera.conf, be sure to restart the node service by running asperanoded:
# /etc/init.d/asperanoded restart