These Gentoo articles will take you from a ‘barebones’ Gentoo Server to a secured and up to date Server ready for your server software (or whatever you use the Server for).

Securing your Server as soon as possible is a great way of starting your Server administration.

Log In

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

ssh root@123.45.67.890

If you rebuilt your Server, you may get a message informing you that the “remote host identification has changed”.

When you log into a Server via SSH, one of the security features is matching the remote host with known keys. When you rebuild a Server, the remote host key changes. As such, your computer thinks there is something dodgy going on.

All you need to do is remove the older entry for the Server IP:

On your LOCAL computer, edit the SSH known_hosts file and remove any entries that point to your Server IP address.

nano ~/.ssh/known_hosts

If you are not using Linux or a Mac 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.

User Administration

Once logged in to the VPS, immediately change your root password to one of your choosing:

passwd

Add an admin user (I’ve used the name demo here but any name will do). The -m causes gentoo to automatically create the users’ home directory in /home/demo.

adduser -m demo

Give this user a password:

passwd demo

Enter the new password twice as prompted. Please note that it will not echo back your keystrokes, just type normally. If you make a mistake just hit Enter and it will start the process again.

SUDO

As you know, we never log in as the root user (this initial setup is the only time you would need to log in as root). As such, the main administration user (demo) needs to have sudo (Super User) privileges so they can, with a password, complete administrative tasks.

We will give sudo privileges to all users who belong to the wheel group.

To configure this, give the visudo command:

visudo

Find the line that reads:

    # %wheel        ALL=(ALL)       ALL

and uncomment it by removing the '# ' (hash and space), so it looks like this:

    %wheel        ALL=(ALL)       ALL

Save the changes by hitting these key combinations: CTRL+O to write out the file, Enter to confirm the filename, CTRL+X to exit the program.

Now we’ll add demo to the wheel group; giving him the ability to use sudo:

usermod -aG wheel demo

Again, replace demo with whatever name you chose above.

SSH Keygen

One effective way of securing SSH access to your server is to use a public/private key. This means that a public key is placed on the server and the private key is on our local workstation. This makes it impossible for someone to log in using just a password - they must have the private key.

The first step is to create a folder to hold your keys. On your LOCAL workstation:

mkdir ~/.ssh

That’s assuming you use Linux or a Mac and the folder does not exist. There will be a separate article for key generation using Putty for Windows users.

To create the ssh keys, on your LOCAL workstation enter:

ssh-keygen -t rsa

If you do not want a passphrase then just press enter when prompted.

That created two files in the .ssh directory: idrsa and idrsa.pub. The pub file holds the public key. This is the file that is placed on the Server.

The other file is your private key. Never show, give away or keep this file on a public computer.

SSH Copy

Now we need to get the public key file onto the Server.

We’ll use the scp (secure copy) command for this as it is an easy and secure means of transferring files.

Still on your LOCAL workstation enter this command:

scp ~/.ssh/id_rsa.pub demo@123.45.67.890:/home/demo/

When prompted, enter the demo user password.

Change the IP address to your server and the location to your admin user’s home directory (remember the admin user in this example is called demo).

SSH Permissions

OK, so now we’ve created the public/private keys and we’ve copied the public key onto the Server.

Now we need to sort out a few permissions for the ssh key.

On your Server, there’s a directory called .ssh in the demo user’s home folder, lets move the pub key into it:

mv /home/demo/id_rsa.pub /home/demo/.ssh/authorized_keys

Now we can set the correct permissions on the key:

chmod 600 /home/demo/.ssh/authorized_keys

Done. It may seem a long set of steps but when you have done it once, you can see the order of things: create the key on your local workstation, copy the public key to the Server and set the correct permissions for the key.

SSH Config

Next we’ll change the default SSH configuration to make it more secure:

nano /etc/ssh/sshd_config

The main things to change (or check) are:

    # Change the default port to something else:
    Change: #Port 22
    to:     Port 30000 # (Actually change it to something generic, 30000 is just an example)
    
    # Don't allow root to login through ssh
    Change: #PermitRootLogin yes
    to:     PermitRootLogin no
    
    # Specify which users can login via ssh. Add this line to the bottom of the file.
    # More users can be addded using `space` as a separator, eg. demo anne jenny
    AllowUsers demo

Once done, save the file and exit the editor using the same commands as earlier. I think the settings are fairly self explanatory but the main thing is to move it from the default port of 22 to one of your choosing, turn off root logins and define which users can log in.

PasswordAuthentication has been turned off as we setup the public/private key earlier. Do note that if you intend to access your server from different computers you may want leave PasswordAuthentication set to yes. Only use the private key if the local computer is secure (i.e. don’t put the private key on a work computer).

