How to secure your Linux VPS – SSH hardening
When a new Linux based vpsie is deployed, it will have default SSH configuration file. This means that SSH server listens on TCP port 22 and accepts password based authentication.
In order to find systems with SSH port open in the internet, attackers send a TCP SYN packet to a broad range of IP addresses. The IP addresses returning a SYN+ACK packet are kept in a list of server to further brute force a username + password pair.
There are few simple measures to remove your self from the herd, by changing the openssh config file.
Here they are:
First, if you are able to connect to higher TCP ports from your internet connection(s) to destinations in the internet, especially your VPS server, then first change the SSH listen port to a higher one. !!! Note that this step has to be done only after you’ve made sure you can access your VPSie via the web console to avoid locking your self out !!!
As stated previously, attackers send a TCP SYN packet to destination port 22 to a broad range of IPs. Your server would not reply if SSH listens to other port.
In order to acomplish this, locate sshd_config (on both CentOS and Debian, it is located under “/etc/ssh” directory), edit it and change or uncomment the “ListenAddress” directive to something like “ListenAddress 0.0.0.0:10022”.
A little more about this directive. In Unix and Linux networking terms, the 32bytes all zero “0.0.0.0” address refers to all local addresses/all local interfaces. If you know what you’re doing you can either use this or be very specific on what IP address you want your SSH server to listen on. Here is another example to make it listen to a specific IP address “ListenAddress 10.1.1.53:10022”.
Save the configuration file and check:
# lsof -Pni :10022 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME sshd 14035 root 3u IPv4 182063 0t0 TCP 10.1.1.53:10022 (LISTEN)
The above confirms that command “sshd” with process ID 14035, file descriptor number 3u listens on IP 10.1.1.53 and port 10022 (non-standard port for SSH). The socket is IPv4 type.
The above is just an example. You should use the IP assigned on the interface intended to process SSH inbound connections.
A second best practice tool is to disable Pasword Authentication in SSH. This leaves you only the (secure) option to authenticate only using ssh keys.
Creating and implementing ssh keys is not the scope of this article (but o a future one) so I will assume this step has been completed. Here is what needs to be changed in “sshd_config” file:
... RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys ... PasswordAuthentication no ...
First three directives enable RSA authentication and enable the authorized_keys file to hold public keys. When SSH RSA authentication is implemented, remember that the SSH server ALWAYS keeps the public key and the user holds the private key. That’s why it is the user’s responsability to keep it safe and report it’s loss or worse, and the administrator’s responsability to react and remove the public key if the coresponding private key has been compromised.
Now, to confirm the above, I’m going to try to ssh to localhost:
$ ssh localhost ssh: connect to host localhost port 22: Connection refused
Port 22 is not open any more.
$ ssh localhost -p 10022 ssh: connect to host localhost port 10022: Connection refused
Port 10022 isn’t working also. Why ? Because SSH listens to specific IP address:
$ ssh 10.1.1.53 -p 10022 Permission denied (publickey).
Ok. So I can’t login to port 22 any more and I can’t login using passwords.
Future article will describe details on how to use ssh key pair for ssh authentication.
You can actually try those security VPS hardening steps on our platform in few minutes utilizing our PCS (Private Cloud Solution) which allows you to have VPSie(s) on a private network – NAT – Port forward – traffic control for inbound and outbound – multiple gateway IPs which you could use for the load-balancing and failover.