General instructions
To ensure the necessary system security settings, it is recommended to perform the following steps:
Disable root access to the server
Unlike other Linux distributions, the root account is disabled in Ubuntu by default. If root is still enabled, disable it with the command:
sudo passwd -l root
Enable SSH key access only
In /etc/ssh/sshd_config:
PasswordAuthentication no ChallengeResponseAuthentication no
Use secure rsa -b 4096 keys
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key sudo ssh-keygen -o -a 100 -t ed25519 -f /etc/ssh/ssh_host_ed25519_key
Automatic password generation for SIP usersit is recommended
The ECSS-10 system has the ability to generate passwords that meet the recommended security requirements when creating SIP subscribers.
Example of subscriber declaration:
admin@mycelium1@ecss1:/$ domain/biysk.local/sip/user/declare ctx_from_local loc.gr 240800 alias-as-user qop_authentication common_login sip3854240800 auto-generation Executed on the sip1@ecss1 Intermediate (incomplete) result: Declaration for range: 240800@biysk.local..240800@biysk.local (1) ... 1 interfaces check for existing ... [**********************************************************************] 50mks 1 users interfaces declaration ... [**********************************************************************] 5ms 1 users aliases declaration ... [**********************************************************************] 29ms 322 interfaces recall to base [**********************************************************************] 109ms Executed on the sip1@ecss1 ┌────────────────────────┐ │ declared 1 subscribers │ └────────────────────────┘ [exec at: 23.01.2020 22:53:18, exec time: 534ms, nodes: sip1@ecss1]
View credentials:
admin@mycelium1@ecss1:/$ domain/biysk.local/sip/user/info loc.gr 240800@biysk.local 1 make users list ... [**********************************************************************] 19mks 1 users information read ... [**********************************************************************] 14ms Executed on the sip1@ecss1 ┌─────────────────────┬─────────────────────────────────────────────┐ │ User │ 240800@biysk.local │ ├─────────────────────┼─────────────────────────────────────────────┤ │internal iface name │062bc20adc06e101 │ │isActive │false │ │group │loc.gr │ │authentication │sip3854240800:uc7cXcnuyunu (ds) use qop: true│ ...
Change passwords to secure
After installing the ECSS, the admin user with the standard password password is automatically created by default to access CLI and web configurator.
Create a new user with system administrator rights, whose username and password exclude the possibility of brute force attack. It is recommended to use at least 8 characters, including lowercase and uppercase letters of the Latin alphabet, as well as numbers and special characters. You can use the standard Linux utility — pwgen. After that, delete the admin user.
There are similar requirements for a mysql user with root rights (set when installing the ecss-mysql package). If necessary, the password can be changed by reconfiguring the package:
sudo dpkg-reconfigure ecss-mysql
Use SBC, configure firewall, ACL
It is recommended to configure your firewall so that Restfs is accessible only from the server itself and is not accessible externally.
If the server or SBC has direct access to the Internet or a corporate network, where various attempts of unauthorized requests or DDoS attacks are possible, configure a list of allowed IP or subnets from which access to certain ports is allowed. For the rest, access should be prohibited. If the complex has SBC, then it has already implemented the necessary functionality to protect against external attacks — a dynamic firewall with a mechanism for recognizing attacks and unauthorized access attempts. In SBC, you can also configure black/white lists of subnets for both management and SIP access.
Update Ubuntu and server utilities when a security pack is released
It is recommended to perform periodic system updates, especially when releasing fresh versions of packages that improve security functionality.
Configuring OpenSSH Security
The openssh-client openssh-server packages or the ssh meta-package including the client and server must be installed on the ECSS servers.
Configuring SSH server and client
OpenSSH server configuration is described in the /etc/ssh/sshd_config file. For more complete security, change some of the default settings.
In the Ubuntu-18.04 LTS repository, the current version is OpenSSH_7.6p1. The following configuration recommendations are for versions starting from 7.6.
In OpenSSH 7.0 and older, SSH 1.0 protocol support is disabled by default at compile time. Similarly, support for 1024-bit diffie-hellman-group1-sha1 keys, ssh-dss, ssh-dss-cert-* hosts and user keys is no longer activated during compilation by default. The v00 certificate format is not supported, and the PermitRootLogin option has changed the default value from yes to prohibit-password.
Key Exchange
To use only trustworthy key exchange protocols in /etc/ssh/sshd_config for the server, specify:
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Similar settings for the client, in /etc/ssh/ssh_config:
Host *
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha25
Authentication
SSH supports four public key authentication algorithms: DSA, ECDSA, Ed25519 and RSA.
ECDSA is tied to NIST technologies and should be disabled. Since the size of the DSA keys cannot exceed 1024 bits, it should also be disabled. Therefore, it is recommended to delete all keys:
cd /etc/ssh rm ssh_host_*key*
Next, generate a larger RSA key, and also add the ed25519 key:
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key sudo ssh-keygen -o -a 100 -t ed25519 -f /etc/ssh/ssh_host_ed25519_key
Symmetric ciphers
Of the 15 symmetric encryption algorithms supported in SSH to organize the protection of the established communication channel, chacha20-poly1305, aes*-ctr and aes*-gcm can be considered secure. The 3des-cbc and arcfour ciphers are potentially vulnerable due to the use of DES and RC4, and cast128-cbc uses too short block size (64 bits).
Therefore, it is recommended to add to /etc/ssh/sshd_config:
Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
In /etc/ssh/sshd_config:
Host *
Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
Message Authenticity Code (MAC)
For ciphers in CTR mode, to guarantee the integrity of the transmitted blocks, only the Encrypt-then-MAC method is trusted ("*-etm", MAC is added to the already encrypted block). The MAC-then-encrypt and Encrypt-and-MAC methods are potentially susceptible to attacks. Of the 18 MAC algorithms available in SSH, you should immediately discard those based on MD5 and SHA1 hashes that are not resistant to detecting collisions, as well as algorithms using key sizes less than 128 bits and tag sizes less than 256 bits. As a result, hmac-sha2-512-etm and hmac-sha2-256-etm can be considered the most secure MACs.
In /etc/ssh/sshd_config:
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
In /etc/ssh/sshd_config:
Host * MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
Key leak protection
The easiest way to gain control over SSH connection is to capture keys on the client or server side. The recommendations are reduced to following the standard rules for maintaining system security:
- prompt installation of updates, installation of programs only from reliable sources;
- installation of only really necessary programs and services;
- using programs for which source texts are available, enabling additional protection mechanisms (Grsecurity, assembly with the -fstack-protector flag).
To protect the keys, choose a strong password to access the client key files. When generating a key to increase the number of hashing iterations, you can use the option "ssh-keygen -o -a number", which will complicate the selection of a password. You can also save the keys only on external media, connecting it only during an SSH connection.
User Restriction
Addi the AllowUsers parameter, which is not in the default configuration file. This parameter allows SSH access to the server only for the listed users.
In /etc/ssh/sshd_config:
AllowUsers dmitry support
Limiting interfaces
These strings are for configuring distinctions by network interfaces, network address or computer name. By default, the server "listens" (accepts connections) on all network interfaces. If you need to leave the connection only through certain interfaces, then uncomment the line:
ListenAddress 192.168.1.21 ListenAddress 10.16.33.5
In the same string, you can explicitly specify the port by first commenting (putting the # symbol at the beginning of the line):
#ListenAddress 0.0.0.0
Changing the port
If there is a possibility of brute force attack attempts (for example, a server on a public network), you can change the port to another one.
Port 22025
By default, port 22 is used. Change it to a non-standard port 22025 — this will spare the server from network robots that automatically scan the Internet in search of open ports and try to connect through them. Basically, bots are configured to search for standard ports. This will not spare from human scanning, but for protection against humans there are a firewall, clever ways to open a port, etc.
Sample listing of the resulting configuration files:
You can check the syntax of the configuration file with the command:
sshd -t
View the current server settings:
sshd -T