Shadows of epiphany

LXC Configure Debian Containers

bodhi.zazen — Wed, 24 Feb 2010 07:16:20 +0000

I have been taking Linux Containers for a spin and was advised on IRC that Debian was easier to configure then Ubuntu, so decided to give it a try.

I will again use debootstrap to make a root file system (rootfs) for a LXC container using Debian. These instructions work with both Lenny and Squeeze.

Commands in this tutorial are run as root, so to obtain a root shell use:

sudo -i

The working directory for this tutorial is /home/bodhi/lxc , so config.lenny and rootfs.lenny are both located in /home/bodhi/lxc

Make a rootfs via debootstrap

debootstrap –variant=minbase lenny rootfs.lenny # two – - in front of “- -variant”

Configure the container

Copy resolv.conf from host node to container

cp /etc/resolv.conf rootfs.lenny/etc

Generate a config file

I call it config.lenny . Make sure the following information is accurate:

container name (lxc.utsname)
network (lxc.network.ipv4)
rootfs (lxc.rootfs)
lxc.utsname = lenny lxc.tty = 4 lxc.network.type = veth lxc.network.flags = up lxc.network.link = br0 lxc.network.name = eth0 lxc.network.mtu = 1500 lxc.network.ipv4 = 192.168.0.0/24 lxc.rootfs = /home/bodhi/lxc/rootfs.lenny lxc.cgroup.devices.deny = a # /dev/null and zero lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm # consoles lxc.cgroup.devices.allow = c 5:1 rwm lxc.cgroup.devices.allow = c 5:0 rwm lxc.cgroup.devices.allow = c 4:0 rwm lxc.cgroup.devices.allow = c 4:1 rwm # /dev/{,u}random lxc.cgroup.devices.allow = c 1:9 rwm lxc.cgroup.devices.allow = c 1:8 rwm # /dev/pts/* - pts namespaces are "coming soon" lxc.cgroup.devices.allow = c 136:* rwm lxc.cgroup.devices.allow = c 5:2 rwm # rtc lxc.cgroup.devices.allow = c 254:0 rwm

Modify the rootfs

chroot into rootfs.ubuntu and configure

chroot rootfs.lenny

apt-get update

# set locales
echo “en_US.UTF-8 UTF-8″ > /etc/locale.gen
apt-get -y install locales

# Add a few applications, including openssh-server
apt-get install -y adduser apt-utils iproute netbase nano openssh-blacklist openssh-blacklist-extra openssh-server console-setup sudo iputils-ping

#Set a root passwd
passwd

# As an alternate to setting a root password, you may of course add a new user and configure sudo.

#exit chroot
exit

Edit /etc/inittab

Using any editor (nano, vim), open rootfs.lenny/etc/inittab and comment out the following two lines:

#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6

Configure networking

edit rootfs.lenny/etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.61
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1

Squeeze only – make a few devices

cd into rootfs.squeeze/dev and run :

mknod -m 666 tty1 c 4 1
mknod -m 666 tty2 c 4 2
mknod -m 666 tty3 c 4 3
mknod -m 666 tty4 c 4 4

Configure and start the container

Create the container:

lxc-create -f /home/bodhi/lxc/conf.lenny -n lenny
lxc-start -n lenny

You should now be able to access the container with either lxc-console or ssh

ssh root@192.168.0.61

lxc-console -n lenny

Assuming you get no error messages , you may start the container with the -d option

lxc-start -d -n lenny

LXC Configure Ubuntu Karmic Containers

bodhi.zazen — Wed, 17 Feb 2010 07:50:29 +0000

This post is in follow up to my previous post on configuring Ubuntu Lucid (10.04) LXC containers and in this post I will show you how to configure an Ubuntu Karmic (9.10) LXC container.

I will again use debootstrap to make a root file system (rootfs) for a LXC container using Ubuntu Karmic (9.10).

Commands in this tutorial are run as root, so to obtain a root shell use:

sudo -i

The working directory for this tutorial is /home/bodhi/lxc , so config.ubuntu and rootfs.ubuntu are both located in /home/bodhi/lxc

Make a rootfs via debootstrap

debootstrap –variant=minbase karmic rootfs.ubuntu # two – - in front of “- -variant”

Configure the container

Copy resolv.conf from host node to container

cp /etc/resolv.conf rootfs.ubuntu/etc

Fix devices in rootfs.ubuntu/dev

udev does not run in lxc containers, so you need to manually make the needed devices.

I use this script to configure the devices:
#!/bin/bash # bodhi.zazen's lxc-config # Makes default devices needed in lxc containers # modified from http://lxc.teegra.net/ ROOT=$(pwd) DEV=${ROOT}/dev if [ $ROOT = '/' ]; then printf "\033[22;35m\nDO NOT RUN ON THE HOST NODE\n\n" tput sgr0 exit 1 fi if [ ! -d $DEV ]; then printf "\033[01;33m\nRun this script in rootfs\n\n" tput sgr0 exit 1 fi rm -rf ${DEV} mkdir ${DEV} mknod -m 666 ${DEV}/null c 1 3 mknod -m 666 ${DEV}/zero c 1 5 mknod -m 666 ${DEV}/random c 1 8 mknod -m 666 ${DEV}/urandom c 1 9 mkdir -m 755 ${DEV}/pts mkdir -m 1777 ${DEV}/shm mknod -m 666 ${DEV}/tty c 5 0 mknod -m 666 ${DEV}/tty0 c 4 0 mknod -m 666 ${DEV}/tty1 c 4 1 mknod -m 666 ${DEV}/tty2 c 4 2 mknod -m 666 ${DEV}/tty3 c 4 3 mknod -m 666 ${DEV}/tty4 c 4 4 mknod -m 600 ${DEV}/console c 5 1 mknod -m 666 ${DEV}/full c 1 7 mknod -m 600 ${DEV}/initctl p mknod -m 666 ${DEV}/ptmx c 5 2 exit 0

The script is very slightly modified from This page and is saved in /usr/local/bin/lxc-config .

Make it executable :

chmod u+x /usr/local/bin/lxc-config

Run the script in rootfs.ubuntu

cd rootfs.ubuntu
/usr/local/bin/lxc-config # fix /dev

Generate a config file

I call it config.ubuntu . Make sure the following information is accurate:

