about blog projects contact

The Cogwheel Blog

Fork me on GitHub
## Linux VPS Server Configuration ### Background The propagation of public cloud and VPS (Virtual Private Server) providers has made the prospect of provisioning a server a viable reality for many. I have benefitted from this trend myself as I have forayed into signing onto AWS EC2 instances as well as one or two smaller VPS providers like Linode. [VPS Benchmarks](https://www.vpsbenchmarks.com/) is a handy reference for those looking to compare/contrast the performance and features of many of these providers. Setting up a server from scratch is not without its pitfalls and many of the providers seeking to compete in this space today have put together some very useful tools to help with this. Providers vary greatly in their hand-holding from the over-the-top approach of AWS (which goes above and beyond others by giving specific instructions on ssh access to instances, walking one through the public-private keygen process) to the more bare-bones approach of smaller shops. It was recently when I was having to provision one of these servers for myself that it occurred to me it would be beneficial to write down a baseline protocol to follow to provision a *nix server from scratch. As such, I formulated the following rules for a Linux/Ubuntu instance, which is a popular choice among subscribers. (Note: I have a Linode-specific provisioning article which I posted to my [GitHub](https://github.com/builderLabs/linux_server_config/blob/master/LinuxSrvCfg.md) page for those who might be interested. Since it's posting, I have seen a proliferation in similar such write-ups which is likely an indication that this space and use-case scenario is only growing). ### Summary Steps: Conceptually-speaking, the steps to acquiring and configuring a VPS or cloud instance for one's own use would involve the three (fairly obvious) steps of: ``` 1). Provisioning the Server --- this means signing up with a vendor, choosing an OS and disk image, booting it up, and so forth 2). Securing the Server --- following basic steps to 'make it your own' 3). Updating Software and Monitoring for future use ``` Among these, the 'Securing the Server' step is of special importance and that is the focus of this blog entry. Since I found myself having to repeat the same basic steps of securing a given instance following the 'best practices' of today and from what I've learned from experience working at smaller shops, I decided to write these down for reference. These are the basic steps I will be detailing in this entry: ``` 1). REMOVE ATTACK VECTOR: root login 2). REMOVE ATTACK VECTOR: password-based authentication 3). REMOVE ATTACK VECTOR: default ssh port log-in 4). REMOVE ATTACK VECTOR: unauthorized traffic (setup a firewall) ``` (CAVEAT EMPTOR: Every use-case scenario is bound to vary and these steps might not be applicable to every situation but I hope collecting these here might prove to be of use). ### Securing a Server: baseline steps for a Linux Ubuntu instance: ``` 1). REMOVE ATTACK VECTOR: root login ``` It's highly likely that the provisioning phase of acquiring a server involved you (or the owner) setting up a root account with superuser privileges (as is par for the course). Obvious though it might seem, it's good practice to create a different user account with root privileges known only to you and/or those on a need-to-know basis and to disassociate the superuser role from the account called 'root' which everybody already knows. The first time you do this, it's likely you'll be having to log in to your freshly setup root account for which you have (hopefully) generated a strong password for password-based authentication (also par for the course for many providers from the get-go). Assuming you have logged into your instance as root, you can now use the following (in Ubuntu-speak) to do this: ``` a). sudo adduser [user] ``` Follow the command prompts and answer the questions which ensue. Next, assign the new user profile root privileges. Create a sudoer file as follows: ``` /etc/sudoers.d/[user] ``` (Note that the file can be called anything, but common practice is to give it the profile name.) put this line inside the file: ``` [user] ALL=(ALL:ALL) ALL ``` This means that for the user we are granting permission to run all commands as all users and all groups from all hosts. You can verify that the user has been added by: ``` sudo cat /etc/passwd | grep [user] ``` Check to make sure you get output from this command, otherwise the user has not been properly added. Having added a new superuser with root privileges, it would be wise at this point to disable logins for the actual user 'root'. Switch from our root profile to the new superuser profile: ``` su - [user] ``` Verify your prompt changes to: ``` [user]@localhost:~$ ``` Edit the server-side sshd_config file: ``` /etc/ssh/sshd_config ``` Change the line 'PermitRootLogin' to read: ``` PermitRootLogin no ``` save and quit. Now restart the ssh service to read the updated configuration changes we made: ``` sudo service ssh restart ``` Confirm you have disabled root log-in by exiting your profile and from your log-on session: ``` exit exit ``` Verify that the following command from your local host: ``` ssh root@12.345.67.890 [ root @ your VPS public IP address ] ``` fails. Conversely, verify that you are able to log on to your server doing: ``` ssh [user]@12.345.67.890 ``` ``` 2). REMOVE ATTACK VECTOR: password-based authentication ``` As the next basic step, remove all the uncertainties/vulnerabilities associated with password-based authentication and replace this entirely with Secure Shell (ssh) login, using public key encryption, instead. On your local machine, create an ssh directory (if not there): ``` mkdir ~/.ssh ``` Create a file called 'config' in this directory to which we will add our remote server's connectivity details. Put the following lines in this file: ``` Host [hostalias] Hostname=12.345.67.890 ``` The value next to 'Host' is the name you want to give your remote server. The value for 'Hostname' should be the public IP address you were given by the vendor for your machine. Note: this step is meant to simplify remote logins to our server. Whereas up to now we used the public IP address of our server to login, we can now use our more descriptive hostname to connect just by typing: ``` ssh [user]@[hostalias] ``` To replace password-based authentication to the server, create a key pair. You can read more on this protocol [here](https://en.wikipedia.org/wiki/Ssh-keygen). Run the following command on your local machine (assuming you haven't done so already before. If you have, you have the option of using your existing key pair combination for this step): ``` ssh-keygen ``` By default, the encryption used is 'RSA'. This can be changed to another format with the '-t' option. Refer to [this](https://en.wikipedia.org/wiki/Ssh-keygen#Key_formats_supported) for alternative encryption protocols. (Yet another option is to use the -f argument to give a specific name to the keys you generate here). Assuming the standard RSA encryption was used, this will generate two keys in your ~/.ssh directory: ``` id_rsa id_rsa.pub ``` Copy the contents of your PUBLIC KEY id_rsa.pub (the private key id_rsa should remain private and on the local client). Back on the REMOTE SERVER we provisioned, create the .ssh directory under the superuser's home directory: ``` mkdir ~/.ssh ``` Create a file called: ``` authorized_keys ``` and paste your id_rsa.pub content into it (alternatively, use rsync/scp to copy the content of your public key over to this file on the remote server). We'll need to grant permissions on this file/directory accordingly, thus: ``` sudo chmod 700 ~/.ssh ``` ( grant user read/write/execute permissions ) ``` sudo chmod 644 ~/.ssh/authorized_keys ``` ( grant user read/write, group and others read permissions ) Define localhost in hosts file with server IP address. This file establishes static associations between IP addresses and hostnames and is read first before any DNS lookups: edit: ``` /etc/hosts ``` to ensure the first entry that it looks like this: ``` localhost.localdomain localhost ``` (Note: different distributions have different requirements. As a result, should host resolution errors crop up downstream - when attempting to service a request for a hosted web application, for instance - edit this file to include the explicit IP address of your server, as follows: localhost ip-12.345.67.890) Having done all this, test the key pair based login. First quit the server: ``` exit ``` Back on the client machine, let us ssh back to the remote server: ``` ssh [user]@[ipAddress] -i [pathToPrivateKey] ``` thus: ``` ssh [user]@12.345.67.890 -i ~/.ssh/id_rsa ``` This should work. If not, review the steps above to ensure they were executed correctly. Note that if you took the extra step to edit your ~/.ssh/config file on your local machine, our login command to the remote server reduces to simply: ``` ssh [user]@hostname ``` thus: ``` ssh [user]@[hostalias] ``` This way, you don't have to remember the IP address every time. Once you have confirmed this works, disable password-based authentication on the remote server. Back on the remote server, edit the file: ``` /etc/ssh/sshd_config ``` change the line: ``` PasswordAuthentication yes ``` to read: ``` PasswordAuthentication no ``` (Note: make sure you're on the server editing /etc/ssh/sshdconfig which is the ssh daemon which runs server-side. If all you see is /etc/ssh/sshconfig, you're on your local machine as this is the client side OpenSSH config file). For these config changes to take effect, restart the service: ``` sudo service ssh restart ``` Alternatively, you can wait until you've completed Step 3 (below) to restart the ssh service on the remote server before exiting and reconnecting. ``` 3). REMOVE ATTACK VECTOR: default ssh port log-in ``` While on the REMOTE server, edit the configurations file above such that the ssh port is set to something other than the default 22. Modify ``` Port 22 ``` to read: ``` Port [port] [some other available port of your choosing ] ``` Since this was yet another configuration change, we need to restart the config read process for the ssh service: ``` sudo service ssh restart ``` With password-based authentication disabled and our ssh port changed from 22 to another port of our choosing, test connections to the remote server by quitting and logging back in again. Exit the server: ``` exit ``` Now attempt to reconnect from our local machine using the following command: ``` ssh [user]@12.345.67.890 - ~/.ssh/id_rsa -p [port] ``` Again, to make this process more convenient, you can edit the ssh config file on your local machine such that the section with our new server (with hostalias) reads as follows: ``` Host [hostalias] Hostname=12.345.67.890 Port=[port] ``` (Note all we're doing here is appending our non-default ssh port number to the information we already added in a previous step). If you do have this information in your ~/.ssh/config file, logging on to your remote server should now be as easy as: ``` ssh [user]@[hostalias] ``` ``` 4). REMOVE ATTACK VECTOR: unauthorized traffic ``` With our server now minimally secured, it is out there, connected to and accessible via the internet and as such it is prudent to be selective with any incoming traffic from potentially malicious entities. Basically, this means setting up a **firewall**. Here, we take steps to configure firewall settings so as to permission and delegate specific types of traffic/requests to their respective ports using Ubuntu's Uncomplicated Firewall UFW which is a high-level tool that has made the once tedious tasks of micro-managing iptables for firewall configurations a thing of the past. While we're likely to want to allow ourselves to be able to reach out to the world from our server, incoming traffic to our server is another matter altogether and for which our guiding philosophy will be: **Start with no traffic and add on piecemeal** The UFW does not come enabled by default. This means that with a fresh Ubuntu Linux server set up, all traffic is enabled from the get go. (Note: be sure to process each of the following commands correctly. If you make a mistake, you will have a chance to fix it before we enable the firewall in the last step. Before it is enabled, however, you need to make sure that you haven't setup the firewall to do unintended things - key among which would be locking yourself out of the server by disabling your chosen ssh port). 1). Blank Slate: reign in all traffic allow ourselves all outgoing traffic: ``` sudo ufw default allow outgoing ``` deny all incoming traffic: ``` sudo ufw default deny incoming ``` 2). First and foremost, allow incoming ssh requests: ``` sudo ufw allow [port] [ make sure your configured ssh port is here ] ``` (Note: if you've only allowed yourself ssh-based access, having followed the steps above, **MAKE SURE YOU DO THIS** otherwise you'll lock yourself out of your server once you quit it). 3). Allow http requests to our server (especially if you're going to host a web app on it): ``` sudo ufw allow 80 ``` 4). Finally, add any other incoming traffic which might be of value of importance to you. A reference for many of these can be found [here](https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers). 5). With these commands processed, take a moment to look back in your command history to ensure you haven't done anything unintended. In particular, make sure you have *allowed incoming ssh requests* via the port you configured in /etc/ssh/sshd_config (originally 22). Each rule is updated as you enter the command, hence the return: ``` Rules updated ``` If you have made a mistake and need to change a port number, simply enter the command with the correct port number. Otherwise, enable the firewall as a last step, if all settings appear to be in order: ``` sudo ufw enable ``` At which point you're liable to see: ``` Command may disrupt existing ssh connections. Proceed with operation (y|n)? ``` Answer 'y' to confirm. You should then see a confirmation message as follows: ``` Firewall is active and enabled on system startup ``` With these basic four steps, we have addressed the most rudimentary security requirements for securing a freshly provisioned Linux VPS with Ubuntu image. As stated before, requirements vary according to different use-case scenarios and your particular needs will very likely require either more precautionary measures than those listed here and/or different ones, depending on your needs. As a baseline-guide, however, these steps might prove useful to anyone looking to provision a server for themselves from scratch.

-A. Ozan Akcin