Note that we haven’t enabled the new settings - we will restart SSH in a moment but first we need to create a simple firewall using iptables.

iptables

As said, the next thing is to set up our iptables so we have a more secure installation. To start with, we’re going to have three ports open: ssh, http and https.

Note that we are logged in as the root user. This is the only time we will log in as the root user. As such, if you are completing this step at a later date using the admin user, you will need to put a sudo in front of the commands.

iptables isn’t included by default on Gentoo, so we’ll have to install it first:

emerge iptables

Gentoo will now proceed to downlaod, compile and install the iptables and all its dependencies. Feel free to go make a cup of coffee at this point. We’ll be looking at ways to speed up compiling and installs in the next article.

While you sip your coffee, read this short iptables description: iptables works by applying rules to network packets that move through chains. The packets we care most about start in the INPUT chain and end up in either the ACCEPT or REJECT chain.

Read the bottom of the install output, it will mention that forwarding is disabled by default and how to turn it on. Forwarding is useful if you want to use one server as a router to pass packets to another server.

This won’t affect this tutorial, but beware, you cannot add any forward rules to ip-tables until you enable forwarding as described in the warning message or you upgrade iptables (as in the next gentoo article); doing so will cause some strange networking behaviour.

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.

One theory is that if there are no services running then it doesn’t matter. I disagree. If connections to unused (and popular) ports are blocked or dropped, then the vast majority of script kiddies will move on to another machine where ports are accepting connections. It takes ten minutes to set up a firewall - is it really worth not doing?

Seeing as we’ve come so far, let’s assume you’ve decided that you want a firewall.

Once it finishes installing, we’ll start adding our rules. Run these commands in the shell. Remember to change 30000 to whichever port you chose to run ssh on:

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -d 127.0.0.0/8 -i ! lo -j REJECT --reject-with icmp-port-unreachable  
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 30000 -j ACCEPT    
iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT    
iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT   
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT 
iptables -A INPUT -j REJECT --reject-with icmp-port-unreachable

Once you’ve entered these commands you can see that iptables is fully loaded with:

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; make sure this is what you want. If something goes wrong, you can start again by typing:

/etc/init.d/iptables reload

Once you are happy with the rules, it’s time to save our rules permanently:

/etc/init.d/iptables save

The table is saved to /var/lib/iptables/rules-save if you need to change something in the future, you can edit this file and reload iptables with:

sudo nano /var/lib/iptables/rules-save
/etc/init.d/iptables reload

At the moment iptables won’t be effective when the server boots up. You can check this with:

rc-update show | grep iptables

Notice the different output when checking for ssh:

rc-update show | grep ssh

There are two run levels by default in Gentoo. SSH is an application so it boots in the default run level. iptables is something that a lot of other software may depend on so we want it to load first, and therefore put it in the boot run level like this:

rc-update add iptables boot

You can see all things that will load on boot like this:

rc-update show

When gentoo boots it will run all the scripts in the boot level first, either alphebetically or using the dependency information within the scripts; then it does the same for all the scripts in the default run level.

Logging in as the new user

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

/etc/init.d/sshd reload

Don’t logout yet…

As you have an already established connection you will not be locked out of your ssh session (look at the iptables config file: it accepts already established connections).

On your LOCAL computer, open a new terminal and log in using the administration user (in this case, demo) to the port number you configured in the sshd_config file:

ssh -p 30000 demo@123.45.67.890

Cloud Server also has the excellent ajax console so if it all goes horribly wrong, you can log into your server from the Cloud Server management area.

If all goes well you should login without a password to a plain terminal:

demo@yourvpsname ~ $

Success!

We now know that the firewall and ssh works and we can log in. Now we’ll configure the gentoo ebuild system and get our Server up to date.

Faster Builds

Ok first lets set up our /etc/make.conf. This file contains the settings that the build system uses:

sudo nano /etc/make.conf

Enter your admin user’s password as directed.

First lets make it take advantage of all 4 cpu cores that the server’s server has. Change:

MAKEOPTS="-j2"

to

MAKEOPTS="-j4"

Don’t close the editor yet, there’s one more line to change.

USE Flags

USE flags define how ebuilds are built. They not only affect what libraries to compile against when building something, but also dependencies between ebuilds.

For example setting the postgres USE flag would make the php ebuild depend on the postgresql client libraries, and also affect the parameters passed to the its build process. This gives us a great degree of control over how we install software.

Now lets set our USE flags. There’s already a line there saying USE in /etc/make.conf, we can add our own preferences in there. Putting a ‘-’ (minus) in front of a flag declares that you explicitly don’t want it. There’s a reference to all the USE flags and their meanings here.