container name (lxc.utsname)
network (lxc.network.ipv4)
rootfs (lxc.rootfs)
lxc.utsname = ubuntu lxc.tty = 4 lxc.network.type = veth lxc.network.flags = up lxc.network.link = br0 lxc.network.name = eth0 lxc.network.mtu = 1500 lxc.network.ipv4 = 192.168.0.0/24 lxc.rootfs = /home/bodhi/lxc/rootfs.ubuntu lxc.cgroup.devices.deny = a # /dev/null and zero lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm # consoles lxc.cgroup.devices.allow = c 5:1 rwm lxc.cgroup.devices.allow = c 5:0 rwm lxc.cgroup.devices.allow = c 4:0 rwm lxc.cgroup.devices.allow = c 4:1 rwm # /dev/{,u}random lxc.cgroup.devices.allow = c 1:9 rwm lxc.cgroup.devices.allow = c 1:8 rwm # /dev/pts/* - pts namespaces are "coming soon" lxc.cgroup.devices.allow = c 136:* rwm lxc.cgroup.devices.allow = c 5:2 rwm # rtc lxc.cgroup.devices.allow = c 254:0 rwm

Modify the rootfs

chroot into rootfs.ubuntu and configure

chroot rootfs.ubuntu

# mount /proc /sys and /dev/pts
mount -t devpts devpts /dev/pts
mount -t proc proc /proc
mount -t sysfs sysfs /sys

apt-get install --force-yes -y gpgv # two - - in front of "--force-yes"
apt-get update

# set locales
apt-get install -y language-pack-en
update-locale LANG=”en_US.UTF-8″ LANGUAGE=”en_US.UTF-8″ LC_ALL=”en_US.UTF-8″

# Add to the installed applications
apt-get install -y adduser apt-utils iproute netbase nano openssh-blacklist openssh-blacklist-extra openssh-server console-setup sudo ping

#Remove udev
apt-get remove --purge udev # two – - in front of “--purge”
rm -rf /etc/udev /lib/udev
apt-get autoremove

#Remove a few upstart scripts
cd /etc/init
rm mountall* upstart*

#Set a root passwd
passwd

# As an alternate to setting a root password, you may of course add a new user and configure sudo.

#unmount /proc /sys and /dev/pts
umount /dev/pts
umount /proc
umount /sys

#exit chroot
exit

Configure networking

edit rootfs.ubuntu/etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.61
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1

Remove tty 5 & 6

rm rootfs.ubuntu/etc/init/tty{5,6}.conf

Fix /var/run/network/ifstate

mkdir -p rootfs.ubuntu/var/run/network
touch rootfs.ubuntu/var/run/network/ifstate

Add an upstart script to boot karmic

Save the following script as rootfs.ubuntu/etc/init/lxc.conf
# LXC – Fix init sequence to have LXC working with upstart # description “Fix LXC container - Karmic” start on startup task pre-start script mount -t proc proc /proc mount -t devpts devpts /dev/pts mount -t sysfs sys /sys mount -t tmpfs varrun /var/run mount -t tmpfs varlock /var/lock mkdir -p /var/run/network touch /var/run/utmp chmod 664 /var/run/utmp chown root.utmp /var/run/utmp if [ "$(find /etc/network/ -name upstart -type f)" ]; then chmod -x /etc/network/*/upstart || true fi end script script start networking initctl emit filesystem --no-wait initctl emit local-filesystems --no-wait initctl emit virtual-filesystems --no-wait init 2 end script

Configure and start the container

Create the container:

lxc-create -f /home/bodhi/lxc/conf.ubuntu -n ubuntu
lxc-start -n ubuntu

You should now be able to access the container with either lxc-console or ssh

ssh root@192.168.0.61

lxc-console -n ubuntu

Assuming you get no error messages , you may start the container with the -d option

lxc-console -d -n ubuntu

Note: Unlike lucid (Ubuntu 10.04) I am able to start the container with the -d option (lxc-start -d -n karmic),

LXC Configure Fedora Containers

bodhi.zazen — Tue, 02 Feb 2010 16:09:19 +0000

In this post I will demonstrate how to use febootstrap to make a root file system (rootfs) for a LXC container using Fedora. This technique is working with Fedora 12 and rawhide. Rawhide is under development and will become Fedora 13, so use a rawhide container at your own risk.

Most of the commands in this tutorial are run as root. To obtain a root shell use:

su -

The working directory for this tutorial is /home/bodhi/lxc , so config.fedora and rootfs.fedora are both located in /home/bodhi/lxc

Note: Unless you are familiar with selinux, it may be helpful to disable selinux as you learn to use Linux Containers.

setenforce 0

Make a rootfs via febootstrap

# Fedora 12
febootstrap fedora-12 rootfs.fedora

# Rawhide
febootstrap rawhide rootfs.fedora

Configure the rootfs

Copy resolv.conf from host node to container

cp /etc/resolv.conf rootfs.fedora/etc

Fix devices

udev does not run in lxc containers, so you need to manually make the needed devices.

The script is very slightly modified from This page and is saved in /usr/local/bin/lxc-config .

Make it executable :

chmod u+x /usr/local/bin/lxc-config

Run the script in rootfs.fedora

cd rootfs.fedora
/usr/local/bin/lxc-config # fix /dev

Generate a config file

I call it config.fedora . Make sure the following information is accurate:

container name (lxc.utsname)
network (lxc.network.ipv4)
rootfs (lxc.rootfs)
lxc.utsname = fedora lxc.tty = 4 lxc.network.type = veth lxc.network.flags = up lxc.network.link = br0 lxc.network.name = eth0 lxc.network.mtu = 1500 lxc.network.ipv4 = 192.168.0.0/24 lxc.rootfs = /home/bodhi/lxc/rootfs.fedora lxc.cgroup.devices.deny = a # /dev/null and zero lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm # consoles lxc.cgroup.devices.allow = c 5:1 rwm lxc.cgroup.devices.allow = c 5:0 rwm lxc.cgroup.devices.allow = c 4:0 rwm lxc.cgroup.devices.allow = c 4:1 rwm # /dev/{,u}random lxc.cgroup.devices.allow = c 1:9 rwm lxc.cgroup.devices.allow = c 1:8 rwm # /dev/pts/* - pts namespaces are "coming soon" lxc.cgroup.devices.allow = c 136:* rwm lxc.cgroup.devices.allow = c 5:2 rwm # rtc lxc.cgroup.devices.allow = c 254:0 rwm

Fix rootfs

touch rootfs.fedora/var/run/syslogd.pid
mkdir -p rootfs.fedora/var/lock/subsys
touch rootfs.fedora/var/lock/subsys/{atd,ip6tables,iptables,local,network,rsyslogd,sshd}

Disable udev

