Server security is a major issue for companies. Indeed, being a central element in the functioning of all the components of an information system (applications, network, infrastructure, employees, etc.), servers are often the prime targets of attacks.
Furthermore, server-side vulnerabilities can have severe consequences. In the event of misconfiguration or lack of control, these flaws can be exploited and lead to the compromise of the data in transit, or even to the server being taken over by malicious persons.
Why is server security important?
Attacks on servers are a daily occurrence because, very often, too many loopholes exist. Indeed, applications vulnerable to SQL injections hosted on a server, users unaware of social engineering risks, or simply poor practices in terms of updates and patch management of the operating system and server services, easily allow attackers to achieve their goals: data theft, access to sensitive information, paralysis of a company’s activity, etc.
Securing a server is therefore vital and necessarily involves implementing best practices in terms of configuration, control, monitoring and security testing.
This article is not intended to be exhaustive. It will only address server security from a best practice perspective, with some additional information on the risks, types of attacks and vulnerabilities that can be exploited by attackers to compromise a server.
Update and patch management policy, hardening, access and administration control and security (via SSH), best logging and monitoring practices, etc., we present here the main measures to strengthen the security of your servers.
Implement an update and patch management policy for servers
Implementing an update management policy for operating systems and services is essential to maintain a good level of security. Indeed, new vulnerabilities are discovered and published regularly. And if security patches are not applied in time, the risk of attacks and server compromise increases.
The numerous attacks suffered by companies, via malware, following the publication of a patch for a protocol, software, operating system, etc., must push any type of organisation to adopt a proactive posture, especially as information on vulnerabilities and exploits is published and therefore accessible to internal and external attackers.
It is also true that caution is recommended when it comes to installing software updates, as testing is always necessary, if not essential. However, it is generally unwise because it is riskier to delay this process, as a passive attitude very often leads to the compromise of information systems.
It is therefore important to define and implement an update and patch management policy or servers and all software and hardware components of the IS. This involves documenting procedures and continuous monitoring of the various patch releases or new versions.
Disable or remove unnecessary services
All software and components installed on an operating system increase the attack surface and therefore the risk of compromise. However, strengthening server security requires reducing the attack surface. To do this, it is necessary to disable or even remove (as far as possible) all services, applications, network protocols, third-party components, etc. that are not essential to the operation of your server.
Removing or disabling unnecessary systems enhances the security of a server in several ways. Firstly, they cannot be compromised, nor can they be used as attack vectors to alter the services that are essential for the server to operate. Indeed, it should be kept in mind that each component added to a server increases the risk of compromising it. Furthermore, the server can be configured to better meet the requirements of a particular service, while improving performance and the overall level of security. Finally, reducing services means limiting the number of log entries, which makes it easier to monitor and detect unusual events.
Controlling and securing server access: Focus on SSH
Presentation of SSH: an essential tool to ensure proper management and secure administration of the server
SSH (Secure Shell) is both a communication protocol and a computer program allowing local and remote administration of a server. Its most common implementation is OpenSSH, which can be found on many systems, including servers (Unix, Linux, Windows) as well as workstations and network equipment.
Indeed, OpenSSH is a suite of tools offering many features, including: a server (sshd), several clients – remote shell connection (ssh) / file transfer and download (scp and sftp), a key generation tool (ssh-keygen), a keychain service (ssh-agent and ssh-add), etc.
SSH currently exists in two versions: SSHv1 and SSHv2. SSHv1 contains vulnerabilities that have been fixed in the second version. Therefore, for enhanced security, only version 2 of the SSH protocol should be authorised.
The most widely used feature of SSH is remote administration, which consists of connecting to a remote machine and launching a shell session following authentication. In this context, the advantage of SSH is its security. Another commonly used feature is the transfer and download of files, both from a client to a server and from a server to a client. For this purpose, SSH offers two mechanisms: SCP and SFTP, which should always be preferred to older protocols such as RCP and FTP.
Public key / certificate authentication
Not ensuring the authenticity of a server can have several security impacts, including the inability to verify that you are communicating with the correct server, with consequent risks of spoofing and exposure to Man in The Middle attacks.
SSH relies on asymmetric encryption for authentication, and thus ensures the legitimacy of the server being contacted before access is granted. Moreover, this control is done in several ways with OpenSSH. Either by ensuring that the public key fingerprint obtained previously with ssh-keygen and presented by the server is the correct one, or by verifying the signature of the certificate presented by the server with a certification authority known to the client.
Recommended algorithms and key sizes
Key quality is an important aspect of server security. There are several algorithms and key sizes that SSH can use. However, not all of them are equal in terms of security.
In practice, it should be noted that the keys used to authenticate an SSH server are often not renewed. It is therefore important to choose sufficiently large keys from the start. However, the DSA implementation in OpenSSH is limited to a key size of 1024 bits, which is insufficient. In fact, the use of DSA keys is not recommended because the minimum key size must be 2048 bits for RSA keys or 256 bits for ECDSA keys.
Access rights and key sharing
SSH authentication keys can be grouped into two categories: those used for user authentication and those for server authentication. And as its name implies, a private key must be secret and protected to prevent its sharing to an unauthorized user. Indeed, it must only be known to the entity seeking to prove its identity to a third party and possibly to a trusted authority.
In addition, the security measures that apply will vary slightly depending on whether the key is a server key or a user key. For example, a server authentication private key should only be readable by the sshd service, while a user authentication private key should only be readable by the user it is associated with. And since there is a real risk of fraudulent use of the private key generated for a user, the storage of this key must be secure, and therefore encrypted.
Choice of symmetric algorithms
Following successful authentication, the communication channel must be protected, i.e., encrypted. The data encryption algorithm should be based on AES 128, AES 192 or AES 256. And to ensure integrity, hash algorithms such as HMAC SHA-1, SHA-256 or SHA-512 should be used.
Since the choice of algorithms is negotiated between the client and the server, the list of algorithms must be fixed on both sides and algorithms considered weak must be removed.
Security of authentication and user access control
Users of a system always have rights, no matter how small. It is therefore important to protect their access via a secure authentication mechanism and to thwart brute force attacks as much as possible.
Firstly, each user must have his or her own account to ensure better traceability and the allocation of access rights must always follow the principle of least privilege. Furthermore, access to a service should be restricted to users who have a justified need and are explicitly authorised.
Regarding users authorised to configure the operating system of servers, they should be limited to a small number of designated administrators.
Furthermore, it is strongly discouraged to use authentication mechanisms in which authentication information is transmitted in the clear over a network, as this information can be intercepted via Man In the Middle attacks and used by an attacker to impersonate an authorised user.
Finally, to ensure secure user authentication, the following measures should be implemented:
- Removing default accounts because the default configuration of the operating system often includes guest accounts, administrator accounts and accounts associated with services. The names and passwords of these accounts are known to attackers.
- Implement a proper password policy. All passwords should be complex and difficult to guess. Above all, they should be long (more than 15 characters). To achieve this, nothing is better than the implementation of a password manager.
Configuring and controlling access to resources
All server operating systems allow you to configure access privileges to files, directories, devices and other resources.
To secure your server, it is essential to carefully define access controls and automatically deny unauthorised access to reduce intentional and unintentional security breaches. For example, denying read access to files and directories helps protect the confidentiality of information, and denying write access can help maintain the integrity of information.
Implement fail2ban to counter brute force attacks
An attacker who wants to gain access to a server has several options to achieve his goal. One of the simplest and most common techniques is the brute force attack. In this case, an attacker uses tools to send a continuous stream of username and password values to test all possible combinations, through a process of trial and error in the hope of guessing correctly
However, the implementation of a good password policy easily renders this attack technique ineffective. Beyond this measure, another essential option must be implemented: the Fail2ban tool. Indeed, an important aspect of server security concerns the recording and management of logs. In this respect, each connection attempt must be recorded and processed in server logs.
Thus, Fail2ban allows to check the logs, to detect unusual behaviour and to block the IP address of suspicious users.
Logging and monitoring of server events
Logging is a central aspect of a security strategy. It is a control mechanism for monitoring the network, systems and servers; and most importantly, it ensures the traceability of all normal and suspicious events. Indeed, log files can be used to track the activities of an attacker and thus detect unusual events or failed or successful intrusion attempts.
To facilitate the management and exploitation of logs, they should be centralised on a dedicated server. This is even more important because, in the event of a machine being compromised, it is likely that the logs will be destroyed or altered by the attacker. Centralising, regularly backing up and duplicating logs will ensure that a copy is always kept. And given their importance, it is essential to restrict access to logs to authorised users only.
For more information on the principle and best practices of logging and monitoring, you can consult our article: Logging and Monitoring: definition and best practices.
Securing APIs, websites and web applications hosted on a server
APIs, websites and web applications hosted on a server must also be secured. These can be used as attack vectors to compromise the server if they are vulnerable to SQL injections for example.
We have discussed the issue of application security at length in a previous article. We invite you to consult it to get an overview of the best practices to implement, in terms of reducing the attack surface, authentication security, protection of sensitive data, etc. How to secure a website or a web application?
And for more information on the flaws inherent in web applications, we refer you to our article: How to strengthen the security of your web applications to counter the most common attacks?
Finally, regarding the specific vulnerabilities of APIs, you can consult our article: How to strengthen the security of your APIs to counter the most common attacks?