In the past few months an important part of my daily job tasks has been spent (devoted!) to re-engineering and migrating our data-center. So I often ended up repeating a certain schedule of tasks. This post is a reference to get back to, when needed. The whole tutorial is based on Ubuntu 14.04.
Connect to your brand new server:
Replace yourServerIP with with your actual IP address. Regardless of which cloud hosting provider you choose, you can find the IP address somewhere in the web control panel/management console associated. We ended up opting for Linode, but there are other viable an valid solutions, also not too expensive like Digitalocean, as well.
You will be prompted for the password you most likely entered during account creation or VM deployment process.
Once connected let's proceed with basic setup.
To set the hostname type:
root@yourServerName:~$ echo "yourServerName" > /etc/hostname
Verify that it has been set correctly:
root@yourServerName:~$ hostname -F /etc/hostname
If everything went OK, you should see printed on the screen the name you chose.
To set the Fully Qualified Domain Name (FQDN for friends) of the server it's advisable to add an A record that points from one of your domains to your new machine and then edit /etc/hosts accordingly:
root@yourServerName:~$ sudo vim /etc/hosts 127.0.0.1 localhost.localdomain localhost 192.168.204.132 yourServerName 188.8.131.52 yourServerName.yourdomain.com # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters
From now on, to connect to your server, you can type:
Here's the man page of /etc/hosts
To set the server timezone:
root@yourServerName:~$ dpkg-reconfigure tzdata
and to verify that date and time are the expected ones:
Make sure to pick the locale you prefer and generate it:
root@yourServerName:~$ sudo locale-gen "en_IE.UTF-8"
then edit /etc/default/locale adding these lines:
root@yourServerName:~$ sudo vim /etc/default/locale LANG="en_IE.UTF-8" LANGUAGE="en_IE:en" LC_ALL="en_IE.UTF-8"
We can now check for updates:
root@yourServerName:~$ sudo apt-get update
and then upgrade:
root@yourServerName:~$ sudo apt-get upgrade
Since it's not a good practice to use root to login to your servers via SSH, we first need to create a new regular account that will have the power to become root via sudo:
adduser yourUsername usermod -aG sudo yourUsername
You will be prompted for a new password and some other questions, after the adduser command.
Logout from your server so we can log back in with the newly created user:
and then from your local machine:
after entering your password you should see:
Now, since it's not only boring but potentially more insecure to have to enter yourpassword everytime you need to login via SSH to your server, we will setup SSH Keys for your primary computer. Note that you can do that for any of the machine you'll use to upkeep your server.
Logout again from your server and check whether or not you already had generated SSH Keys by looking for /home/yourUsername/.ssh/idrsa.pub file on your local computer/laptop. If it is not present we can generate one:
ssh-keygen -t rsa -C "yourEmailAddress"
The -C (comment) option isn't strictly necessary, but it is useful to distinguish among different keys among multi users system.
Accept the defaults and choose a good passphrase, even if it is optional.
The result of the above command will generate two key files, one public and one private, in the ~/.ssh folder.
More information about SSH keys, can be found here.
It's time for you to copy the generated public key to your server:
From now on, you'll be required to enter the passphrase only the first time you connect to your remote server or when you'll reboot your working computer/laptop.
Let's enhance our server securty by disabling root access via ssh and changing the SSH port from the default 22 to a less obvious one, but below 1024. That will be enough to prevent the majority of automatic attacks from hackers.
To know why it's better to choose a port below 1024, read here.
yourUsername@yourServerName:~$ sudo vim /etc/ssh/sshd_config
and change the lines:
Port yourChosenPort ... PermitRootLogin no
then save the file and restart ssh service:
yourUsername@yourServerName:~$ sudo service ssh restart
Logout and test your changes:
ssh -p yourChosenPort yourUsername@yourServerName.yourDomain.com
How to further improve security and prevent repeated login attempts? Fail2ban is the answer!
yourUsername@yourServerName:~$ sudo apt-get install fail2ban
To configure Fail2ban, make a backup copy of its original configuration file:
yourUsername@yourServerName:~$ sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
and then edit jail.conf to match your choosen ssh port and to enable ssh-ddos:
yourUsername@yourServerName:~$ sudo vim /etc/fail2ban/jail.local [ssh] enabled = true port = yourChosenPort ... [ssh-ddos] enabled = true port = yourChosenPort ...
(Change the port number to match whatever you set your SSH port to).
Save the file and restart Fail2ban service to apply the new rules:
yourUsername@yourServerName:~$ sudo service fail2ban restart
Adding a firewall is the next logical step. Install ufw if you don't have it already:
yourUsername@yourServerName:~$ sudo apt-get install ufw
Depending on what the purpose of your new server is, firewall configuration might vary.
For further information on how to properly set ufw up, refer to this DigitalOcean guide.
We can do one more thing to improve security a bit more. What about getting an email everytime someone uses sudo on your server?
First of all, install sendmail:
yourUsername@yourServerName:~$ sudo apt-get install sendmail
then create a new file in /etc/sudoers.d/. I like to use a name that logically links it to the server it's used on:
yourUsername@yourServerName:~$ sudo vim /etc/sudoers.d/yourServerName_sudoers Defaults mail_always Defaults mailto="yourEmailAddress"
and set appropriate permissions on the file:
yourUsername@yourServerName:~$ sudo chmod 0440 /etc/sudoers.d/yourServerName_sudoers
After that, you'll get an email whenever someone uses sudo.
To improve server stability and reboot in case the server runs out of memory, add at the bottom of /etc/sysctl.conf these lines:
The vm.paniconoom=1 line enables panic on Out-Of-Memory condition and the kernel.panic=10 line tells the kernel to reboot ten seconds after entering in panick state. Adjust that number to what best suites your scenario.
A quick reboot when necessary is always better to leave the server in a troublesome situation that will degrade performances of whatever you are serving.
Now you have a fully working server with a pretty decent security to start with.