rm rootfs.fedora/etc/init.d/udev-post

edit rootfs.fedora/etc/rc.sysinit and comment out the start_udev line

# /sbin/start_udev

Set up fstab and mtab

touch rootfs.fedora/etc/{fstab,mtab}
echo "none /dev/pts devpts defaults 0 0" >> rootfs.fedora/etc/fstab

Configure networking

eth0

Using any editor, edit rootfs.fedora/etc/sysconfig/networking-scripts/ifcfg-eth0

set your ipaddress in this file, either via static or dhcp (I use static IP)

DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
HOSTNAME=fedora
TYPE=Ethernet
IPADDR=192.168.0.20
NETWORK=192.168.0.0
GATEWAY=192.168.0.1
BROADCAST=192.168.0.255
NETMASK=255.255.255.0
MTU=1500
DNS1=192.168.0.1
IPV6INIT=no
USERCTL=no

Using any editor, edit rootfs/etc/sysconfig/network

Add these two lines (adjust hostname):

NETWORKING=yes
HOSTNAME=fedora

Using any editor, edit rootfs/etc/rc.local

Add (was necessary to bring up the network in my Fedora containers).

service network restart

Remove tty5 and tty6

Fedora 12

cd rootfs.fedora/etc/event.d
rm tty{5,6}

Radhide: edit rootfs.fedora/etc/sysconfig/init

The very last line of the file reads "ACTIVE_CONSOLES=/dev/tty[1-6]" , change this to

ACTIVE_CONSOLES=/dev/tty[1-4]

Chroot and set a root password

chroot rootfs.fedora /bin/bash
passwd

Configure and start the container

lxc-create -f ~bodhi/lxc/config.fedora -n fedora

