Introduction
Keeping your data secure it critically important. Aspera strongly encourages you to take additional steps in setting up and configuring your SSH server so that it is protected against common attacks. Most automated robots will try to log into your SSH server on Port 22 as Administrator, 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 take in securing 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.
Please note that for Aspera Enterprise or Connect Server version 2.6, your transfer product ships with OpenSSH listening on TCP/22. For Aspera Enterprise or Connect Server 2.7, your transfer product ships with OpenSSH listening on both TCP/22 and TCP/33001. For both versions, Aspera recommends disabling TCP/22 and only exposing TCP/33001 or another non-default port.
IMPORTANT NOTE: You need Administrator access privileges to perform the steps below.
-
Locate and open your system's SSH configuration file
Open your SSH configuration file with a text editor. You will find this file in the following system location:
OS Version |
Path |
32-bit Windows |
C:\Program Files\Aspera\Enterprise Server\etc\sshd_config |
64-bit Windows |
C:\Program Files (x86)\Aspera\Enterprise Server\etc\sshd_config |
-
Add new SSH port
IMPORTANT NOTE: Before changing the default port for SSH connections, please verify with your network administrators that TCP/33001 is open.
The OpenSSH suite included in the Enterprise Server installer uses TCP/22 and TCP/33001 as the default ports for SSH connections. Aspera recommends disabling TCP/22 to prevent security breaches of your SSH server.
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
...
-
Disable non-admin SSH tunneling
IMPORTANT NOTE: The instructions below assume that OpenSSH 4.4 or newer is installed on your system. For OpenSSH 4.4 and newer versions, the "Match" directive allows some configuration options to be selectively overridden if specific criteria (based on user, group, hostname and/or address) are met. If you are running an OpenSSH version older than 4.4, the "Match" directive will not be available and Aspera recommends updating to the latest version.
In OpenSSH versions 4.4 and newer, disable SSH tunneling to avoid potential attacks; thereby only allowing tunneling from Administrator group users. To disable non-admin SSH tunneling, add the following lines at the end of the sshd_config file:
...
AllowTcpForwarding no
Match Group Administrators
AllowTcpForwarding yes
Depending on your sshd_config file, you may have additional instances of "AllowTCPForwarding" that are set to the default "Yes." Please review your sshd_config file for other instances and disable as appropriate.
-
Update authentication methods
Public key authentication can prevent brute force SSH attacks if all password-based authentication methods are disabled. Thus, Aspera recommends disabling password authentication in the sshd_config file and enabling private/public key authentication. To do so, add or uncomment PubkeyAuthentication yes in the sshd_config file and comment out PasswordAuthentication yes.
...
PubkeyAuthentication yes
#PasswordAuthentication yes
PasswordAuthentication no
...
-
Restart the SSH server to apply new settings
When you have finished updating your SSH server configuration, you must restart the server to apply your new settings. Restarting your SSH server will not impact currently connected users. To restart your SSH Server, go to . Locate the OpenSSH Service and click Restart.
-
Review your user and file permissions
Permissions determine who can access certain files within your system,
thereby making it a critical component of securing your server. By default,
all user accounts are allowed to browse and read all files in the
server.
To limit the user's access to a portion of the system, set
a document root for the user. The Docroot configuration options can
be found in your Aspera products's Configuration menu, within the
Global, Groups and Users sections.
The following is a list of your Aspera product's Docroot configuration
options:
# |
Field |
Description |
Values |
Default |
1 |
Absolute Path |
The Absolute Path describes the area of the file system that
is accessible by Aspera users. The default empty value gives users
access to the entire file system. |
file path |
blank |
2 |
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. |
|
blank |
3 |
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. |
|
blank |
4 |
Browse Allowed |
Setting this to true allows users to browse the
directory. |
|
blank |
-
Review your logs periodically for attacks
Aspera recommends reviewing your SSH log periodically for signs of a potential attack. Launch . To see only SSH Server events, select to bring up the filter settings. In Application Properties's Filter tab, select sshd in the Event source menu to display only SSH Server events. You may also apply other conditions when needed.
With filter applied, you can review the logs in the Event Viewer main window, or select to export a log file using .txt or .csv format.
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[1496]: Failed password for invalid user alex from 1.2.3.4 port 1585 ssh2
...
Mar 14 23:25:52 sku sshd[1496]: Failed password for invalid user alice from 1.2.3.4 port 1585 ssh2
...
If you have identified attacks:
- Double-check the SSH security settings in this topic.
- Report attacker to your ISP's abuse email (e.g. abuse@your-isp).