Debian VPS setup - page 1

Debian Etch is a popular choice for a VPS OS for good reasons with stability, configurability and speed among them.

These articles will take you from a 'barebones' Debian VPS to a secure, up to date and working VPS. Not only that, you will have a deeper understanding of what is going on and, more importantly, why it's going on.

Scenario

You have a newly ordered or reinstalled VPS and have chosen Debian Etch as your particular Linux OS.

Unless you have ordered a fully managed solution, your VPS provider will have supplied a 'barebones' Debian install which will need securing and updating. You will then need to install the software required to run a server.

Aim

These articles will take you from a 'barebones' Debian VPS to a secure and up to date VPS with no unnecessary software or other irrelevant resource hogs.

Along the way, we will personalise the VPS to your requirements including the shell output, 'screen' and a customised 'top' install for easy system monitoring.

Once ready, a full MySQL and Ruby on Rails stack with subversion and postfix support will be added.

Most sections are optional so if you don't want Rails then simply skip that section.

Log in

On your LOCAL computer, edit the SSH known_hosts file and remove any entries that point to your VPS IP address. If this is a brand new VPS then you will not need to do this, but an OS reinstall will result in a different signature.

nano ~/.ssh/known_hosts

If you are not using Linux on your LOCAL computer, the location of the known_hosts file will differ. Please refer to your own OS for details of where this file is kept.

As soon as you have your IP address and password for your VPS login via SSH:

ssh root@YOURIPADDRESS

Now we're logged in to the VPS, immediately change your root password

passwd

Add an admin user (I've used the name paul here but any name will do).

adduser paul

As paul is our main administration user (we don't normally log in as root!) he needs to be able to sudo (Super User privileges) so we give those permissions via the visudo command:

visudo

Note: If the 'visudo' command is not found, you may need to install sudo as VPS images may vary slightly between hosting providers:

aptitude install sudo

Once installed, try the 'visudo' command again and at the end of the file add:

paul   ALL=(ALL) ALL

SSH

Now we'll create two directories. One in our root user folder and one in our newly made paul user folder. These 'hidden' directories (did you note the period (.) at the beginning of the folder name?) will hold the public SSH key so we won't have to enter our SSH password every time we log in.

mkdir /root/.ssh && mkdir /home/paul/.ssh

Now we need to copy (using secure copy) the public key from our LOCAL computer to the VPS. On my LOCAL machine, I have the user onion setup, so I would enter:

scp -2 /home/onion/.ssh/id_rsa.pub root@YOURIPADDRESS:/root/.ssh/authorized_keys

Remember to adjust the path to wherever your OS keeps the public key. This is the only time you'll need to enter the root password as the authorized_keys file will enable you to log in without a password. If you are concerned about security (and passwordless logins are far more secure than using passwords), then here is a nice ssh tricks article.

Now we need to configure SSH to make it more secure.

nano /etc/ssh/sshd_config

Use this ssh configuration as an example.

The main things to change (or check) are:

Port 30000                           <--- change to a port of your choosing
Protocol 2
PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
UsePAM no
UseDNS no
AllowUsers paul

Now we're going to do a bit of copying and changing permissions of some files. This is so that we can log in without passwords and not worry about who can see what. There are a few lines shown below (each line is a separate command), but each one is fairly self explanatory.

Overall, we're going to copy the authorized_keys file from root into paul's .ssh folder. Then change the permissions so it's not available to everyone.

cp /root/.ssh/authorized_keys /home/paul/.ssh/authorized_keys
chown -R paul:paul /home/paul/.ssh 
chmod go-w /root/
chmod 700 /root/.ssh 
chmod 600 /root/.ssh/authorized_keys
chmod go-w /home/paul/
chmod 700 /home/paul/.ssh
chmod 600 /home/paul/.ssh/authorized_keys

iptables

Right, now we have the basics of logging in and security done. Next thing is to set up our iptables so we have a more secure installation. We're going to have four ports open: ssh, http, https and a port for our Litespeed Server GUI.

We're going to create two files, /etc/iptables.up.rules and /etc/iptables.test.rules. One will be the 'permanent' set of rules and one will be the temporary (test) set of rules.

Let's save any existing rules to /etc/iptables.up.rules:

iptables-save > /etc/iptables.up.rules

Now let's see what's running at the moment:

iptables -L

You will see something similar to this:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

As you can see, we are accepting anything from anyone on any port and allowing anything to happen. Not sure about you but I don't like that.

Lets create the file /etc/iptables.test.rules and add some rules to it.

nano /etc/iptables.test.rules

Look at this example iptables configuration file. This configuration allows connections to ports 80 and 443 (the standard web server ports) and allows connections to the SSH port and to the Litespeed GUI. It also has some logging facilities so you can monitor SSH login attempts.

You will begin to see the pattern of the iptables configuration file. It isn't complicated and it is very flexible and you can change and add ports as you see fit.

What's the litespeed admin port all about? The web server we will setup later on uses a particular port for administration and configuration. We'll setup the port later when we install the server, but for now, we are just defining the firewall rules.

Good. Defined your rules? Then lets apply those rules to our server:

iptables-restore < /etc/iptables.test.rules

Let's see if there is any difference:

iptables -L

Notice the change? (If there is no change in the output, you did something wrong. Try again from the start). Have a look at the rules and see exactly what is being accepted, rejected and dropped.

Once you are happy with your /etc/iptables.test.rules file and are happy with the output of iptables -L, it's time to save our rules permanently:

iptables-save > /etc/iptables.up.rules

Now we need to ensure that the iptables rules are applied when we reboot the server. At the moment, the changes will be lost and it will go back to allowing everything from everywhere.

Open the file /etc/network/interfaces

nano /etc/network/interfaces

Add a single line (shown below) just after 'iface lo inet loopback':

...
auto lo
iface lo inet loopback
pre-up iptables-restore < /etc/iptables.up.rules

# The primary network interface
...

As you can see, this line will restore the iptables rules from the /etc/iptables.up.rules file. Simple but effective.

Now we have our firewall humming along and we've set the ssh configuration. Now we need to test it. Reload ssh so it uses the new ports and configurations:

/etc/init.d/ssh reload

Don't logout yet...

On your LOCAL computer, open a new terminal and try and login using the administration user (in this case, paul) to the new port number you configured in the sshd_config file and allowed to be open in the iptables configuration:

ssh -p 30000 paul@YOURIPADDRESS

The reason we use a new terminal is that if you can't login you will still have the working connection to try and fix any errors. Some VPS providers have an 'emergency console' - Slicehost also has the excellent ajax console - so if it all goes horribly wrong, you can still log into your VPS and fix any configuration errors.

If all has gone well you will be logged in without entering a password:

paul@yourvpsname:~$

This is very secure as only you (hopefully!) have access to the private key on your computer. We also set up the SSH configuration to not accept passwords as an authorisation method so SSH will not even listen to someone trying different passwords.

We now know that the firewall works, the SSH configuration works and we can login safely and securely. A good start.

Let's move on to the next article which includes configuring the terminal and bash commands and updating the Debian Etch install to include the latest security updates.

PickledOnion.

Digg it | del.icio.us | reddit | StumbleUpon