Disable selinux (on the host

setenforce 0

Start the container, watch for error messages

lxc-start -n fedora

Note: It takes some time for the container to boot ...

lxc-console or ssh in and set a locale

lxc-console -n fedora

In the container run:

yum -y reinstall glibc-common

#auditd is not woking, so turn it off
chkconfig auditd off

#sendmail is slow to start, so if you are not using it disable it
chkconfig sendmail off

Clean up container

From within the container

yum clean all

Stop the container

lxc-stop -n fedora

Optional : Clean unnecessary files

remove the febootstrap cache (if it exists). You may remove the shared doc and locales.

rm -rf rootfs/var/yum/cache/febootstrap
rm -rf rootfs/usr/share/locale/*
rm -rf rootfs/usr/share/doc/*

LXC Configure Ubuntu Lucid Containers

bodhi.zazen — Tue, 02 Feb 2010 16:09:19 +0000

In this post I will demonstrate how to use debootstrap to make a root file system (rootfs) for a LXC container using Ubuntu Lucid (10.04).

Note: At the time of this post, Lucid (Ubuntu 10.04) is in the Alpha stage of development. As with all development releases, breakage may occur.

Commands in this tutorial are run as root, so to obtain a root shell use:

sudo -i

The working directory for this tutorial is /home/bodhi/lxc , so config.ubuntu and rootfs.ubuntu are both located in /home/bodhi/lxc

Make a rootfs via debootstrap

debootstrap –variant=minbase lucid rootfs.ubuntu # two – - in front of “- -variant”

Configure the container

Copy resolv.conf from host node to container

cp /etc/resolv.conf rootfs.ubuntu/etc

Fix devices in rootfs.ubuntu/dev

udev does not run in lxc containers, so you need to manually make the needed devices.

The script is very slightly modified from This page and is saved in /usr/local/bin/lxc-config .

Make it executable :

chmod u+x /usr/local/bin/lxc-config

Run the script in rootfs.ubuntu

cd rootfs.ubuntu
/usr/local/bin/lxc-config # fix /dev

Generate a config file

I call it config.ubuntu . Make sure the following information is accurate:

Modify the rootfs

chroot into rootfs.ubuntu and configure

chroot rootfs.ubuntu

apt-get install --force-yes -y gpgv # two - - in front of "--force-yes"
apt-get update

# set locales
apt-get install -y language-pack-en
update-locale LANG=”en_US.UTF-8″ LANGUAGE=”en_US.UTF-8″ LC_ALL=”en_US.UTF-8″

# Add to the installed applications
apt-get install -y adduser apt-utils iproute netbase nano openssh-blacklist openssh-blacklist-extra openssh-server console-setup sudo ping

#Set a root passwd
passwd

# As an alternate to setting a root password, you may of course add a new user and configure sudo.

#exit chroot
exit

Configure networking

edit rootfs.ubuntu/etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.60
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1

Remove tty4, 5, & 6

rm rootfs.ubuntu/etc/init/tty{4,5,6}.conf

Fix /var/run/network/ifstate

mkdir -p rootfs.ubuntu/var/run/network
touch rootfs.ubuntu/var/run/network/ifstate

Add a directory to allow ssh user privilege separation

mkdir -p rootfs.ubuntu/var/run/sshd

Edit rootfs.ubuntu/lib/init/fstab

Using any editor, open rootfs.ubuntu/lib/init/fstab and comment out the following lines:

#none /proc proc nodev,noexec,nosuid 0 0
#none /sys sysfs nodev,noexec,nosuid 0 0
#none /dev devtmpfs,tmpfs mode=0755 0 0

Edit rootfs.ubuntu/etc/init/rc-sysinit.conf

Using any editor, open rootfs.ubuntu/etc/init/rc-sysinit.conf, look for the line
start on filesystem and net-device-up IFACE=lo

and change it to

start on filesystem # and net-device-up IFACE=lo

Add an init (upstart) script

Using any editor, make a file rootfs.lucid/etc/init/lxc.conf and add:
# LXC – Fix init sequence to have LXC containers boot with upstart # description “Fix LXC container - Lucid” start on startup task pre-start script mount -t proc proc /proc mount -t devpts devpts /dev/pts mount -t sysfs sys /sys mount -t tmpfs varrun /var/run mount -t tmpfs varlock /var/lock mkdir -p /var/run/network touch /var/run/utmp chmod 664 /var/run/utmp chown root.utmp /var/run/utmp if [ "$(find /etc/network/ -name upstart -type f)" ]; then chmod -x /etc/network/*/upstart || true fi end script script start networking initctl emit filesystem --no-wait initctl emit local-filesystems --no-wait initctl emit virtual-filesystems --no-wait init 2 end script

Configure and start the container

Create the container:

lxc-create -f /home/bodhi/lxc/conf.ubuntu -n ubuntu
lxc-start -n ubuntu

You should now be able to access the container with either lxc-console or ssh

ssh root@192.168.0.60

lxc-console -n ubuntu

Update: The lucid container now boots with the -d option .

LXC – Linux Containers

bodhi.zazen — Tue, 02 Feb 2010 16:09:19 +0000

Linux Containers seems to be the “new kid on the virtualization block” so I decided it was time to take the technology for a spin.

What are Linux Containers?

Linux Containers (LXC) are an operating system-level virtualization method for running multiple isolated server installs (containers) on a single control host. LXC does not provide a virtual machine, but rather provides a virtual environment that has its own process and network space. It is similar to a chroot, but offers much more isolation.

~ Dwight Schauer ~

Linux containers has several features / advantages:

Advantages:

Better isolation as compared to a chroot (chroot jail).
Low overhead. LXC uses minimal resources in terms of RAM and hard drive space without the overhead of installing a guest OS in a virtual machine ( VMWare / VirtualBox / KVM ) .
Applications and services (servers) run at native speed.
There is support for Linux containers in libvirt .
Linux containers work well with btrfs .
No special hardware is required, runs on 32 and 64 bit processors.
Linux containers are Open source.
Unlike XEN or OpenVZ , no patch is required to the kernel.

But there is also a downside:

Linux containers run Linux processes on a Linux kernel. This means you can run Linux (Fedora container on an Ubuntu host) but not other operating systems (Not BSD / OSX / Windows).
There are no GUI (graphical) interfaces to configure or manage the containers.
There is a paucity of documentation on how to install and configure a container.
Configuring a container requires a modest technical knowledge and skill (and a large grain of patience).

In this post I will show how to configure your host node using Fedora and Ubuntu as examples. This information is relatively generic and you should be able to adapt most of the information to other Linux hosts. Some distributions (Arch / SUSE) have specific reference pages listed at the end of this post.

Configuration of the Host takes 4 steps:

Kernel.
LXC tools.
Cgroups.
Bridge network card.

Kernel

The good news, Linux containers are part of the mainstream Linux kernel. This means there is no need to patch or compile a custom kernel.

To run Linux containers you need kernel >= 2.6.27. The stock or default kernels, 2.6.29 or greater, that ship with most Linux distributions work out of the box.

LXC tools

There are a set tools are a set of commands / scripts to create and manage containers.

lxc – These are the scripts used to manage containers. Home page .

bridge-utils – Although there are several options for networking, the consensus appears that the easiest ( ? best) option for networking is a bridge.

debootstrap / febootstrap – These tools allow one to install a minimal Debian/Ubuntu or Fedora root file system.

Fedora Host

su -c “yum install lxc bridge-utils febootstrap”

Ubuntu Host

sudo apt-get install lxc bridge-utils debootstrap

Alternately you may compile the most recent lxc package from source :

Get the source code (the lxc project also maintains a git repository for bleeding edgers). At the time of this post, lxc-0.6.5 was the most recent version and, since it was recently released, no updated git version was yet available.

lxc source code

wget http://lxc.sourceforge.net/download/lxc/lxc-0.6.5.tar.gz
tar xvf lxc-0.6.5.tar.gz

Install dependencies:

Feodra

su -c “yum install -y make gcc libcap libcap-devel”

Ubuntu

sudo apt-get -y install libcap-dev

Compile and install

cd lxc-0.6.5
./configure –prefix=/usr # two – - in front of “–prefix”
make
sudo make install # Ubuntu
su -c “make install” # Fedora

As you compile you may see a message about running lxc as a user (vs root). You may ignore this advice as I could not get lxc-setcap working (the majority of the lxc commands require root privileges even after enabling the “lxc-setcap”).

If you wish to have a non root user to use the lxc tools, you can add the needed capabilities to the tools by invoking the ‘lxc-setcap’ script. To remove the capabilities, use the ‘lxc-setcap -d’.

cgroups

AKA Control groups

cgroups are basically the configuration files that set and regulate (limit) resources available to the containers.

For additional information on cgroups see :

Linux Kernel Documentation – cgroups
Using CGroups with libvirt and LXC/KVM guests in Fedora 12
man lxc-cgroup

To configure cgroups, as root, run the following commands:

mkdir /cgroup

Using any editor, edit /etc/fstab to include:

none /cgroup cgroup defaults 0 0

/cgroups will now mount automatically when you boot your system. To mount it manually without rebooting:

mount /cgroup

Bridge network card

As outlined in the lxc.conf man page there are several options for networking. The consensus when I searched the documentation was to use a bridge, so that is what I will outline here. Feel free to try the other options (examples in lxc.conf man page).

Unfortunately, configuring a bridge must be done manually. Also Network Manager will not manage the bridge (nor will many graphical firewall tools).

Note: You can not bridge a wireless card.

Fedora

As root:

chkconfig NetworkManager off
chkconfig network on
service NetworkManager stop
service network start

Using any editor, edit /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
TYPE=Ethernet
HWADDR=aa:bb:cc:dd:ee:ff:11:22 # DO NOT change your hardware mac
ONBOOT=yes
BRIDGE=br0
USERCTL=no
IPV6INIT=no

Make a new config file for your bridge

Using any editor, edit /etc/sysconfig/network-scripts/ifcfg-br0

To obtain an ip address automatically using DHCP:

DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0

To set a static IP:

HOSTNANE=fedora
DEVICE=br0
ONBOOT=yes
BOOTPROTO=static
DELAY=0
TYPE=Bridge
IPADDR=192.168.0.10
NETWORK=192.168.0.0
NETMASK=255.255.255.0
GATEWAY=192.168.0.1
MTU=1500
DNS1=192.168.0.1
IPV6INIT=no
USERCTL=no

Next, using any editor, edit /etc/sysconfig/network-scripts/ifup-post

Just above the “exit 0″ at the bottom add:

if [ $DEVNAME = "br0" ]; then
/usr/sbin/brctl setfd br0 0
fi

Restart your network:

service network restart

Note: You may need to manually edit /etc/resolv.conf and add your nameserver back in.

nameserver 192.168.0.1

Ubuntu

Turn network manager off or remove it.

sudo apt-get remove –purge network-manager network-manager-gnome

Stop your networking

service networking stop

Using any editor, edit /etc/network/interfaces adding lines for your bridge:

To obtain an ip address automatically using DHCP:

auto lo
iface lo inet loopback

auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp off
bridge_maxwait 5
post-up /usr/sbin/brctl setfd br0 0

To set a static IP:

auto lo
iface lo inet loopback

auto br0
iface br0 inet static
address 192.168.0.10
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1
bridge_ports eth0
bridge_stp off
bridge_maxwait 5
post-up /usr/sbin/brctl setfd br0 0

Using any editor, edit /etc/resolv.conf and add in your nameserver

nameserver 192.168.0.1

Managing containers

Containers, or guests, are built either with lxc tools (lxc-debian or lxc-fedora), debootstrap / febootstrap, or by converting openvz containers.

In Fedora, lxc-debian is not working. In Ubuntu neither lxc-fedora nor lxc-debian are working (and there is no lxc-ubuntu yet).

OpenVZ containers may be old / out of date and will require some modification.

Thus, of the 3 options I prefer bootstraping a minimal container.

In practice, creating a container takes some time and in my next blogs I will post detailed instructions for Fedora and Ubuntu.

In this post I will assume you have a working root file system, I call mine rootfs.fedora , rootfs.ubuntu, etc

Note: The commands to manage containers are run as root.

Create a container

To use LXC to provide VPS you need two things, a directory containing the file system, aka rootfs (see the above section), and a configuration file.

To create a config file for your container I suggest you either editing a generic template or better, read the man page and write one from scratch. See man lxc.conf for options

Basic file (very slightly modified from the default config file generated from lxc-fedora on a Fedora host):
lxc.utsname = container_name lxc.tty = 4 lxc.network.type = veth lxc.network.flags = up lxc.network.link = br0 lxc.network.name = eth0 lxc.network.mtu = 1500 lxc.network.ipv4 = your_network_here #for example 192.168.0.0/24 lxc.rootfs = /full/path/to/rootfs lxc.cgroup.devices.deny = a # /dev/null and zero lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm # consoles lxc.cgroup.devices.allow = c 5:1 rwm lxc.cgroup.devices.allow = c 5:0 rwm lxc.cgroup.devices.allow = c 4:0 rwm lxc.cgroup.devices.allow = c 4:1 rwm # /dev/{,u}random lxc.cgroup.devices.allow = c 1:9 rwm lxc.cgroup.devices.allow = c 1:8 rwm # /dev/pts/* - pts namespaces are "coming soon" lxc.cgroup.devices.allow = c 136:* rwm lxc.cgroup.devices.allow = c 5:2 rwm # rtc lxc.cgroup.devices.allow = c 254:0 rwm

Basically you will edit 3 lines (although you may use additional options, see man lxc.conf).
lxc.utsname = container_name
lxc.network.ipv4 = your_network_here (ie 192.168.0.0/24)
lxc.rootfs = /full/path/to/rootfs

The lines with “lxc.group …” define which resources are available to the container and configure confinement. The line “lxc.cgroup.devices.deny = a” denies access to everything and exceptions are added in in the following lines as needed. Yes, the terminology is cryptic, and for a better understanding I will have to refer you to the cgroup references in this blog.

Once you have a rootfs and a config file, run lxc-create :

lxc-create -f /path_to/config.file -n name_of_container

For example:

lxc-create -f /root/config.fedora -n fedora

Start a container

The basic command is lxc-start -n name_of_container

lxc-start -n fedora

Starting this way will show you the boot messages you would normally get when booting your distro. Watch for error messages (you will need to fix them manually).

Once the container is working, you can start it with the -d (demonize) option.

lxc-start -d -n fedora

Note: Some containers may not start with the -d option, in that case, IMO, better to use screen:

screen -dmS lxc_container_name lxc-start -n lxc_container_name

For example:

screen -dmS ubuntu lxc-start -n ubuntu

Stop a container

lxc-stop -n name_of_container

For example:

lxc-stop -n fedora

Destroy a container

lxc-destroy -n name_of_container

For example:

lxc-destroy -n fedora

Manage resources

The resources available to your containers is managed via cgroups. You manage them with the lxc-cgroup command. The resources are listed as flat text files in /cgroup/name_of_container .

A detailed discussion of cgroup is beyond this post, but I may devote a separate blog to this topic after finishing instructions for Fedora and Ubuntu containers. See the links in the cgroup section above for helpful links to “get you started”.

Tips

A few comments on the structure of containers on the host file system.

1. /var/lib/lxc : Container configuration files are kept in /var/lib/lxc . It makes life easier to make a link or bind /var/lib/lxc to /lxc

mkdir /lxc
ln -s /var/lib/lxc /lxc

2. /var/cache/lxc : Used by lxc-debian and lxc-fedora as a cache for downloading and installing a rootfs .

3. /cgroup/name_of_container : Location of container cgroup files.

4. lxc-fedora

When using lxc-fedora, the root file system is downloaded to /var/cache/lxc/fedora and then copied to your current working directory. This makes it much faster the next time you invoke lxc-fedora as it will copy the cached rootfs to your current working directory without repeating the downloading and installation of the base packages.

So, for example, if you lxc-fedora create, you will be asked a few questions, including the name of your container and network configuration.

If you run the command from /root, the script will cache and install the packages in /var/cache/lxc/fedora, copy the /var/cache/lxc/fedora to /root/name_of_container, and generate a configuration file based on the options you give.

When you then create a container, with lxc-create, the configuration files are generated in /var/lib/lxc , and a link is generated for the rootfs to /root/fedora (assuming you names the container fedora).

This behavior is NOT emulated if you use bootstrap to make a rootfs manually or import (convert) an openvz template.

The down side of lxc-fedora is that the container still needs some modification and it is larger then if you use febootstrap.

See my blogs on generating a Fedora and Ubuntu container for detailed instructions.

5. IMHO, containment is very poor if you chroot into the container form the host node. Use lxc-console or ssh into the container.

References:

ModSecurity 2.5 – Book Review

bodhi.zazen — Fri, 08 Jan 2010 05:39:43 +0000

Happy New Year Everybody =)

