Staying Up to Date
Most of your dependencies will come through aptitude, to update your local index of dependencies type:
sudo apt-get update
Upgrading the dependencies themselves is done by entering:
sudo apt-get upgrade -y sudo apt-get dist-upgrade -y
As with your smartphone, if you go outside of the aptitude channel make sure you trust the source you are downloading packages from.
Stopping Unused Services
To display all running processes enter the following at the shell prompt:
You will get an output that appears like:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.4 33508 2268 ? Ss Nov30 0:02 /sbin/init
root 2 0.0 0.0 0 0 ? S Nov30 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S Nov30 0:00 [ksoftirqd/0]
root 5 0.0 0.0 0 0 ? S< Nov30 0:00 [kworker/0:0H]
root 7 0.0 0.0 0 0 ? S Nov30 0:09 [rcu_sched]
root 8 0.0 0.0 0 0 ? R Nov30 0:07 [rcuos/0]
root 9 0.0 0.0 0 0 ? S Nov30 0:00 [rcu_bh]
root 10 0.0 0.0 0 0 ? S Nov30 0:00 [rcuob/0]
root 11 0.0 0.0 0 0 ? S Nov30 0:00 [migration/0]
root 12 0.0 0.0 0 0 ? S Nov30 0:01 [watchdog/0]
Some entries in the list will be just one off processes, some will be daemons. If any are running that you don't recognise you can look them up in a search engine and stop them using the command:
The first steps you should take are to limit access to your new server.
UFW (Uncomplicated Firewall)
The easiest way to limit access to the server is by utilising UFW, which is really just a wrapper around iptables the Linux kernel firewall.
If UFW is not already installed install it with:
sudo apt-get install ufw -y
You are most probably connecting via SSH, so enable that:
sudo ufw limit ssh
Instead of "ssh" you can put the port number you have switch SSH to.
Next, enable ports for the services you are going to run on the server, for example http and https would be:
sudo ufw allow http sudo ufw allow https
To enable the firewall type:
sudo ufw enable
Checking the status of UFW is as easy as:
sudo ufw status
You'll notice that UFW has added rules for both IPv4 and IPv6.
If Fail2ban is not already installed install it with:
sudo apt-get install fail2ban -y
Next you have to copy the jail configuration to create a local copy:
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
At this point you might want to edit the configuration file to set parameters for the jail:
sudo nano /etc/fail2ban/jail.local
This will launch the nano editor. Some settings you might want to change are:
ignoreip = 127.0.0.1/8 <<ADD YOUR STATIC IP HERE>> bantime = <<THE NUMBER OF SECONDS TO BAN AN IP ADDRESS FOR>> findtime = <<THE NUMBER OF SECONDS TO CACHE A BANNED IP FOR REMATCHING>> maxretry = <<THE NUMBER OF FAILED LOGINS TO BAN AFTER>>
To exit and save use Ctrl+x, y and Enter.
Next we'll integrate with the badips.com service to track and map where any intrusions originate, in the shell type:
wget -q -O - http://www.badips.com/get/key
This will return a json document with a key attribute, copy this attribute somewhere for future reference. The key will be associated with your VPS by badpis.com. Next execute the following command:
sudo nano /etc/fail2ban/action.d/iptables-multiport.conf
Find the actionban option, which should look something like:
actionban = iptables -I fail2ban-<name> l -s <ip> -j <blocktype>
Change the option to read:
actionban = iptables -I fail2ban-<name> l -s <ip> -j <blocktype> wget -q -o /dev/null www.badips.com/add/<name>/<ip>
You can review your badips.com stats page at https://www.badips.com/stats?key=<key>. There are a few interesting reports available here, such as where attackers are originating their calls and the number of calls that are making it through to your VPS as opposed to those that are being dropped as malicious.
Finally for Fail2ban, we will use a badips list to keep IPTables up to date with a list of malicious IPs. This post by Timo Korthals details two approaches to this, we will be using the second one. Copy the script into a new shell script file called badips4iptables. If we wanted to execute the script once we would enter:
sudo sh badips4iptables
We actually want the script to run on a schedule, so we will add this script to the daily cron folder to run this task daily, at the shell prompt enter:
cp badips4iptables /etc/cron.daily/
Now we want to ensure that the file has the right permissions:
sudo chmod ugo+rx /etc/cron.daily/badips4iptables
To check that the script will now run execute the following command and check that badips4iptables is in the resulting list:
run-parts --test /etc/cron.daily
Use Key Authentication
Usually when you fire up a VPS you are given a root user and a password. Even if you are assigned a key, such as with DigitalOcean, usually there will be a password generated and password authentication still accepted by the server.
Generating a certificate on a Windows system is easy using a program such as PuTTYgen, which comes bundled with PuTTY. Once you load PuTTYgen it's as easy as clicking the Generate button, adding a passphrase to the Private Key and then saving both the Private Key and Public Key.
Protip: If you are using a non-US layout keyboard steer clear of special characters that are in different positions, such as the " on a GB keyboard, as may VPS terminals won't respect these.
To add the Public Key to the server, open the ~/.ssh/authorized_keys file from the shell by entering:
sudo nano ~/.ssh/authorized_keys
Add the Public Key text from the file you saved (or from PuTTYgen itself if it is still open) as a single line in the file and save it by entering Ctrl+x, y, Enter.
At this point it would be a good idea to exit your SSH session and attempt to reconnect using your Private Key. To do this, start PuTTY. In the dialog you want to enter your VPS IP address, navigate to Connection -> Data in the tree and enter your username (usually root) and finally navigate to Connection -> SSH -> Auth and load your Private Key file. Once you have done all of that, click Open and enter your Private Key passphrase in the terminal window. If you are successful you should see a shell prompt.
To disable password authentication over SSH you need to edit the sshd_config file. To edit the file from the prompt enter:
sudo nano /etc/ssh/sshd_config
Either find the line saying:
And change it to, or add a new line:
To test that your SSH configuration is valid enter:
sudo service ssh reload -t
If no errors are shown, reboot your VPS.
There are many options here such as Tripwire Open Source that will monitor and alert file system changes.
As in the Windows world it is not a good idea to give total access to administrative accounts on a Linux VPS. Especially if you are web hosting, ensure that the www-data (or similar) user does not have access to write or execute critical files on the system.