You don’t need to set too many, just have a browse through and if any jump out at you, add them to your file. As we look at installing things later we’ll be changing the USE flags some more.

Here’s an example of my preferences:

USE="bash-completion postgres mysql
     -alsa -cups -doc -gnome -gtk -gtk2 -ipv6 -java -kde -oss -qt -sdl -X"

In this example I’m using postgresql and mysql, perhaps you only want mysql, it’s all up to you. You should go through the reference page and choose flags that are appropriate to your setup. Notice I’ve turned off anything to do with a graphical server to keep the bloat down; some packages come with multiple UIs, I only want text based interfaces on my server.

Once you are happy with your choice of USE flags, save the file and exit the editor. Again, don’t worry about spending too much time in here, we will be changing it later as we look at emerging new software.

System Update

Gentoo uses the ‘ebuild’ system to manage software installs, each new ‘package’ or software program availabe for install is called an ‘ebuild’. Lets update our list of available ebuilds from the Gentoo servers:

sudo emerge --sync

At the bottom it will say:

* An update to portage is available. It is _highly_ recommended
 * that you update portage now, before any other packages are updated.
 
 * To update portage, run 'emerge portage' now.

So lets do that now:

sudo emerge portage

Now that we have an up-to-date list of ebuilds available, we should start updating our system:

sudo emerge system --update -vp

The -vp means verbose and pretend. It will now give some information explaining what would happen if you emerge without the -vp. We can use this output to decide if you want to update our USE flags before continuing. My output looked like this, (I’ve word wrapped it so it fits nicely on the page):

These are the packages that would be merged, in order:
 
Calculating system dependencies... done!
[ebuild     U ] sys-apps/net-tools-1.60_p20071202044231-r1 [1.60-r13] USE="nls -static" 180 kB
[ebuild     U ] sys-apps/busybox-1.11.1 [1.8.2] USE="pam -debug -make-symlinks -savedconfig
                (-selinux) -static" 1,880 kB
[ebuild     U ] sys-apps/gawk-3.1.6 [3.1.5-r5] USE="nls" 1,818 kB
[ebuild     U ] app-arch/bzip2-1.0.5-r1 [1.0.5] USE="-static" 822 kB
[ebuild     U ] sys-apps/findutils-4.4.0 [4.3.13] USE="nls (-selinux) -static" 1,983 kB
[ebuild     U ] sys-apps/man-1.6f-r2 [1.6f-r1] USE="nls" 249 kB
[ebuild     U ] sys-devel/automake-1.10.1-r1 [1.10.1] 897 kB
[ebuild     U ] sys-apps/util-linux-2.14.1 [2.13.1.1] USE="crypt nls unicode -loop-aes -old-linux
                (-selinux) -slang (-uclibc)" 2,861 kB
[ebuild     U ] sys-fs/udev-124-r1 [119] USE="(-selinux)" 204 kB
[ebuild     U ] net-misc/rsync-3.0.4 [3.0.2] USE="acl iconv ipv6 -static -xattr -xinetd" 755 kB
[ebuild     U ] net-misc/openssh-5.1_p1-r1 [4.7_p1-r6] USE="pam tcpd -X -X509 -hpn -kerberos -ldap
                -libedit (-selinux) -skey -smartcard -static (-chroot%)" 1,083 kB
[ebuild     U ] sys-apps/man-pages-3.14 [2.80] USE="nls" LINGUAS="-cs -da -de -es -fr -it -ja -nl
                -pl -ro -ru -zh_CN" 1,015 kB
[ebuild  N    ] sys-apps/man-pages-posix-2003a  949 kB
 
Total: 13 packages (12 upgrades, 1 new), Size of downloads: 14,692 kB

Here the U means the software will be upgraded and the N means its a new install. USE flags with a % sign mean the flag is being made available in the version we are about to upgrade to, or if the % is accompanied by brackets it’s becoming unavailable.

For example the (-chroot%) in the openssh line means that in our currently installed version of openssh the chroot USE flag has a meaning but in the version we are upgrading to it is no longer effective nor useful.

If we can’t remember what a certain USE flag does for an ebuild we can ask gentoo. For example to find out what the build flags for openssh mean we can type:

equery uses openssh

I particularly like the sound of the hpn flag, ‘High performance ssh’, before enabling we’ll check with google if it’s really what we want. I came up with this link. Looks good to me.

Instead of enabling that flag for all packages (in /etc/make.conf) we’ll just enable it for the openssh ebuild:

sudo nano /etc/portage/package.use

Add a line like this:

