• Sales: 1-800-961-2888
  • Support: 1-800-961-4454

Ubuntu - Setup


This article will walk you through setting up your Ubuntu Cloud Server. For our example server we will be using Ubuntu 9.10 (Karmic).

Contents

//

Log in

Windows Clients

If you are logging into your server from Windows you can use a terminal application called PuTTY. Simply do a Google search for it and you will find where to download it.

Mac / Linux Clients

Simply type in the command below from a Terminal window to login:

# ssh root@12.34.56.78

If this is a reinstall you may have to delete your ~/.ssh/known_hosts file. Please refer to your Operating Systems documentation on how to resolve this.

User administration

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

# passwd

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

# adduser demo

You'll be prompted for the password as well as basic user information.

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 he can, with a password, complete administrative tasks.

To do this, we're going to add the main user to the 'sudo' group. Once that is done, we need to edit the 'sudoers' file, using visudo, and ensure the 'sudo' group has the correct privileges.

So firstly, add the user to the sudo group:

# usermod -a -G sudo demo

Next, give the 'visudo' command:

# visudo

Near the bottom of the file you will see this group of text:

# Uncomment to allow members of group sudo to not need a password
# (Note that later entries override this, so you might need to move
# it further down)
# %sudo ALL=NOPASSWD: ALL

Simply add the following line just under the text above:

## Allows people in group wheel to run all commands
%sudo  ALL=(ALL)       ALL

Save the file by pressing CTRL-X on your keyboard, followed by Y and Enter. Now members of the 'sudo' group have full sudo privileges. You can test this by opening up another SSH session and logging in as the demo user trying to get to a root shell prompt by typing sudo su - and pressing Enter. You will be prompted for the demo password.

Updating Apt

Ubuntu comes with a fully functional package manager called Apt, or apt-get. Ubuntu can also use a program called Aptitude, but it's not always installed on Ubuntu by default.

The first thing we'll need to do is update our cache by running the following command:

# apt-get update

Once you have been returned to the console you'll need to upgrade the packages on your server to keep it secure. Run the following command to upgrade your packages:

# apt-get upgrade

You'll be prompted to confirm the upgrade, press Y followed by Enter.

Basic Firewall

Now it is time to setup a basic firewall. For this tutorial we'll use a great Ubuntu article as the basis for our basic firewall. You can find this article here: https://help.ubuntu.com/community/IptablesHowTo

The following steps will setup each part of a basic firewall configuration. Once we have all of the rules applied we'll save the rules and set them to start up at boot.

Allow established connections

The first thing we need to do is allow any established traffic to come into the server. This will allow our SSH traffic to continue functioning while we work on our firewall. Type the following command:

# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Allow SSH traffic

Next we need to include a rule to enable SSH traffic. Type the following rule to allow incoming SSH connections:

# iptables -A INPUT -p tcp --dport ssh -j ACCEPT

If we were to look at our rules at this point by typing iptables -L we would see something like this:

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

While this looks like it may be complete, we still need to add a few additional rules. Let's continue on...

Allow HTTP traffic (optional)

If you intend to host a web server you will need to include a rule to accept HTTP (port 80) traffic. Type the following rule to do this:

# iptables -A INPUT -p tcp --dport 80 -j ACCEPT

Note: You will still be required to install a web server such as Apache!

Drop all remaining traffic

Now we need to setup our final rule to drop all remaining traffic that is not destined for our server.

# iptables -A INPUT -j DROP

Allow loopback traffic

Now that we've worked on the rules for our external traffic we need to allow internal loopback traffic for inter-server communication. Type the following rule to allow this:

# iptables -I INPUT 1 -i lo -j ACCEPT

Check your rules

Now if we look at our rules by typing iptables -L -v you should see something similar to this:

