One of the first things you should do after deploying a new cloud server is to make sure it will stay secure. Linux offers a multitude of options to help prevent unauthorized access and harden your system. In this how-to guide, you can find some commonly recommended steps in order to protect your cloud server.<\/p>\n\n\n\n

Test hosting on UpCloud!<\/a><\/div>\n<\/div>\n\n\n\n

Encrypt communications<\/h2>\n\n\n\n
When connecting to your cloud server all traffic will pass through the public network, which anyone could be eavesdropping on, unless you take measures to secure your communication. Avoid using any unencrypted transfer protocols such as Telnet and FTP, or anything that would send passwords or other sensitive information as plain text. Instead, you should use SSH (Secure Shell), SCP (Secure Copy), SFTP (SSH File Transfer Protocol) or rsync for all your remote control and file transfer needs.<\/p>\n\n\n\n
The SSH<\/strong> protocol offers a secure encrypted channel over the public network to allow remote login and other network services to operate securely. The most commonly used implementation of this protocol is OpenSSH which is included in most Unix-based operating systems like the majority of Linux distributions and OS X, in a Windows environment the PuTTY SSH client is a popular alternative. Check out\u00a0our article for\u00a0Connecting to Your Server<\/a>\u00a0to learn more.<\/p>\n\n\n\n
Secure Copy<\/strong> or SCP is a built-in feature of OpenSSH which allows simple file transfer over an encrypted network connection. The SCP uses SSH for data transfer and provides the same authentication and level of security as SSH. Below are two examples of a single file copy to and from a remote server.<\/p>\n\n\n\n
# Copy the file \"foo.txt\" from the local host to a remote host\nscp foo.txt <username>@<remotehost>:\/some\/remote\/directory\n# Copy the file \"foo.txt\" from a remote host to the local host\nscp <username>@<remotehost>:foo.txt \/some\/local\/directory<\/pre>\n\n\n\n
SFTP<\/strong> is another command-line utility included in OpenSSH and should be installed on most Unix operating systems by default. Like SCP, it uses SSH to securely transfer files over an insecure network. Windows users can get the same functionality using WinSCP<\/a> (Windows Secure Copy) which as its name suggests implements SCP and\u00a0also SFTP functionality.<\/p>\n\n\n\n
rsync<\/strong> is another utility commonly found on Unix systems. It offers file transfer over encrypted channels to keep the copies of a file on two computers synchronised. The program uses SSH to make the initial connection between the two systems and then invokes rsync on the remote host to determine which parts of the file being synced need to be copied over.<\/p>\n\n\n\n
User account security policies<\/h2>\n\n\n\n
After logging in to your newly deployed cloud server for the first time, creating a new user account for yourself and enabling sudo access control, are some important tasks to start with. Sudo, which stands for \u201csuperuser do,\u201d allows you to perform actions that would otherwise require the root account. This lets you avoid logging in as root on a daily basis, instead, use sudo privileges to execute root-level commands when required.<\/p>\n\n\n\n
Using sudo is considered good practice for security, and it\u2019s usually installed in most Linux distributions by default. To get the most out of what sudo offers, and to set up secure user access, follow our guide for Managing Linux User Account Security<\/a>.<\/p>\n\n\n\n
Monitoring login authentication<\/h2>\n\n\n\n
The reality in today\u2019s internet is that your server security will be tested by malicious parties, sooner rather than later, hoping to find a poorly secured entrance. If your server has been running for even a day, you\u2019ve most likely already had failed login attempts originating from IP addresses other than your own. The majority of Linux distributions keep logs for authentication from the moment they are booted up for the first time. Different systems might store the logs under different\u00a0names, for example with Ubuntu and other Debian-based servers you can view these logs using the following command<\/p>\n\n\n\n
cat \/var\/log\/auth.log | grep 'ssh.Invalid'<\/pre>\n\n\n\n
On CentOS and other Red Hat variants use this instead<\/p>\n\n\n\n
cat \/var\/log\/secure | grep 'ssh.Invalid'<\/pre>\n\n\n\n
The output will list dates and times when invalid login attempts occurred, which user accounts were used, and from which IP addresses the connections came from. Even a large\u00a0number of failed logins is nothing to be frightened about, though it shows how common practice this kind of behaviour is.<\/p>\n\n\n\n
In contrast, check your successful log-in times using the command below.<\/p>\n\n\n\n
last<\/pre>\n\n\n\n
This will print the latest few login times, dates and the IP addresses the connections originated from. If you\u2019ve recently used the web Console at your UpCloud Control Panel, you\u2019ll see those login times marked with tty1<\/em>, other remote control connections such as SSH show pts\/0<\/em> instead, where the number is a connection identifier when you have had multiple SSH sessions open at the same time.<\/p>\n\n\n\n
While your cloud server should still be secure thanks to the Linux default security implementations, you should not rest easy and just hope it stays that way. There are some powerful tools available for reducing failed login attempts and protecting from simple password brute-forcing.<\/p>\n\n\n\n
Fail2ban<\/strong> is one such intrusion prevention framework, which works together with a packet-control system or firewall installed on your server. It is commonly used to block connection attempts after a certain number of failed tries, effectively giving the user a time-out before they are allowed to try again. Read our guide to installing Fail2ban on Linux cloud servers with CentOS<\/a>, Debian<\/a> or Ubuntu<\/a> to learn more.<\/p>\n\n\n\n
Use SSH keys instead of passwords<\/h2>\n\n\n\n
Passwords are the default way to authenticate to almost everything, and while secure to a point they can often be guessed using brute-forcing or dictionary lists by simply trying multiple variations of common passwords. Secure and difficult-to-guess passwords can then again get troublesome to remember and are easily mistyped.<\/p>\n\n\n\n
Another option is to use SSH keys for authentication by generating a pair of long, practically impossible-to-break, key codes. From these keys, a so-called public key can be safely passed on to your server, while keeping the private key securely on your own computer.<\/p>\n\n\n\n
The public key can only be used to identify the user who has the private part of the pair.<\/p>\n\n\n\n
The private key must be kept safe, ensuring that only you have access to it.<\/p>\n\n\n\n
Check out our guide to\u00a0 Using SSH keys For Authentication<\/a> to learn how to implement it on your Linux cloud server.<\/p>\n\n\n\n
Setup a firewall<\/h2>\n\n\n\n
A common solution for any networked computer security is to set limitations to which connections are allowed. This can be\u00a0done by using a firewall, a network security system, that monitors and controls the incoming and outgoing network traffic based on predetermined security rules.<\/p>\n\n\n\n
The UpCloud control panel offers an easy-to-configure firewall that acts as a first-line defence to secure your cloud server. The UpCloud firewall works server specifically, but you can copy firewall settings between your servers. You also have the option to configure the firewall using one of the premade setups available in the firewall rules settings. The premade rules are a simple starting point for further customization. You can read more about the UpCloud Firewall in its own article.<\/p>\n\n\n\n
Another option on a Linux server is to use the built-in solution called iptables, which is included in most distributions. On CentOS and other Red Hat variants, iptables often come with some pre-configured rules, while Ubuntu and Debian servers don\u2019t implement any restrictions by default. To learn more about iptables, check out our introductory guide to configuring iptables on your Linux server of either CentOS<\/a>, Debian<\/a> or Ubuntu<\/a>.<\/p>\n\n\n\n
Update your system<\/h2>\n\n\n\n
Make sure to regularly check for updates on your Linux server. New vulnerabilities are found from time to time and often patched quickly. Make sure your cloud server has the latest fixes to keep your system up-to-date and secure.<\/p>\n\n\n\n
Ubuntu<\/strong> server users can do this with the following<\/p>\n\n\n\n
sudo apt-get update && sudo apt-get upgrade<\/pre>\n\n\n\n
This is the simple method to update the packages already installed on your server, but it\u2019s not allowed to add or remove packages even if they\u2019ve become obsolete. You can also use the advanced \u201csmart upgrade\u201d with<\/p>\n\n\n\n
sudo apt-get update && sudo apt-get dist-upgrade<\/pre>\n\n\n\n
The command checks package relations and aims to upgrade the most important packages at the expense of less important ones if necessary.<\/p>\n\n\n\n
Debian<\/strong> also includes the apt-get<\/em> but recommends using aptitude<\/em> instead. Enter the following command to upgrade your system.<\/p>\n\n\n\n
sudo aptitude update && sudo aptitude full-upgrade<\/pre>\n\n\n\n
CentOS<\/strong> servers can be updated with a simple command shown below<\/p>\n\n\n\n
sudo yum update<\/pre>\n\n\n\n
Yum does include the upgrade command as well, but it might also remove some packages it deems obsolete even if you were still using them, so the update command is generally safer in most cases.<\/p>\n\n\n\n
Remember to update other software outside the package manager as well, for example, if you use content management software (CMS) like WordPress or Joomla. Make sure to keep your platform up to date and remove any unnecessary plugins, as outdated web apps are often targeted by attackers.<\/p>\n\n\n\n
Minimize vulnerabilities<\/h2>\n\n\n\n
An important part of securing a cloud server\u00a0is to not leave open any unnecessary network services that are listening for incoming connections. A newly deployed Linux system\u00a0usually only has SSH port 22 open. You can test your own server by scanning for open ports using a network tool named Nmap<\/em>. The program isn\u2019t included in many distributions by default, but you can install it simply with one of the following commands on Ubuntu and Debian or CentOS respectively.<\/p>\n\n\n\n
sudo apt-get install nmap<\/pre>\n\n\n\nsudo yum install nmap<\/pre>\n\n\n\n
With the program installed, try running a test scan on the localhost using<\/p>\n\n\n\n
nmap -v -sT localhost<\/pre>\n\n\n\n
The printout will list port numbers and services associated with them that are currently open for local connections. Next, use the same command, but scan for your server\u2019s public IP instead. This can be performed from any computer with internet access and Nmap installed using the following<\/p>\n\n\n\n
nmap -v -sT <public IP><\/pre>\n\n\n\n
If you had more than just SSH appear in the localhost scan, they most likely do not show up in the public IP list. One example of such a service\u00a0is the SMTP email server included in Debian.<\/p>\n\n\n\n
Any other services open to the public network should be paid close attention to. Make sure you know what services you have running and how secure their connection methods are. Disable any services you know you don\u2019t need.<\/p>\n\n\n\n
Scan for malware regularly<\/h2>\n\n\n\n
Linux systems are generally less likely\u00a0to be infected by malicious software as open-source scrutiny and diverse end-user configurations make finding and exploiting vulnerabilities difficult. Your primary defence should be a preventative effort to stop unauthorized access, but it can\u2019t be your only security measure. While you might not think anything on your system is out of the ordinary, a harmful program could be running unnoticed for a long time before causing alarming traffic or system damage. Therefore it\u2019s important that you scan your cloud server for malware regularly, just to make sure it hasn\u2019t been infected.<\/p>\n\n\n\n
Aside from the variety of malware, another type of malicious software to look out for are rootkits, which are a collection of programs designed to gain access to a computer or parts of its OS that are usually restricted while at the same time hiding their presence. The rootkits are often used by an attacker after gaining root access to their target system. Even though rootkits try to mask their existence there are tools made specifically for detecting known rootkit variants.<\/p>\n\n\n\n
Read our started guide for scanning malware on your Linux server running either CentOS<\/a>, Debian<\/a> or Ubuntu<\/a>.<\/p>\n\n\n\n
Implement an Intrusion Detection System<\/h2>\n\n\n\n
Checking your system with malware scanners and the like are still mostly scheduled tasks performed every now and then. This gives any malware time between scans to go about their business unnoticed possibly even for an extended period of time. The solution for the downtime between malware sweeps is to set up an intrusion detection system (IDS), that constantly keeps an eye on your cloud server and its network traffic.<\/p>\n\n\n\n
Snort<\/a> is a popular choice for network-based intrusion detection systems (NIDS), it\u2019s open-source, actively developed, and lightweight enough to be installed on even the smallest of cloud servers. Check out our guides for installing Snort on CentOS<\/a>, Debian<\/a> or\u00a0 Ubuntu<\/a>.<\/p>\n\n\n\n
The other type of intrusion detection system is host-based (HIDS), which analyses system behaviour and configuration status to detect potential security breaches, compromises, modifications to critical system files, common rootkits, and malicious processes.<\/p>\n\n\n\n
OSSEC<\/a> is a good example of an open-source HIDS that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response. OSSEC is available for most operating systems including most common Linux distributions. It\u2019s intended to be configured on a server-client basis, where very light clients are installed on the critical systems, that then send their reports to the OSSEC server for analysis. This is ideal for users with multiple cloud servers for centralized security monitoring.<\/p>\n","protected":false},"featured_media":27375,"comment_status":"open","ping_status":"closed","template":"","community-category":[121],"class_list":["post-24637","tutorial","type-tutorial","status-publish","has-post-thumbnail","hentry","community-category-security"],"acf":[],"_links":{"self":[{"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/tutorial\/24637","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/tutorial"}],"about":[{"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/types\/tutorial"}],"replies":[{"embeddable":true,"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/comments?post=24637"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/media\/27375"}],"wp:attachment":[{"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/media?parent=24637"}],"wp:term":[{"taxonomy":"community-category","embeddable":true,"href":"https:\/\/studiogo.tech\/upcloudold\/wp-json\/wp\/v2\/community-category?post=24637"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}