I had the privilege of reviewing ModSecurity 2.5 by Magnus Mischel and now that the holidays are over, well, time to stop procrastinating.

For those unfamiliar with ModSecurity, it is an Apache module designed to enhance (Apache server) security. For more information on mod_security see this link .

ModSecurity is a security tool that has a number of features, but how to unleash the power of these advanced features ? Sure one can download and install mod_security and the community rule set, but where to go from there ? Where to turn for assistance with deploying mod_security ?

Enter ModSecurity 2.5 by Magnus Mischel

Although when working with Apache security it is helpful if you understand the basics of HTTP headers, this book will help get you started with mod_security. The book starts with installation of mod_security and then covers configuration and customization. The features of mod_security are detailed with clear explanations and examples.

The Book consists of 9 chapters and 2 appendices.

Chapter 1 Describes how to obtain and compile mod_security from source code. Often when working with security it is preferable to install the most up to date version rather then relying on older binaries from repositories. As such the instructions for compiling are easy to follow and will make compiling mod_security from source less intimidating. The author then describes how to configure Apache to use mod_security and test the initial installation.

Chapter 2 Describes how to write rules for mod_security. For those who are unfamiliar with regular expressions, there is a brief but thorough review of the syntax of regular expressions (and may be helpful even if you are familiar with regular expressions). The chapter concludes with several examples of practical rules to block undesired traffic by IP address, region, or after failing a set number of log in attempts.

