Operating and managing a remote server located in a data centre is often carried out by using a secure network connection provided by the SSH protocol. The necessary registration on the server is preceded by an authentication process. Usually this occurs in the form of the username and password. Alternative methods such as the public key authentication used by SSH, do have their advantages. But...
To enjoy maximum freedom of configuration, the best solution is to host your own server. Another good alternative is to use Dedicated Root Servers, which can be rented by many hosts and grant access to the root account. The basic administrative steps such as installation, structuring, and maintenance of the server remain within the tenant’s sphere of responsibility, as would be the case with a self-hosted variant. This type of server package usually only takes care of the initial installation of the operating system, if needed.
Regardless of the chosen hosting solution, you should be careful and responsible when designing and using the root account. In particular, the issue of security plays an important role here: On the one hand, a faulty procedure in the root area is particularly difficult, on the other hand, a concrete basis for a stable, high-performance and secure server can be created if the procedure is correct. For example, in order to secure a dedicated server and protect it against external access, a mandatory password change is just one of the many necessary measures to increase server security.
- Minimal installation and a secure password
- Change the SSH ports
- Disable the SSH login for Root users
- E-mail notification for SSH log-ins
- Disabling unused ports
- Regular software updates
- Securing Windows and Linux servers against brute force attacks
- Configuring a server securely: Set monitoring tools from the beginning
- Trust is good, backups are better
Minimal installation and a secure password
Even before you start with the actual precautions and configure your server safely, you can influence the future security potential of your web project. Regardless of whether you choose a Windows or a Linux system, the following principle applies to the installation: A server should only contain the software it needs to perform its tasks. The reason for this is that any installed application is a potential security risk and can have a negative impact on performance. To offer attackers as little as possible, you should only install or activate the necessary system components, and only access verified third-party software.
After the installation, you should first set a root password (Linux systems). As standard, there is no value defined and the administrator account is also blocked until you make a corresponding entry. After installation, the operating system usually automatically prompts you to create a user account, including a password, which is the root access point. If you rented a server from a provider and received an existing root log-in, you must change the password. To do this, you must log into your server via SSH (from a Linux system) or PuTTY (from a Windows system) and enter the following command in the proper terminal for a root log-in to change the password:
You can then specify your password, which then requires verification. Be sure to choose the longest possible password, not just letters but also special characters and numbers. In addition, it is recommended to use a password manager to save the password, so that you can access it at any time. Then, try to connect to the new root log-in. If it’s done correctly, you can disconnect the SSH connection made at the beginning.
If your system already has a root password that you do not know, you can change it in recovery mode. Recovery mode can be accessed by holding down the Shift key during the boot process. Select ‘root’ from the Item Menu, then you can automatically operate as an administrator and make the desired password change.
Change the SSH ports
For server access via SSH, port 22 is provided by default. It is automatically entered when you reinstall your system. Criminals who are looking for cracks in the system will primarily run their attack attempts (mostly automated log-in attempts) on this port. By simply picking a different port for encrypted remote connections, you minimise the risk of unwanted access. To do this, all you have to do is open the SSH configuration file sshd_config with the text editor of your choice. The following code example calls the file with the Linux standard editor nano:
Look for the appropriate line and replace port number 22 with a number of choice. However, keep in mind that there are several other default ports for other services (for example, port 80 for HTTP) that you should not use if possible. First, take a look at the list of standardised ports which is managed by the IANA (Internet Assigned Numbers Authority) and can be viewed on its official homepage.
Alternatively, you can view the listing in the /etc/ services file.
Before the changes in sshd_config become active, it is necessary to restart the SSH service. On Debian, this is done with the /etc/init.d/ssh restart command. If you are an Ubuntu user, restart the service by using ‘service ssh restart.’
Disable the SSH login for Root users
To secure your server, it is also recommended to disable the direct SSH log-in for the root account. If not, an attacker who possesses the password could use the remote account to remotely access the server, and block the SSH direct log-in for the root account. Before you can perform this action, you must have at least one additional user account that can be connected to the server, in addition to the root user, and which is not completely excluded from the system. If you have not made a corresponding user profile, use the following command to create it:
useradd -g users -d /home/nutzer1 -m -s /bin/bash user1
With this, you can create the user account user1, which is also added to the users group (-g). As well as that, the home directory/home/user1 is assigned to this user profile (-d). The command specifies the bash shell as the default shell (-s /bin/bash). Finally, define a secure password for this new log-in account:
Now, test whether the login works with the created user account and only proceed with the actual project (locking yourself out of the root account) if you are successful. For this, you need the SSH configuration sshd_config, which you can open with your preferred editor. Look for the ‘PermitRootLogin yes’ entry and replace it with ‘PermitRootLogin no’. After restarting the SSH service via command line:
/etc/init.d/ssh restart (alternativ: service ssh restart)
Remote access of the root account is no longer possible. You simply log in with the user profile(s) you have created, and change to the root account at any time (after logging in), if you need it again.
You can also use the AllowGroups line in the configuration file to determine which users are allowed to connect to the server via SSH. To do this, simply create a group (addgroup) and add the desired users (adduser). Then add the selected group name to the sshd_config (e. g. AllowGroupsssh_user).
A convenient alternative to blocking the root log-in is the option to completely ban user log-ins with a password and instead use public key authentication with SSH-Keys.
E-mail notification for SSH log-ins
However, in the event of SSH access to your server, you should keep an eye on all remote activities. This allows you to determine if you have secured the SSH service on your server properly. Additionally, monitoring these activities means that you are warned at an early stage by a good monitoring of the established connections in case of unauthorised access and can take appropriate countermeasures. A simple shell script is sufficient for this, which automatically sends a notification email to your address on every successful remote login on your server.
A corresponding script (here: /opt/shell-login.sh), which you can easily create yourself, must contain the following code for this purpose:
#!/bin/bash echo "Log in to $(hostname) on $(date +%Y-%m-%d) at $(date +%H:%M)" echo "User: $USER" echo finger
Then add the following line to the /etc/profile profile file:
/opt/shell-login.sh | mailx -s "SSH-Log-in to YOUR-HOSTNAME" firstname.lastname@example.org
This entry can ensure that the script is executed and, in the event of a successful log-in, it sends a notification mail to the desired address. The prerequisite is that the script is assigned the right 755, which can be done with the following command:
chmod 755 /opt/shell-login.sh
If a user establishes an SSH connection using a program such as WinSCP which does not perform a complete log-in, the shell script described here does not send an e-mail!
Disabling unused ports
Open ports generally are not a serious safety risk. Because they are needed to communicate with the individual services and applications, it is important that certain ports are enabled by default, like ports 80 and 443 for HTTP or HTTPS connections, or the SSH port of your choosing. If you have been able to implement a minimal system installation and access a small number of third party applications, the number of other required ports in manageable. The risk is that these open interfaces will only be used if the responding programs have security gaps and criminals are taking advantage of this fact. The danger of this kind of potential attack is growing due to the increasing number of applications being used.
To that end, it is useful to secure your server against these kind of attacks by blocking all unused open ports. Nearly all common operating systems have already installed the appropriate tool by default with the packet filter software iptablesiptables tutorial – rule sets for creating data packets. You can use the tool to create fixed rules for traffic regulation, including the definition of desired or undesirable ports. A small introduction to the filter program, including instructions for setting up a rudimentary firewall for your system, can be found in our Tutorial on this topic.
Regular software updates
In general, there is no software that is completely free of the vulnerabilities mentioned in the previous section. However, cybercriminals would first have to discover the exploitable mis-programming before they can take up the attack. As a rule, known vulnerabilities are quickly closed again by published updates. If you keep on top of updates to the operating system and the installed programs, and update as soon as possible, you are ensuring the best possible protection for your server. Nearly all server systems also allow you to download and install important security updates automatically in the background.
For example, if you want to secure a Windows server that receives automatic updates, you can set specific instructions for the update process in the Windows Update area. In this way, you can configure when and how regularly to check for updates, whether you want updates to be installed, and when the system should reboot. There are specific scripts such as apt-listchanges or apticron for Linux systems, which inform you daily about new available software packages and allow you to download them. Other scripts, such as unattended upgrades, will then download the automatic installation.
Ensure that you have an amended update process that keeps you up-to-date with updates. This allows you to better understand and correct errors that occur as a result of the update process.
Securing Windows and Linux servers against brute force attacks
Hackers, who want to access your server or the applications running on them, have different options to do this. One of the simplest and most frequently used types of attack is the so-called brute-force method. The attacker tries to access passwords using a tool that attempts to log in one at a time. However, the more care you put into assigning your password, the less likely this method will be to succeed. Do keep in mind that, particularly if you are offering a service with a registration option, you must assume that not every user will be as conscientious and cautious as needed.
There is of course, no need for complex, expensive software to protect against such attacks. Since every log-in attempt is registered, answered, and recorded in log files, simple analysis tools can help.
Fail2ban (Linux-/POSIX-Systems) or RdpGuard (Windows) check the relevant log files, detect unusual behavior, and block the IP address of suspicious users.
You can also go a step further and set up a two-factor authentication for establishing the connection to your server to additionally secure the log-in. This method requires the user’s personal possession (e.g. smartphone, smartcard, TAN list) as an extra component to the logging-in process, as well as the password input.
Configuring a server securely: Set monitoring tools from the beginning
If you want to secure a server, the previously listed measures against external adversities are extremely important. However, it is equally important to ensure that the interaction between hardware and software runs as desired. This is not a one-off check, completed after successfully creating your server environment; this is a long-term task that you should never lose sight of. With the high number of different processes, this is easier said than done, which is why you should have access to help tools from the beginning. These help monitor all the operations on your server and alert any incidents.
An easy program of this kind that is quick to configure is Monit, which can be installed easily on many Linux distributions via the package administrator. The open source application (GNU-AGPL license) selectively monitors processes, files, clouds, hosts, programs, or scripts after starting. The system resources – CPU, memory, and absolute system utilisation – can also be monitored. In the Monit configuration file, you can select which values or events generate a notification via e-mail. If you require more information, the monitoring software Nagios is recommended. It is somewhat more complex, but the core version is open source, and can be expanded using diverse plugins. A virtual machine can also allow it to be run on a Windows platform.
Trust is good, backups are better
With the recommended configuration suggestions, server security significantly increases. The various settings for the login process and the restriction of the root account give your server a very high security standard, in conjunction with continuous updates, monitoring tools, and mandatory security software. However, even the best configuration and dedicated care cannot provide one hundred percent protection for the server. Program errors, hardware failures, or personal negligence can lead to data being lost in the worst case. A further supporting pillar of your security system should be the appropriate backup strategy that allows you to restore the appropriate files in such a case.
There is no lack of powerful tools that can support you not only when creating, but also when importing a backup copy. A free application which should be mentioned here is the synchronisation program rsync, which takes its name from the same protocol and is available in various forms for almost all common platforms (macOS, Windows, Linux). This tool keeps a copy of your server data up-to-date by noting all changes to the original in real time. As well as a general backup of the server, the program also automatically protects the database.
For the most secure backup protection, it is recommended that the backup directory is located on an external storage medium (portable hard disk, another server, etc.) and not on the server you want to back up.