net-misc/openssh hpn

Once that file has been saved, we can see that the output of sudo emerge system -vp is different now. Once you’re happy with what it is planning to do, run it for real:

sudo emerge system --update

This will take some time, so please feel free to go make another coffee.

Updating the Configuration Files

Once it’s done you’ll see that now some of our configuration files need updating. What gentoo does is download the new version of each config file and ask you to merge the differences in. Lets run the command as suggested:

sudo etc-update

It will show you a bunch of configuration files from /etc that need updating. As we’ve updated openssh, our /etc/ssh/sshd_config needs updating. We don’t want to just overwrite it with the new one, but we may want some of the options to be available in it.

In my output, that file is number 4 so I hit 4 and enter; you should type whatever number it is listed under in your output.

Now it shows the differences between both the files; lines to be added have a + in front, and - for lines that are to be deleted. This listing of the changes is to give you a preview of what comes next. You can get to the next page by hitting the space bar, once you get down to the bottom hit q to exit the difference listing.

Now you’ll be presented with a list of options. Choose 3) Interactively merge original with update (hit 3 and enter). Now for each line that is different you’ll be asked to choose which line you want to keep, and also have the oppurtunity to edit the line. Hit ? and enter to get further instructions on how to merge in the changes.

The first line is the banner, telling the version of the file. We want to keep the updated version of that so type r and enter to keep the ‘right’ hand version.

The changes on the left side are the ones in your current config file, on the right side are the changes that gentoo wants to make. Basically you want to keep anything that you’ve set, such as the Port and the AllowedUsers, and bring in all the new lines.

If you make a mistake, you can hit q for quit (from the merge program), then choose 3) Remerge original with update to start the merge process again for this file. If you totally panic, after quitting the merge program you can hit ctrl+c (Hold ctrl and hit c); this will take you back to the linux prompt, and you can start again with sudo etc-update.

Once you’ve been through the changes and you’re confident about your choices, choose 1) Replace /etc/ssh/sshd_config with merged file. You could also edit the config file to go through it one more time if you would like. Follow the prompts to finish setting up the new /etc/ssh/sshd_config. You can type y and enter for yes or n and enter for no.

In this case we know we haven’t changed any of the other files, so just type -5 and enter to auto update them all.

It wouldn’t hurt to do a reboot once all the config files are updated. We should at least get the new openssh server to running. Don’t worry it won’t log you out:

sudo /etc/init.d/sshd restart

Upgrade applications

Now that we’ve upgraded the system level apps, lets see what will happen when we upgrade the higher level apps:

sudo emerge world --update -vp

Adjust your USE flags as you deem appropriate again, then run it for real with out the -vp.

Once you’ve run it, you’ll need to go through the etc-update process again. On my install I had to merge the changes for the /etc/sudoers file to keep that wheel group with sudoers access.

Security

Finally we’ll want to check for any known security issues on our server. Gentoo has a great service called the Gentoo Linux Security Advisory. When a known security problem becomes apparent in a gentoo package, it’s added to the glsa list.

We’ll use the glsa-check tool to see if there are any known security updates with our current setup:

sudo glsa-check -tv all

In my case I have two security announcements that affect my server. The output looks like this:

This system is affected by the following GLSAs:
200807-16 ( Python: Multiple vulnerabilities ) 
200812-06 ( libxml2: Multiple vulnerabilities )

You can find out more about what is affecting your system by searching for the announcement number in the glsa listing page and clicking on it’s link.

You could follow the instructions in the page manually to fix the security problem, or we could get it all done automatically:

sudo glsa-check -fv affected

It will now proceed to fix all security vunerabilities mentioned in the glsa that affect your server.

Quick Searches

Finally I’d like to introduce a great Gentoo tool; esearch.

The esearch tool lets you search for ebuilds to install using a cached indexing system that is much faster than a standard emerge --search something.

Lets install esearch :

sudo emerge esearch
sudo eupdatedb

This will take quite some time; but will save us a lot of time in searching for ebuilds in the future.

From now on, we can update esearch's indexes and update our list of available ebuilds with a single command:

sudo esync

This is the equivalent of:

sudo emerge --sync && sudo eupdatedb

Now to give you an example of how to use it, lets search for something. If you’re search for the name of a specific package, you might want to leave the -S flag off. The -S flag makes it search through the package descriptions as well as the names:

esearch apache
esearch -S mail.*server

The search string is a regular expresssion. So mail.*server will match any ebuild description with the pattern server, following the pattern mail, with anything in between. The . means any charater and the * means zero or more of the character before.

Well done, you now have an up to date and more secure Gentoo Server ready to be loaded up with your server software.