Chapter 3 presents an analysis of how mod_security affects performance and suggests methods to both test and optimize performance.

Chapter 4 continues with a description of how to use and review the log files for mod_security. The chapter begins with a description of the logs and an overview of the options. The chapter concludes with a description of how to install and use the ModSecurity Console, which provides a web based graphical log analysis. Although again compiling is necessary, the directions were easy to understand and I was able to download and install the ModSecurity Console without any problems. I found the Console easy to understand and use.

Chapter 5 covers additional practical examples of using mod_security via the use of “Virtual Patching”. The general idea here is that if there is a known vulnerability in Apache, or mysql, one may be able to deploy a set of rules using mod_security that will prevent exploitation of such a zero day exploit while waiting for a patch from upstream. As is characteristic of the book, the chapter concludes with an example of a theoretical mysql injection and how to “virtual patch” the vulnerability with mod_security. Cross-site scripting and the twitter worm are covered as additional examples.

Chapter 6 is titled “Blocking Common Attacks” and as you might imagine covers very practical security threats such as http fingerprinting, blocking proxy requests, cross-site scripting, cross site forgeries, shell command execution attempts, and SQL injection (to name a few). An overview if each potential threat is provided if you do not know the terminology and then specific examples and mod_security rules are described.

Chapter 7 covers chroot jails. The concept of a chroot jail is introduced and using mod_security to simplify using apache in a chroot jail is then described.

Chapter 8 – REMO. Remo is a web based graphical tool to write and edit mod_security rules. Again easy to follow directions were provided and REMO was easy to install. The chapter covers how to configure REMO and use the interface to modify rules.

The book concludes with chapter 9 “Protecting a Web Application”. This chapter details how to write and monitor a custom set of rules for a web application, YaBB (Yet another Bulletin Board). This is a daunting task and if you feel your are super man (or woman) go for it. The process involves a thorough understanding of the normal functions of the web application and would require a test server to use for development and testing of rules. Ethereal or fiddler are used to monitor http activity and this information is then used to write a rule set for YaBB. The rules then are debugged.

Appendix A is a compendium of Directives and variables for use with mod_security.

Appendix B covers Regular Expressions in more detail.

OK, so not exactly light reading. This book will provide a solid foundation for ModSecurity and should be extremely helpful in understanding an deploying mod_security.

Firewall Ubuntu GUFW

bodhi.zazen — Wed, 25 Nov 2009 00:01:25 +0000

This is the third in my Firewall series, is in follow up to my previous 2 blogs about firewalls, and is intended to introduce GUFW, a graphical front end to UFW.

Firewall Ubuntu Desktops
Firewall Ubuntu Servers

Although the GUFW GUI may seem deceptively simple, the graphical front end is both easy to use and capable of performing the most common firewall configuration options. The graphical tool is a perfect place to start if you find ufw and iptables overwhelming.

Again the most difficult part of managing a firewall is knowing who you wish to allow or restrict (by ip address) and what service and port you need to allow (open) or deny (close). Gufw can help as many of these options are preconfigured. If you need further assistance, start with gufw, configure as much as you can, and then review the other two links.

GUFW is an option if you installed a few simple servers on your desktop (torrents for example) or if you installed a graphical desktop/ window manager (Gnome, Fluxbox, etc) to help you administrate a server.

As a side note, server side, rather then installing a GUI, some people probably use either the command line or web tools such as webmin, phpMyAdmin, etc to manage servers.

Install GUFW

Although ufw is installed by default, gufw is not.

First, Enable the Universe repository.

Then, using any method, install gufw (apt-get shown here).

sudo apt-get update
sudo apt-get -y install gufw

In Ubuntu 9.10, UFW is then located under System -> Administration -> Firewall configuration.

Enable your firewall

Simply click (check off) the “Enabled” button and select “Deny” in the “By Default” pull down menu.

The default settings are probably sufficient for the vast majority of Desktop users and, unless you are running a server, nothing further needs to be done. Simply close the GUFW window and your firewall will remain active, even if you reboot.

IMO, The most common servers used on desktops would include torrents, VNC, Samba, Apache, and SSH. If you are wanting to allow access to one or more of these servers you will need to configure GUFW as outlined below.

Allow inbound connections

UFW manages NEW INBOUND connections. Gufw allows all outbound traffic (see limitations below).

Use the following options if you are running servers and you wish to allow inbound connections from other computers.

To add a rule, first click the “Add” box on the bottom left. You will get a dialog box which will allow you a number of options.

Preconfigured options

GUFW has a number of common services preconfigured. You allow a service by program name (perhaps most useful on Desktops). As you can see common servers used on desktops, such as Transmission, are included (surprise, torrents are servers).

Or by service (perhaps most useful on servers).

By port

In the “Simple” tab you can open a specific port, by tcp, udp, or both. Simply add the port you wish to open in the box.

You may specify multiple ports, comma delineated

22,80,443

Or a range of ports with a : , so to allow bittorrent, open ports 6881 – 6999, use

6881:6999

Limit traffic

You may use the “Advanced” tab to allow or deny traffic from a specific ip address or subnet (LAN). Keep in mind order of your rules counts, so deny first then allow.

You may blacklist an ip address by denying all traffic from that IP.

In this example, all traffic from your LAN is allowed to connect to Apache (sorry the first part of “192.168.0.0/24″ was outside the box).

Firewall rules are displayed in the main GUFW window. The rule displayed in this example allows all traffic on the LAN (192.168.0.0/24) to access Apache ( port 80/tcp) on the server (ip address 192.168.1.10).

Remove a rule

Simply select your rule and click the “Remove” button on the bottom.

Logs

Logging is enabled by default. Under the menu, select Edit -> Preferences

Enable logging by selecting (checking off) your “Enable Gufw Logging” and “Enable ufw Logging”.