# iptables -L -v
Chain INPUT (policy ACCEPT 355 packets, 26896 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  lo     any     anywhere             anywhere            
  323 24560 ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED 
    1    48 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:ssh 
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:www 
    0     0 DROP       all  --  any    any     anywhere             anywhere 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 372 packets, 38968 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Saving your rules

Now that we have a basic firewall configuration we need to go ahead and save it. The command iptables-save will save your IPtables configuration. By default it will send it to the console so we need to 'pipe' it to a file. Type the following to save the file to /etc/iptables.rules:

# iptables-save > /etc/iptables.rules

Set your rules to apply at boot

Finally we need to make sure that our iptables rules are applied when we boot up the server. The method that Ubuntu suggests is to apply them to your interfaces file but because of the tight integration with our Control Panel we do not recommend that. Our suggested method is to create a service that applies the rules.

To create the startup service file type the following command:

# nano /etc/network/if-pre-up.d/iptaload

You'll see the nano text editor load up. Paste in the following text:

#!/bin/sh
iptables-restore < /etc/iptables.rules
exit 0

Save the file by pressing CTRL-X, then Y and Enter.

Next we need to create a service that will run when the server is shut down. This file will save our rules so any changes we have made will be applied at next boot. Type the following to create the service file:

# nano /etc/network/if-post-down.d/iptasave

Once the nano editor has appeared, paste in the following text:

#!/bin/sh
iptables-save -c > /etc/iptables.save
if [ -f /etc/iptables.downrules ]; then
   iptables-restore < /etc/iptables.downrules
fi
exit 0

Save the file as you did before.

Now we need to make sure these scripts are executable. Type the following:

# chmod +x /etc/network/if-post-down.d/iptasave
# chmod +x /etc/network/if-pre-up.d/iptaload

Test your setup

You may reboot your server and run iptables -L to make sure that your firewall rules applied successfully.

--Kelly Koehn 10:41, 11 February 2010 (CST)



© 2011-2013 Rackspace US, Inc.

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License


See license specifics and DISCLAIMER

6 Comments

#!/bin/sh
if [ -f /etc/iptables.downrules ]; then <--- if there is a file name iptables.downrules This will fail since in the else clause the rules are being saved in iptables.save. Unless otherwise there is a magical way of either renaming the file or copying the contents to iptables.downrules
iptables-restore < /etc/iptables.downrules <--- restore from iptables.downrules
fi
iptables-save -c > /etc/iptables.save <--- Save the rules to the file iptables.save
exit 0

if there is a file name iptables.downrules, then. (This will fail since in the else clause the rules are being saved in iptables.save. Unless otherwise there is a magical way of either renaming the file or copying the contents to iptables.downrules)

The reference to iptables.downrules comes from the [Ubuntu article](https://help.ubuntu.com/community/IptablesHowTo) referenced in this write-up. It's okay that the file doesn't actually exist - since that "-f" check returns "false", the script won't try to do anything with it and you'll get no error.

The idea behind that part of the script in the original article is that you can have a set of rules applied when the interface goes down (an empty ruleset, for example). Curiously, the script we present here has it backwards. In the original referenced article the script saves the rules first, *then* applies the downrules.

I'll switch that back around for now. We intend to revisit these articles and clean them up a bit anyway, and I expect we'll take out the downrules reference entirely. Clearing the rules isn't really necessary - they wouldn't be doing anything when the interface is down, and when it's brought up any rules would be overwritten by the main iptables-restore.

(1) One wonders if there isn't unnecessary complexity in juggling several files and scripts. Although the scenario does work, the process is nearly inscrutable, and if something happens to the iptables.save file, or if the script is interrupted and it does not update the file from which IPTables must be restored on boot, then the server could start with the "default" (undesirable) rule set.

[a] Would not a crontab line work just as well:
@reboot root /sbin/iptables-restore < /etc/iptables.rules

[b] Would making your ruleset the "default" be safer?

I think more options need to be explored here. These are just ideas, they have not been tested.


(2) A wise think to do while experimenting with IPTables is to add one of the following to crontab:

This will flush the rules every 10 minutes to keep you from locking yourself out of the server.
*/10 * * * * root /sbin/iptables -F

This will refresh IPTables with a custom default ruleset every 10 minutes.
*/10 * * * * root /sbin/iptables-restore < /etc/iptables.rules_custom

Hope this helps, and/or, provides food for thought.

On 1: By tying the iptables restore/save to the ifup and ifdown scripts, it actually does more than make sure the state is saved between reboots. It makes sure iptables will be in the state you want every time networking is restarted (which can happen outside a reboot). Basically it covers more eventualities than simply setting up a cronjob or init script to handle iptables.

There isn't a "default" ruleset, I don't think, on Ubuntu - just the ruleset you save and restore from. On the whole this approach is very similar to what you'll find in the [Ubuntu docs for iptables](https://help.ubuntu.com/community/IptablesHowTo).

On 2: Nice recommendation. If you're using a Cloud Server you also have rescue mode or the console to help you recover from an iptables problem, letting you either change the rules in the config file or to flush the tables to let you reconnect.

The most simple safeguard is to make sure you don't log out when you're playing with iptables - in most cases if you open a new ssh connection while leaving your original connection in place, you'll be able to use the original session to fix any problems.

One necessary note. Apache makes the default virtual host on an ip address by the first named virtual host on the ip address. Using the 'Include vhost.d/*.conf' method this means that the first virtual host in the alphabet is the default. So, if you need to cause a virtual host to be the first ensure it by prefixing '000-default-' to the virtual host configuration file name. So 'domain.com.conf' becomes '000-default-domain.com.conf'. Reload apache and all is well.

Add new comment