Let's Encrypt SSL-certificaat wordt GRATIS geleverd in al onze webhostingpakketten.
DetailLet's Encrypt SSL-certificaat wordt GRATIS geleverd in al onze webhostingpakketten.
DetailJust because you don’t have anything of value on your server, doesn’t mean that malicious actors won’t target it. You may be thinking that since your server isn’t even running a website, let alone store customer data, you don’t need to take security seriously.
Nothing could be farther from the truth. Cybercriminals today prefer going after the low hanging fruit. They constantly scan for servers with potentially weak security. Once they identify such a target, they can usually execute a brute-force attack to infiltrate it.
As the owner of a public-facing server, the onus of security rests on your shoulders. Most of our servers are unmanaged, which means that securing the server is your responsibility. In the following guide, we will share tips and insights on how you can start securing your server today.
Server security includes the processes and tools used to protect a server from unauthorised access. Severs are prime targets for attackers because they lie at the heart of an organizational network. They also often contain sensitive data, like PII, application logs, or source code.
If you’ve hosted a website, it’s running on a server. If you’ve purchased some storage space from a cloud provider, it’s running on a server. If you’re about to build your company’s infrastructure online, you’ll probably need a lot of servers, and subsequently proper cloud server security.
The point is, most service delivery on the internet happens through servers, which makes it imperative that we secure them. This is especially true for Linux servers, because people often assume that they are inherently secure.
While it’s true that Linux offers much more ways to secure servers than its counterparts, the security isn’t built in. Administrators must explicitly perform security measures to secure Linux servers. The absence of security often indicates to an attacker that the server administrator is possibly inexperienced and hence, an easy target.
Did you know that billions of cyberattack requests originate each day? Take a look at this live threat attack map. What you need to understand is that hackers don’t sit on their computers with their morning coffee deciding who to target for the day, they wouldn’t be very successful then.
Instead, they create millions of bots that constantly automatically scan all public IP addresses on the internet, every second of every day. In fact, any new device that starts up with a public IP on the internet is scanned for weaknesses within 30 to 60 SECONDS of it going live. Yes, that was not a typo, it’s a scary fact.
That means before you’ve even logged into your server for the first time, there have already been thousands of break-in attempts on it. We often see in excess of 10,000 failed login attempts PER DAY on some of our client machines before they get locked down.
Cybercriminals target all types of servers. Enterprise servers, shared hosting servers, AWS instances, and even your personal server with no meaningful data on it. They randomly send out requests across the internet, hoping for any form of response.
Usually, if a server responds, it indicates weak security. This is the attacker’s cue to launch a brute-force attack, i.e. make thousands of attempts to guess the server’s username-password combo. Once they gain entry, they use the server as a staging point to launch their campaigns.
These may be junk-mail/spam floods or Denial of Service (DoS) attacks. Running botnets or Malware responders, or setting up Phishing sites. They could even set up bitcoin mining applications that run in the background, and consume all your server’s resources.
So, not only will any sensitive data be exposed forever, your server will also become an anonymous staging point for criminal activity, which would be virtually impossible to trace back to the original attackers.
Are you taking cyber security seriously? Let’s look at some more reasons why it should always be your top-most priority:
One of the advantages of using Linux is that it offers so many easy-to-use features to secure a server. Let’s look at how do you go about securing a server:
SSH, or secure shell, is a protocol used to authenticate and communicate with servers. There are multiple ways to use SSH to log in to a server. The easiest method is using password-based authentication, but it’s not considered secure.
A much safer alternative is using SSH key pairs. An SSH key pair consists of cryptographically secure keys, which ensure that only authorized clients, with the right keys, get to access the server. Each pair consists of a public key, which is configured at the server, and a private key, which is secretively stored by the client.
To create a SSH pair, follow these steps:
ssh-keygen
.That’s it! This should create public and private key files in the user home directory (/home/~/.ssh
). For root the default folder is /root/.ssh/id_rsa
.
The files will typically be called id_rsa.pub
and id_rsa
. The .pub
file is the public key. This can be copied into ~/.ssh/authorized_keys
to allow any holder of both keys to access the server, WITHOUT a password. The advantage of this is that removing the key also removes access.
It’s recommended to disable password authentication on your server, and always use SSH keys to log in. Here’s how to do so:
/etc/ssh/sshd_config
in your favourite editor.#PasswordAuthentication no
, then remove the #
from the beginning, and change yes
to no
sudo systemctl restart sshd
sudo systemctl restart ssh
sudo systemctl restart ssh
The /etc/hosts.allow
and /etc/hosts.deny
files give users the ability to define rules that only allow access to trusted clients. Once you create the files and add entries to them, the network daemon will consult them every time it gets a new request.
As the name indicates, allowed clients should be defined in the /etc/hosts.allow
file, and if there are any blacklisted clients, they should be defined in the /etc/hosts.deny
file. As a standard practice, you should reject all access by default, and only allow approved, known hosts. Here’s how to configure this:
/etc/hosts.deny
file and put the following line inside it:ALL: ALL
/etc/hosts.allow
and specify a list of known hosts. For example:ALL: LOCAL @test_netgroup
The above rule will only allow access from ALL hosts inside the local domain, and ALL members of the test_netgroup
netgroup.
Once you have all your software installed and running, make sure you have researched which ports each application runs on. Run the command netstat -punta
to see which ports and applications are running.
Ensure that each open port is actually needed by the system or your application.
Ignore any ports running on the IP address 127.0.0.1, as this is an internal IP. Focus on ports running on IP 0.0.0.0 (Any IP) or the PUBLIC IP of your server. Shut down any-and-all applications that are not absolutely necessary.
The Fail2Ban SSH Module checks your log files for failed login attempts (for SSH). After a predefined number of failed login attempts, it blocks the IP address of the client trying to log in.
However, you should only install this if you do NOT have cPanel installed. cPanel uses CSF/LFD (Login Failure Daemon) to essentially do the same as fail2ban. In Ubuntu, fail2ban is usually activated by default for SSH. On CentOS, you usually have to activate it.
However, if for some reason fail2ban isn’t installed/enabled on your system, follow these steps to do so:
On CentOS 7/8:
sudo yum install epel-release
sudo yum install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
On Ubuntu 20 and Debian 11:
sudo apt update
sudo apt install fail2ban
Permissions are often misunderstood and overrated as a security measure. Setting the correct permissions can keep a rogue application in check, or minimise the damage caused by a compromised account.
Set User
and Group
permissions on files AND directories, with no global permissions. If global permissions can’t be avoided, only use read-only.
sudo
gives a user the ability to execute commands on other accounts, including root
. Ensure that only authorised accounts have the permission to use sudo
. To do this, you will need to create a sudousers
group, and add all the required users to it:
sudo groupadd sudousers
sudo usermod -a -G sudousers myuser1
sudo usermod -a -G sudousers myuser2
sudo
rights.sudoers
file, let’s create a backup:sudo cp --archive /etc/sudoers /etc/sudoers-bak
sudoers
file: sudo visudo
%sudousers ALL=(ALL:ALL) ALL
It’s imperative to install critical security updates on your server, as soon as they are released. Most-if-not-all security updates are patches for known vulnerabilities and bugs, which can be exploited by malicious actors.
Ideally, you should be able to automatically install security updates from the official vendors. It may not be prudent to install ALL updates, as some may break the operating system. However, critical security updates shouldn’t be avoided or delayed at any cost.
Debian and Ubuntu both have built-in features that support automatic security update installation. We recommend enabling it. For CentOS, you can use the package DNF Automatic to set up automatic updates.
Let’s finish this section off by looking at some security tools for Linux, across different categories:
Our favourite antivirus / anti-malware software for Linux is Sourcefire’s ClamAV. This is a free, open-source package designed to detect trojans, viruses, malware and other malicious threats. Included in the software are a multi-threaded scanning daemon, command line utilities for on-demand file scanning, and an intelligent tool for automatic signature updates.
Snort is a free, open-source tool that helps in the detection of intruders and also highlights malicious attacks against the system. In effect, Snort is merely a packet filter. But the true value of this tool lies in its signature-based detection of attacks, by analysing packets that Wireshark or tcpdump are incapable of analysing.
Canarytokens provide an early warning system, by mimicking devices, files or URLs that are attractive to attackers snooping around your system, and when engaged with you are automatically alerted.
NIKTO is an open-source web server scanner that tests web servers for potentially dangerous CGI files. It also performs version-specific analysis, such as identifying outdated frameworks. One must note that every test or check report doesn’t necessarily point to a security problem, so keep an eye out for false positives.
Chkrootkit is a free tool designed to check locally for signs of a rootkit infection on your Linux machine. The free software is a very popular choice, but Rootkit Hunter (rkhunter) is another, like-minded alternative.
Both these programs check your disk for any known malware and insecure setups. They can also optionally run on a schedule to warn you about any changes to specified directories or files. Another good program to watch your files for changes is Tripwire.
Last but not least, a good firewall can do a lot. If you do not want to learn iptables, the de-facto standard Linux firewall, you can manipulate it through various simplified front-ends. These include firewalld (CentOs 7 and later), CSF and UFW (more common on Debian variants such as Ubuntu).
We hope that by showing you how to secure a Linux server, we’ve made the internet a little more secure. These basic security tips help you lay a secure foundation, but it’s only a start. Server security is not a set-and-forget configuration, it takes constant work and updating.
Cybercriminals and their millions of automated bots don’t sleep. It’s up to you to advance and maintain your server security 24/7.
If you don’t have that kind of time, energy, or skills, then a managed server would would be the solution for you.
Stay informed on the latest security threats and news from reputable sites like The Hacker News and ZDNet. You can subscribe to their security newsletters or simply follow them on your preferred social media platform to get alerts and keep your systems SAFE.
Happy Hosting ????