View the log

Under File -> Select the option “Log” with the magnifying glass icon

And you will see your logs. Although not displayed, any denied traffic will be logged.

You may clear the logs from this menu as well.

Limitations of GUFW

IMO GUFW is designed for users who wish to enable a firewall and do not feel they need to know the dirty details. As such it is simple and effective, although it does not offer all of the available options from either ufw or iptables.

GUFW does not manage (limit) outbound traffic.
GUFW only manages NEW connections.
GUFW does not give the option to block ping or limit connections.

You will need to user either ufw from the command line, learn iptables, or use another configuration tool if you need these options.

Firewall Ubuntu Servers

bodhi.zazen — Mon, 23 Nov 2009 23:43:42 +0000

This post is in follow up to my post on firewalls on Ubuntu Desktops.

IMO firewalls are often helpful for restricting access to servers. Servers come in two varieties, public and private, and often people wish to limit access or black list IP addresses that misbehave.

Again I will use UFW which is installed by default. In the last section I will introduce iptables. One feature that is nice about ufw, if you understand the ufw rules it is an easy transition to iptables.

The most important thing you need to know to firewall servers is;

Who (ip address) you wish to allow or restrict access.
What protocol (tcp / udp) and port is used by your server.

A listing of ports is available here.

Enable your firewall

If you are accessing your server remotely be sure NOT to lock yourself out

Assuming you are accessing via ssh, allow ssh (we will restrict ssh access below, for now just do not lock yourself out).

sudo ufw allow 22

Now enable your firewall. Except for ssh, which you allowed with the above rule, this will deny all incoming (udp/tcp) traffic to your server.

sudo ufw enable
sudo default deny

Public servers

Examples of public servers would be Apache (http) or FTP servers (to name a few). Here we wish to allow access to just about everyone.

Simply allow by port

sudo ufw allow 80

Or if you wish, by protocol and port (most servers will be tcp).

sudo ufw allow 80/tcp

You may specify multiple ports (comma separated list):

sudo ufw allow 80,443/tcp

Or a range of ports, low:high:

#Allow ports 6881 – 6999 (torrent)
sudo ufw allow 6881:6999/tcp

You may specify most services by name.

By Name :

sudo ufw allow ssh

Some servers can be specified “by application”, although this is still by port and is not application specific. By that I mean : if you allow “Apache”, you open port 80, which can be used by any client application (firefox, wget, etc).

List applications with -

sudo ufw app list

ufw app list Available applications: Apache Apache Full Apache Secure CUPS OpenSSH

To translate the cryptic output to English,
Apache = http = port 80
Apache Secure = https = port 443
Apache Full = both ports

As you install servers, they will be added to the list.

Now allow by application.

Examples (you do not need to use all 3 rules):

sudo ufw allow Apache

#Note: Quotes are needed with “Apache Full”
sudo ufw allow “Apache Full”

sudo ufw allow from 192.168.0.0/24 app OpenSSH

You may add custom applications or custom ports to /etc/ufw/application.d

As an example, /etc/ufw/applications.d/apache2.2-common contains
[Apache] title=Web Server description=Apache v2 is the next generation of the omnipresent Apache web server. ports=80/tcp [Apache Secure] title=Web Server (HTTPS) description=Apache v2 is the next generation of the omnipresent Apache web server. ports=443/tcp [Apache Full] title=Web Server (HTTP,HTTPS) description=Apache v2 is the next generation of the omnipresent Apache web server. ports=80,443/tcp

So if you changed the ssh port to 8822, add a file “ssh-custom”, at /etc/ufw/applications.d/ssh-custom

[SSH Custom]
title= SSH Custom port
description=OpenSSH Server Custom port
ports=8822/tcp

You will now see “SSH Custom” when you list apps and can use it as above.

Private servers

Examples may included NFS, Samba, ssh, VNC, and VPN. I will use ssh and Apache as an examples.

For these examples we will assume your LAN is 192.168.0.0/24 and your server is 192.168.0.10

Here we almost always wish to restrict access to a single ip or perhaps range of IP. For example to restrict access for ssh to a single machine, say 192.168.0.20

sudo ufw allow proto tcp from 192.168.0.20 to 192.168.0.10 port 22

The syntax is protocol from to port

To allow ssh from any client on your your lan use:

sudo ufw allow proto tcp from 192.168.0.0/24 to 192.168.0.10 port 22

Limiting access

Limiting access comes in two flavors, the first is to limit a DOS or brute force attempt, and the other blacklisting.

Brute Force

UFW will rate limit connection attempts:

ufw supports connection rate limiting, which is useful for protecting against brute-force login attacks. ufw will deny connections if an IP address has attempted to initiate 6 or more connections in the last 30 seconds.

Example (using ssh):

sudo ufw limit ssh

“Limit” opens the port, so you do not need a second rule.

ufw status Status: active To Action From -- ------ ---- 22 LIMIT Anywhere

This output demonstrates – Port 22 is open and access is limited by ufw.

Blacklist

Keep in mind the order of your rules is critical. As such I like to block first, accept second. So for example let us assume we wish to block a misbehaving client on our LAN, 192.168.0.20:

sudo ufw insert 1 deny from 192.168.0.20

Here “insert 1″ is specifying to ufw to insert the rule first (or near the top) of the chain.

Using UFW in this way blocks only NEW connections.

IMO better to use iptables or an application such as iplist.

Block ping

By default, UFW allows ping requests. In order to block these requests you will need to edit /etc/ufw/before.rules

sudo -e /etc/ufw/before.rules

Change # ok icmp codes -A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT -A ufw-before-input -p icmp --icmp-type source-quench -j ACCEPT -A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT -A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT -A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT

# ok icmp codes
-A ufw-before-input -p icmp –icmp-type destination-unreachable -j ACCEPT
-A ufw-before-input -p icmp –icmp-type source-quench -j ACCEPT
-A ufw-before-input -p icmp –icmp-type time-exceeded -j ACCEPT
-A ufw-before-input -p icmp –icmp-type parameter-problem -j ACCEPT
-A ufw-before-input -p icmp –icmp-type echo-request -j DROP

Restart UFW

sudo ufw disable
sudo ufw enable

Deleting rules

Deleting a rule is also easy. Use the same syntax you used to add a rule to ufw with the word “delete” added.

For example, using Apache as an example:

# sudo ufw allow Apache
Rule added

# ufw status
Status: active

To Action From
– —— —-
22 LIMIT Anywhere
Apache ALLOW Anywhere

# sudo ufw delete allow Apache
Rule deleted

