After discussing options in choosing a cheap, low-end, learning VPS, we take a look here at how to set it up for secure use, for when you get a so much for so little, you want to make sure it’s only yours!
These are the commands I issue when I first login to a VPS – (I used +bryan and the associated HackerNews discussion for estimating consensus). The “$” is there to signify the prompt – you don’t need to replicate it when issuing commands.
Most VPS control panels offer you the ability to reset (change) your root password. Nonetheless, start by changing it to something long and complex you can either remember or retrieve later.
Next, update and upgrade:
$ apt-get update && apt-get upgrade
Fail2ban is a daemon that goes through your logs and blocks suspicious activity as it occurs. Nano is a text editor that’s more visual and less intimidating than vim. Other intrusion detection tools you might want to consider are rkhunter (RootKit), psad (analyzes iptables log), lynis; to check your setup try privesc.
$ apt-get install fail2ban nano p7zip-full htop sysstat
Optionally, if you would like nano to display line numbers edit /etc/nanorc and uncomment set const. If you find that fail2ban uses too much memory, append the ulimit command to /etc/default/fail2ban or simply issue:
$ echo “ulimit –s 256” >> /etc/default/fail2ban && service fail2ban restart
Create a new user. “Deploy” is a seemingly popular term, but on my boxes I tend to use another username. The command adduser makes it easy. If you would rather use a different username, be sure to change it throughout the rest of the commands. If for some reason “adduser” won’t work, use useradd and be sure to create the home directory.
$ adduser deploy
$ mkdir /home/deploy/.ssh
$ chmod 700 /home/deploy/.ssh
$ nano /home/deploy/.ssh/authorized_keys
Now paste the contents of your public key (starting with “ssh” as puttygen outputs it), then change the file permissions:
$ chmod 400 /home/deploy/.ssh/authorized_keys && chown deploy:deploy /home/deploy –R
Open a new terminal (Putty) window and login to the new server with the deploy user and your private key. If successful, set the password for this user. You will use this password for administering the server.
$ passwd deploy
To ensure that the deploy user can gain sudo, you need to issue the command
..and comment the existing user/group grand lines, adding
root ALL=(ALL) ALL
deploy ALL=(ALL) ALL
If you get an error for “visudo” (this might happen in a minimal Debian install) you need to apt-get install sudo. Now to secure SSH, you need to edit sshd_config as follows.
$ nano /etc/ssh/sshd_config
Look for and modify the lines below as necessary, uncommenting them if necessary.
AllowUsers deploy@<IP> deploy@<another IP>
Changing the default port makes it a bit harder for script kiddies; note that some recommend using a nonstandard value below 1024 as otherwise you might inadvertently make it easier to have your box pwned. In the last line, replace <IP> and <another IP> with actual IP number if you always log in from a fixed IP; if not, ignore that line altogether.
For the changes to take effect, SSH needs restarting.
$ service ssh restart
To set up automatic security updates, issue the following:
$ apt-get install unattended-upgrades
$ nano /etc/apt/apt.conf.d/10periodic
Make sure the following can be found in that file:
You might also want to edit the “allowed-origins” section of /etc/apt/apt.conf.d/50unattended-upgrades and comment out (with //) anything but security updates. To ensure everything works as intended, install Logwatch to monitor and email you logs:
$ apt-get install logwatch
$ nano /etc/cron.daily/00logwatch
Add this line, replacing as needed with your actual email address:
/usr/sbin/logwatch --output mail –mailto indeliblebonobo @gmail.com --detail high
Now that your server is updated, operational and stable, consider starting a Journal file, where you write any changes as you make them. You may keep it locally or on the box. You could also save a snapshot of the running processes.
The above steps are things that most sysadmins will do with their boxes, for starters. The following are less general and more specific to my preferences.
If you have to move to another VPS or configure many servers, the above is quite tedious. One way to avoid the tedium is using tools such as Puppet or Chef. Both are, however, quite complex and make sense only for large scale infrastructure deployments. Fred from Practical Ops wrote a great guide and “recipe” (po-ans) for doing all the above with Ansible, a much simpler and easier tool. I use my own Ansible recipe based on his, on a desktop Linux box (or another VPS that is already set up) doing the following (some have managed to install it on Windows under Cygwin):
- Login to your server and set the root password (# passwd)
- Git the recipe: $ git clone https://github.com/ibonobo/5minbootstrap.git && cd 5minbootstrap
- Edit bootstrap.yml changing the variables – at least email & deploy_password (as explained)
- Edit hosts.ini, replacing 127.0.0.1 with your new box IP address and 2222 with the SSH port you are starting with.
- Copy your public key in ssh format to “ibonobo.pub” – if on linux,
$ cp ~/.ssh/id_dsa.pub ./ibonobo.pub
otherwise in Windows copy it from puttygen and save as ibonobo.pub.
- Install Ansible on your workstation (see link below, in Sources) then run it (on Linux: $ ansible-playbook -i hosts.ini bootstrap.yml --user root --ask-pass
To change: I do not want to set a fixed IP, I would like to be able to log in from any IP.
For a low-end box, Apache may be too demanding, so I completely removed it. Nginx or OpenLiteSpeed are far better suited for this situation.
$ service apache2 stop && apt-get purge apache2 apache2-utils apache2.2-bin apache2-common && rm -rf /etc/apache2
If you get some error message about that last command / directory, you can find the correct directory with $ whereis apache2. Some people uninstall even the following: sendmail* exim4* bind9 samba xinetd (don’t! unless you really know what they do and what you’re doing).
Another optional step is installing Network Time Protocol and setting its timezone. This however may not be needed / possible when sharing a linux kernel.
$ apt-get install ntpdate && dpkg-reconfigure tzdata && nano /etc/cron.daily/ntpdate
$ chmod 755 /etc/cron.daily/ntpdate
Again, this step may not needed/possible with OpenVZ, but if being synchronized to the correct time is very important for your application, consider using NTPd (apt-get install ntp).
Most of the time, all that’s needed is setting the timezone, which you can check with $ cat /etc/timezone. To change it, $ dpkg-reconfigure tzdata.
If you will be using this box for webserving and want the latest versions, consider using Dotdeb. For Nginx alone, add-apt-repository ppa:nginx/stable. To get Nginx up and running you might want to nano /etc/nginx/sites-available/default, then modify root to point to your website directory and the following line (index, etc) to include other default files you might have, such as index.php or .htm etc then (re)start the nginx service.
If starting with a Debian minimal install, you want to configure some webserving services, you might want to rely on dotdeb rather than the official Debian for updates, as dotdeb serves these faster than Debian. That delay could sometimes make the difference between an exploit being used against your server and a worry-free patch being installed.
The easiest way is to add these to your sources.list:
deb http://packages.dotdeb.org jessie all deb-src http://packages.dotdeb.org jessie all
Personally, I prefer to put them in a .d:
$ nano /etc/apt/sources.list.d/dotdeb.list
Obviously, if your distro is something other than Jessie, replace “jessie” above as necessary. If you’re not sure, do one of the following:
- lsb_release -
- cat /etc/*-release
- cat /proc/version
- uname –a
- uname –mrs
If you issue apt-get update at this time, you’ll get an error message. To add the keys, do
$ wget -qO – https://www.dotdeb.org/dotdeb.gpg | sudo apt-key add -
(though dotdeb recommends:)
$ wget https://www.dotdeb.org/dotdeb.gpg $ sudo apt-key add dotdeb.gpg
Keep in mind that testing is what makes Debian so stable, and dotdeb is only suited for servers focused on webhosting.
You might not know this, but the most important services on your brand new server readily tell anyone who might be asking what they are and what version. In an ideal world where we are all friends that’s fine, but for an attacker, that’s a godsend, as they can target their efforts more easily this way. The lines to add to configuration files will be displayed in “typewriter font,” while the commands will be in italics.
- Apache2 HTTPd – append the 2 lines below
$ nano /etc/apache2/apache2.conf
- Nginx – append the line below at the very end (to remove the server/software name you will need to compile from source; see rmsign link below for details)
$ nano /etc/nginx/nginx.conf
add the last line only if compiled from source as stated above
- PHP – edit the following four files and set the lines that follow in each
$ nano /etc/php5/apache2/php.ini
$ nano /etc/php5/cgi/php.ini
$ nano /etc/php5/cli/php.ini
$ nano /etc/php5/fpm/php.ini
; Decides whether PHP may expose the fact that it is installed on the server
expose_php = Off
- Postfix replace the first line with the second
$ nano /etc/postfix/main.cf
replace smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
with smtpd_banner = $myhostname ESMTP $mail_name
Some people prefer configuring a server through either ISPconfig or Webmin and its derivatives; varnish/php-fm/nginx/MariaDB, others prefer APC (php opcode cacher) and don’t use varnish with low-memory machines.
Please keep in mind that securing a server is a demanding task; the above is what most people do as a start. Some of the links below will surely help with further tasks. For more customization, mostly a long .bash_aliases file, see the next episode.