Securing Your Ubuntu Server

February 1st, 2007

Improving the security of your fresh VPS or dedicated server running Ubuntu should be your first real task to accomplish. Having it done, you'll have less trouble later on keeping script kiddies off your server. Follow the instructions below to improve your SSH security and set up a simple firewall.

Ready, steady, go!

All the tasks were performed on my Ubuntu 6.06-based VPS from Slicehost, but they should be easily replicable on any other server running Ubuntu or similar, Debian-derived distro.

Improve SSH Security

Steps up to Disable SSH root access may not be necessary if you have root account disabled already (plain Ubuntu install should have). Follow them if your hosting provider uses a custom Ubuntu setup (Slicehost does).

First step is changing your default root password.

matid@local:~$ ssh root@server
root@server's password:
root@server:~# passwd

Choose a hard-to-guess password and keep it save just for maintenance - you shouldn't be using it more than once.

OK - let's create an administrative user we'll use to manage our server:

root@server:~# adduser --ingroup users 

You'll be asked for password and some other, optional data. Please keep in mind that it's the account you'll use frequently, so having a strong password is a must.

Now we need to assign it necessary privileges (we won't use root account anymore).

root@server:~# visudo

A text editor (nano, not vim - don't worry) will pop up. Add the following line at the end to give your user root privileges:

 ALL=(ALL) ALL

You should now check if you can use sudo with your brand new account:

root@server:~# exit
matid@local:~$ ssh server
matid@server's password:
matid@server:~$ sudo cat /etc/shadow

If you see roughly 20 lines of text from /etc/shadow everything is going smoothly.

Disable SSH root access

Now let's disable SSH root access by editing /etc/ssh/sshd_config, finding a PermitRootLogin line and changing it from yes to no. You can also change your Port from 22 to a different one - it should keep off some script kiddies and bots for a while.

Now restart SSH daemon and start feeling a bit more secure:

matid@server:~$ sudo invoke-rc.d ssh restart

Setting up a Firewall

This is also a very important step - it can save you from various hacking attempts in the future, and - it's not as hard as it may seem:

matid@server:~$ sudo apt-get install shorewall

After a while we have an iptables-based firewall ready for tweaking. Configuration files are located in /etc/shorewall and as access to this directory is denied for a normal user, we'll use administrative shell to avoid typing sudo all the time:

matid@server:~$ sudo -i
Password:
root@server:~# cd /etc/shorewall

We'll now copy some default files from /usr/share/:

root@server:/etc/shorewall# cp /usr/share/doc/default-config/interfaces .
root@server:/etc/shorewall# cp /usr/share/doc/default-config/policy .
root@server:/etc/shorewall# cp /usr/share/doc/default-config/rules .
root@server:/etc/shorewall# cp /usr/share/doc/default-config/zones .

We have to specify our network interface in /etc/shorewall/interfaces, so open it with your favourite editor and add the following line at the bottom:

net eth0 detect

Let's also add a default zone to /etc/shorewall/zones by appending this line:

net ipv4

OK, here comes the security - edit /etc/shorewall/policy and block all remote access by adding these lines to the end of the file:

fw net ACCEPT
net all DROP info
all all REJECT info

These settings will allow all outgoing transfer, drop all packages coming from outside and reject all that's left. Yet, this will also lock SSH connections, leaving us in trouble, so let us take care of /etc/shorewall/rules file:

ACCEPT net fw tcp 22 # Replace 22 with your SSH port if you changed it before

If you're planning to run WWW server you have to add:

ACCEPT net fw tcp 80

As you can see, adding custom rules is not that difficult at all. The last thing to do before actually starting our firewall is editing /etc/default/shorewall, and replacing:

startup=0
with
startup=1

Our simple firewall is now ready to start with:

matid@server:~$ sudo invoke-rc.d shorewall start

After completing these simple steps you have a secure Ubuntu server up and running. Don't forget about upgrading it frequently and enjoy!

11 Responses to “Securing Your Ubuntu Server”

  1. tonfa Says:

    I think it is a bad idea to change the root password, since by default Ubuntu doesn’t have any (’*’ in /etc/shadow). So by default nobody can log in as root with a password, whereas if you set it someone can try to su to root.

  2. dAniel hAhler Says:

    IMHO it’s better to not enable “sudo” for your normal user, but use “su -” and the root user instead. This way, if your “normal user” does get compromised it cannot get abused for doing things which only root can do (by using sudo).

  3. matid Says:

    SliceHost enabled root account be default, and hence my instructions on disabling it. Anyway, as you’ve noticed, adding an notice that it may not be necessary is a good idea.

  4. matid Says:

    Daniel: It really depends on what your attitude towards sudo is – some consider it safer than using root account and some not. Actually, both should be quite safe if you disable disable ssh root access. I’ll also add a paragraph about certificate-based login, which also should be good for your server’s sake.

  5. Matthew East Says:

    Hi! If you’re interested and knowledgeable about server security, you might be interested in reviewing or contributing to the Ubuntu Server Guide:

    http://doc.ubuntu.com/ubuntu/serverguide/C/index.html

    Have a read, and have a look at https://wiki.ubuntu.com/DocumentationTeam if you’re interested in contributing!!

  6. Jeff Schroeder Says:

    sudo -s is a bad idea, if you are in your own $HOME, it has a tendency to create root owned files because it keeps your environment instead of reading root’s environment. sudo -i is the proper way of doing that.

    Also, root ssh login is ok as long as you disable password authentication. As a matter of fact, key based authentication is infinitely more secure than a password (unless you have 1024+ bit passwords).

    Something you forgot… Enabling sshd to only accept protocol 2 ssh traffic. The sshv1 protocol is completely suceptible to man-in-the-middle attacks and deemed insecure by the powers that be. Protocol 2

    You might also take a look at a script I wrote to secure Ubuntu but note that it doesn’t install ssh or “secure” it. However, it does do a bit of hardening and some of the ideas from it might help this post. http://www.digitalprognosis.com/opensource/scripts/lockdown-ubuntu.sh.txt

    Good post btw, we need more security related info to go out to the less seasoned Linux crowd.

  7. Jonathan Lozinski Says:

    Hi, The other way of being paranoid and protecting yourself script kiddies is to disable outgoing traffic too. Why would the server need it. Then open maybe smtp for the sever to send, and whatever outgoing connections it needs

    In particular only allow http to your apt repositories and whatever other minor known sites. This prevents the script in the event of a brute force or whatever doing a wget http://site.com/rootkit.tar.bz2 automatically.

    Yes if the account is forced they can pretty much disable stuff like this, but the scripts won’t be able to without intervention, and maybe the script just forced regular access and needs to break into root using the download. Stopping this can minimise the damage.

  8. matid Says:

    Jeff: You’re right about sudo -s, I modified the article to suggest sudo -i instead. And you don’t have to disable SSH1 traffic – it’s done by default.

  9. mike Says:

    Also I would recommend to install “fail2ban”.

    Very nice tool

  10. nicolas Says:

    Thanks for the great post. I used this to fortify my dad’s PC. With your instruction to copy the config files in your post, you forgot to put shorewall between /usr/share/doc and default-config.

  11. matid Says:

    nicolas: Glad my post was helpful and thanks for pointing out a typo. Now I have to look up how to fix it without this entry topping Ubuntu Planet again :)

Sorry, comments are closed for this article.