# ufw status
Status: active

To Action From
– —— —-
22 LIMIT Anywhere

Iptables

Now that you have ufw under your belt, it is easier to understand iptables. If you are wanting to use iptables, best disable UFW first.

sudo ufw disable

#These iptables rules clean up after UFW, deleting the custom tables
sudo iptables -F
sudo iptables -X

To deny all incoming traffic (take care not to lock yourself out form remote servers, allow ssh first !!!):

sudo iptables -A INPUT -j DROP

You can set a Policy with iptables, but doing so makes it easy to lock yourself out if you issue the command “iptables -F”.

To allow ssh

sudo iptables -A INPUT -p tcp –dport 22 -j ACCEPT

To allow ssh only from your LAN:

sudo iptables -A INPUT -s 192.168.0.0/24 -p tcp –dport 22 -j ACCEPT

iptables is much more feature rich the UFW and hopefully this blog will both stimulate your interest and facilitate your learning of the use of iptables.

Firewall Ubuntu Desktops

bodhi.zazen — Mon, 23 Nov 2009 06:34:16 +0000

Many Ubuntu users are interested in learning how to enable a firewall. The majority of people seem to be interested in filtering in an out bound connections on a Desktop installation.

Without getting into the inevitable debate on the merits of using a firewall, I would like to pass on some basic information. Please understand that discussions about firewalls and understanding the technical details of a firewall can become complicated very fast. The goal of this blog therefore is to enable users to feel comfortable with the basic firewall manipulations on an Ubuntu Desktop installation.

You should also know, by default Ubuntu, unlike some operating systems, has no significant listening servers. You may list your listening servers with any of the following commands:

sudo bash -c “netstat -an | grep LISTEN | grep -v ^unix”
netstat -ntulp
sudo lsof -i -n -P

Alternately you may perform a portscan from a second computer, ie nmap

I strongly advise the use of UFW (Uncomplicated FireWall) as it is installed by default, the syntax is easy to understand, and the defaults are more then adequate for the vast majority of users. If you prefer a graphical front end, install GUFW.

Enable your firewall

This is very easy:

sudo ufw enable

Deny incoming connections

This setting will deny all new incoming connections. Established connections (connections you request) are allowed.

sudo ufw default deny

Since we are not running a server, nothing further is required for incoming connections.

Deny outgoing connections

This is a bit harder as you need to know the services you wish to allow and write rules for outbound traffic you wish to allow. Common services you may wish to allow (and their ports) include:

Basic services:
DNS (Domain Name Service) = protocol udp port 53.
Web browsing = http protocol tcp port 80.
Secure web browsing = https protocol tcp port 443.
Mail = protocol tcp port 25.
FTP = protocol tcp port 20 and 21.
SSH = protocol tcp port 22.
VNC = protocol tcp port 5900.
Samba uses multiple ports , protocol udp ports 137 and 138 as well as tcp ports 139, and 445.
IRC protocol tcp , Ubuntu Servers defaults to 8001.

A listing of ports can be found here.

UFW will block outbound traffic based on the destination port on the server. To allow the outbound traffic listed above use:

sudo ufw allow out 53,137,138/udp
sudo ufw allow out 20,21,22,25,80,139,443,5900,8001/tcp

Then block all other outbound traffic with:

sudo ufw deny out to any

Keep in mind, order of the rules is critical. So if you need to allow additional traffic, you will need to insert a rule.

List your rules by number with:

sudo ufw status numbered

If you used the above syntax you will see :
Status: active To Action From -- ------ ---- [ 1] 53,137,138/udp ALLOW OUT Anywhere (out) [ 2] 20,21,22,25,80,139,443,5900,8001/tcp ALLOW OUT Anywhere (out) [ 3] Anywhere DENY OUT Anywhere (out)

Say we wish to allow out telnet on port 23. We will need to add this before the third rule (which denies all outbound traffic). We do this using insert.

ufw insert 3 allow out 23

Peer-to-peer (torrents)

Peer-to-peer file sharing via torrents are popular and allowing torrent traffic is a bit complicated. The major reason for this is that IP providers often block common torrent ports, so it is almost impossible to know what ports will be used for the torrent transfer and it may be easier to disable your firewall if you use torrents.

The somewhat more complicated approach is to determine the inbound port for your torrent client, and allow inbound traffic on that port.

Using the “default” torrent ports as an example (bittorrent uses ports 6881-6999), the easiest settings for torrent sharing are to allow these ports in and allow all outbound traffic. Check your torrent application for the inbound port or ports (Transmission, the default client in Ubuntu, uses port 51413 for example).

#This first rule allow ports 6881-6999 inclusive
sudo ufw allow 6881:6999/tcp

# Allow all outbound traffic if we blocked it previously
sudo ufw delete deny out to any

Deleting rules

If you need to delete a rule, simply use “delete”, for example:

sudo ufw delete deny out to all

Additional information

Ubuntu Wiki UFW
Ubuntu Wiki GUFW
Begin linux blog – ubuntu 9.10 ufw firewall

Download Ubuntu 9.10 OpenVZ Templates

bodhi.zazen — Fri, 13 Nov 2009 17:47:51 +0000

As many of you know, I am a big fan of Openvz and I have helped several learn to use OpenVZ. Although you certainly may wish to make your own Ubuntu Templates, several people have asked me if I have any.

So, I am making my templates available for download =)

I updated a set of Ubuntu 9.10 OpenVZ Templates and have made them available for download.

The templates are named such that they are compatible with Proxmox (these templates will show up in the Proxmox menu).

These templates work out of the box and are up to date as of November 12, 2009. The only thing that is “missing” would be an openssh-server (I remove openssh-server from my VPS). Openssh server can be installed with apt-get if you wish.

apt-get install ssh

The templates have been generated according to this how to and include this init script (which is modified from the script provieded by Stephane Graber).

If you want only the init script, it can be downloaded from here. Simply save that file in /etc/init/ as /etc/init/openvz.conf

i386 : 32 bit VPS
ubuntu-9.10-minimal_9.10_i386.tar.gz
ubuntu-9.10-minimal_9.10_i386.tar.gz md5sum

amd64 : 64 bit VPS
ubuntu-9.10-minimal_9.10_amd64.tar.gz
ubuntu-9.10-minimal_9.10_amd64.tar.gz md5sum

To use these templates, save them in /vz/templates/cache (I always link /var/lib/vz to /vz on Debian / Ubuntu Openvz host nodes).

sudo ln -s /var/lib/vz /vz