toic.org - Entries for the category Linux

Wsgi on cPanel improved

Sun, 27 Mar 2011 20:01:02 +0000

There is a long time now from my original post on running Django with python 2.6 on cPanel based servers, and as time passed there was some issues while deploying Django in such a way. So I decided to post another post with some updates regarding deployment of any python based scripts trough mod_wsgi and cPanel.

What's changed since last post?

There is a fix for easy_apache rebuilds, retaining the mod_wsgi and not braking rebuild process
There was some additions in virtualhost include files, enabling python app to run as a user, not nobody
A fix for cpanel's shell fork bomb protection while running python aps as a user and not nobody
Some minor changes regarding media handling, so it get's included in virtualhost includes and not by eating up user's subdomains
And of course python and Django version updates

Disclaimer at the beginning, this setup works for me on latest RELESE cPanel build, running on top of CentOS 5.5. I'm posting this as a way how I managed to get it working, so this shouldn't be considered as a official way of running Django or any other python app on cPanell servers. Although, as per my last post <a href="/blog/2010/django-on-cpanel-with-python2-6-virtualenv-and-mod_wsgi/">Django on cpanel with python2.6, virtualenv and mod_wsgi</a> lot's of people are reporting this is working for them also, and this version of deployment guide will bring some more enhancements.

Installing python and dependencies

mkdir /usr/src/python2.7 && cd /usr/src/python2.7

again, if you need sqlite, now is the time to install it.

wget http://www.sqlite.org/sqlite-autoconf-3070500.tar.gz
tar zxvf sqlite-autoconf-3070500.tar.gz
cd sqlite-autoconf-3070500
./configure
make
make install

Since CentOS 5.5 is still running python 2.4 and if you don't wish to brake your system you should install your python 2.7 in alternate location:

cd /usr/src/python2.7/
wget http://www.python.org/ftp/python/2.7.1/Python-2.7.1.tgz
tar zxvf Python-2.7.1.tgz
cd Python-2.7.1
./configure --prefix=/opt/python2.7 --with-threads --enable-shared
./configure --help
make
make install

This will install python 2.7 in /opt/python2.7 directory. To make any use of this alternate install we must do the following:

ln -s /opt/python2.7/bin/python /usr/bin/python2.7
echo '/opt/python2.7/lib'>> /etc/ld.so.conf.d/opt-python2.7.conf
ldconfig

It will make a symbolic link in your path and instruct the system where to find libs for this alternate python install.

Now is a good time to check if everything is working as it should

root@toy2 [/usr/src/python2.7]# /usr/bin/python2.7
Python 2.7.1 (r271:86832, Mar 26 2011, 22:31:33)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>>

Type CTRL+D to exit.

Next thing to do is installation of python-setup tools:

/usr/bin/python2.7
cd /usr/src/python2.7/
wget http://pypi.python.org/packages/2.7/s/setuptools/setuptools-0.6c11-py2.7.egg
sh setuptools-0.6c11-py2.7.egg --prefix=/opt/python2.7

In this tutorial, I'm skipping the installation of mysql for python since you will have to install it per user basis in their virtual environments. All we need to do next is to install virtualenv to our python 2.7 so we can distribute them to our users

cd /opt/python2.7/bin/
./easy_install virtualenv

mod_wsgi installation

cd /opt/python2.7/lib/python2.7/config/
ln -s ../../libpython2.7.so .
cd /usr/src/python2.7/
wget http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz
tar zxvf mod_wsgi-3.3.tar.gz
cd mod_wsgi-3.3
./configure --with-python=/opt/python2.7/bin/python
make
make install

Now this will install mod_wsgi.so file in /usr/local/apache/modules folder, as I experienced during cPanel easy_apache rebuilds it will completely empty this folder, thus any virtualhost includes relying on mod_wsgi will fail and easy_apache will not be able to properly rebuild your httpd.conf file and whole apache or php upgrade you were running will fail and revert back to last good state.

To avoid this we will now copy the mod_wsgi to different folder:

mkdir /usr/local/apache/extramodules
mv /usr/local/apache/modules/mod_wsgi.so /usr/local/apache/extramodules/

Note that this wsgi module is built with python 2.7 and will not work with any other version. If for some strange reason later on you try to run any given python application with system's default python2.4 it will not work.

Anyways, all we need to do next is to include mod_wsgi into the apache configuration:

nano /usr/local/apache/conf/includes/pre_virtualhost_global.conf

and paste:

LoadModule wsgi_module /usr/local/apache/extramodules/mod_wsgi.so
AddHandler wsgi-script .wsgi

Now do configtest:

root@toy2 [~]# service httpd configtest
Syntax OK

If you get Syntax OK at the end, you can safely restart your apache:

/scripts/restartsrv httpd

This is it, our apache can now serve python apps like Django, pylons, etc...

Setting up Django projects

Just like in my previous post I'll use '[username]' for cpanel username reference and '[domain]' for that user's domain. To match your needs you will have to replace those where appropriate.

We will quickly setup user's virtualenv, be aware though some of the python packages requires compile rights, and most of the cPanel setups I've seen so far are forbidding compiler access to their users. You can either make an permanent exception for this user, or you can instruct your user to contact you whenever he needs to install some package that requires compile rights (PIL, mysql...).

To enable compile rights for that specific user you can find that user in WHM WHM->Compiler Access->Allow specific users to use the compilers or if you don't like to exit the shell you can do it like this:

gpasswd -a [username] compiler

to remove it, use the same path in WHM and in shell:

gpasswd -d [username] compiler

For now, lets add this user to the compiler group since we will be installing some python packages for him in the start. Also you will have to enable your user a normal login shell, let's first check what shell this user has.

cat /etc/passwd |grep [username]

it should return something like this:

[username]:x:928:923::/home/[username]:/usr/local/cpanel/bin/jailshell

This user has jailshell enabled to change that into normal shell do this:

usermod -s /bin/bash [username]

If it's already bash, don't change it. You can also do this via WHM-> Manage Shell Access.

So let's finaly create a virtualenv for our user:

cd /home/[username]
/opt/python2.7/bin/virtualenv --no-site-packages --distribute virtualenv
chown -R [username].[username] virtualenv

this will create a new directory /home/[username]/virtualenv with our new virtual python environment for our user. From this point on we will do everything as the user and not root, until told otherwise.

su [username]
source virtualenv/bin/activate

And the promt will change to something like this:

(virtualenv)[username]@[domain] [~]#

that way we know we are loged in as user and we are using his virtualenv. Now let's install Django in this users environment, simply enter:

easy_install django

Now is also a good time to install additional python site-packages like mysql and PIL.

easy_install pil
easy_install mysql-python

So we have the django installed inside the users virtualenv, all we have to do now is start one of the instance. It's probably the best practice to keep django sites outside of public_html folders on cpanel servers. So we will do (still as a user)

cd
mkdir djangosites
cd djangosites
django-admin.py startproject [projectname]

So by now we should have a directory structure like this:

/home/[username]/virtualenv < - python virtual environment
/home/[username]/djangosites <- django sites folder
/home/[username]/djangosites/[projectname] <- django project

Create the wsgi script for that project, usualy [projectname].wsgi in django sites folder

nano /home/[username]/djangosites/[projectname].wsgi

and paste the following code:

import sys
import site
import os
vepath = '/home/[username]/virtualenv/lib/python2.7/site-packages'
prev_sys_path = list(sys.path)
site.addsitedir(vepath)
sys.path.append('/home/[username]/djangosites')
new_sys_path = [p for p in sys.path if p not in prev_sys_path]
for item in new_sys_path:
sys.path.remove(item)
sys.path[:0] = new_sys_path
from django.core.handlers.wsgi import WSGIHandler
os.environ['DJANGO_SETTINGS_MODULE'] = '[projectname].settings'
application = WSGIHandler()

give the scripts execute permissions:

chmod +x /home/[username]/djangosites/[projectname].wsgi

and exit user login with:

exit

now you will have your root propmt at the shell:

root@servername [/home/username]#

If you have decided so, now is the good time to disable the compiler access for this user.

create the apache include folder for that virtualhost:

mkdir -p /usr/local/apache/conf/userdata/std/2/[username]/[domain]/
nano /usr/local/apache/conf/userdata/std/2/[username]/[domain]/django.conf

and add:

<ifmodule mod_wsgi.c>
WSGIScriptAlias / /home/[username]/djangosites/[projectname].wsgi
WSGIDaemonProcess [projectname] user=[username] group=[username] processes=5 threads=15 display-name=%{GROUP}
WSGIProcessGroup [projectname]
WSGIApplicationGroup %{GLOBAL}
</ifmodule>

Ok, so this will create a processgroup for this specific django projects with 5 processes each 15 threads with our user's uid and gid. This is great since we have isolated this user to his own application pool and his own home path, also we are enforcing user quotas since if we omit "user=[username] group=[username]" from WSGIDaemonProcess the deamon process will run ass apache user nobody, and all files made/uploaded via this application will not count into this user's quota. They will also make lot's of problems if the user don't grant global write permissions on some folders. Just like mod_php and php_suexec.

Shell fork bomb exception

On the other hand, running 5 processes each with 15 threads (you can customize this ofcourse), will hit the defaults ulimits enforced by cPanels shell fork bomb protection (if enabled). You could either disable the protection, or you can make a little adjustments to its logic so that you can make exceptions per user allowing them a bit more freedom but still not unlimited.

I have found this method somewhere on cPanel forums (I can't seem to find the exact post right now, but I will update this post when I find it), anyways with little patching of profile, limits and bashrc you can create a list of users that have a slightly higher limits, so our django users won't run into any memory or fork limits normally enforced by fork bomb protection.

I've created a little tarball with installer scripts for patched fork bomb logic, I advise you to check the files prior to installing them. Script will make a copies of your original files, to the same destination with .orig suffixes.

cd /usr/src/
wget https://toic.org/files/django/forkbomb.tar.gz
tar zxvf forkbomb.tar.gz
cd forkbomb
./install.sh

Now all you have to do is put one username per line in /etc/profile.exclude

Each user in that line will have slightly bigger ulimits

Back to the Django

Let's also make admin media paths and media folder paths

System Message: WARNING/2 (<string>, line 323)

Literal block expected; none found.

mkdir /home/[username]/djangosites/[projectname]/media nano /usr/local/apache/conf/userdata/std/2/[username]/[domain]/django-media.conf

and add.

Alias /admin_media/ /home/[username]/virtualenv/lib/python2.7/site-packages/Django-1.2.4-py2.7.egg/django/contrib/admin/media/
<Directory /home/[username]/virtualenv/lib/python2.7/site-packages/Django-1.2.4-py2.7.egg/django/contrib/admin/media>
Order deny,allow
Allow from all
</Directory>
Alias /media/ /home/[username]/djangosites/[projectname]/media/
<Directory /home/[username]/djangosites/[projectname]/media>
Order deny,allow
Allow from all
</Directory>

Just replace your python version, django version and username and projectname in paths. This will create [domain]/media - for site media and [domain]/admin_media/ for admin media

Now verify those apache include files and rebuild apache conf:

/scripts/verify_vhost_includes
/scripts/rebuildhttpdconf

As always you can make subdomains for your media files, you will just need to update your [projectname]/settings.py

And that's it, hope you enjoy your django installation

Django on cpanel with python2.6, virtualenv and mod_wsgi

Sat, 14 Aug 2010 19:59:44 +0000

Here is the simple to follow step by step tutorial on howto run latest Django on cpanel powered servers with python 2.6, virtual env and mod_wsgi.
If you are running cPanel on your server it's most probably a rhel or centos distro, and those will have by default python2.4 installed. You can't just overwrite your python2.4 as many of the system utilities are depended on the python2.4 So what we will do is install an alternate python 2.6 and setup our server to run Django instances with python2.6

First of all let's make a folder where we will download all those source packages

Installing python and dependencies

mkdir -p /usr/src/python26 && cd /usr/src/python26

Next, we have to download and install sqlite3 dependency. It's not needed if your Django instances will not run sqlite databases, but on a safe side it's better to install it than not.

wget http://www.sqlite.org/sqlite-amalgamation-3.6.4.tar.gz
tar zxvf sqlite-amalgamation-3.6.4.tar.gz
cd sqlite-3.6.4
./configure
make
make install

If all went well it's time to install python 2.6 as alternate install.

cd /usr/src/python26
wget http://www.python.org/ftp/python/2.6.5/Python-2.6.5.tgz
tar zxvf Python-2.6.5.tgz
cd Python-2.6.5
./configure --prefix=/opt/python2.6 --with-threads --enable-shared
make
make install

This will install python 2.6 in /opt/python2.6 and will not interfere with system python install. Let's make a symbolic link to our newly installed python:

ln -s /opt/python2.6/bin/python /usr/bin/python2.6<

Also we must instruct our system where it should find the libs for new python.

echo '/opt/python2.6/lib' >> /etc/ld.so.conf.d/opt-python2.6.conf
ldconfig

You shoud check if your new python install is working as it should:

/usr/bin/python2.6
Python 2.6.5 (r265:79063, Jul 15 2010, 16:55:23)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

Type CTRL+D to exit. Next thing to do is installation of python-setup tools:

cd /usr/src/python26
wget http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11-py2.6.egg
sh setuptools-0.6c11-py2.6.egg --prefix=/opt/python2.6

Make sure to define the prefix on where your new python 2.6 installation is residing. We should make a temporary alias for new python as it will be needed for installation of python mysql package:

alias python="/opt/python2.6/bin/python"

Let's check if everything is working ok:

python
Python 2.6.5 (r265:79063, Jul 15 2010, 16:55:23)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> CTRL + D

So next in line is mysql for python:

cd /usr/src/python26
wget http://netcologne.dl.sourceforge.net/project/mysql-python/mysql-python/1.2.3/MySQL-python-1.2.3.tar.gz
tar zxvf MySQL-python-1.2.3.tar.gz
cd MySQL-python-1.2.3
python setup.py build
python setup.py install

Again let's verify the install:

cd /usr/src/python26
python
Python 2.6.5 (r265:79063, Jul 15 2010, 17:57:29)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> import MySQLdb
>>> CTRL + D

It shouldn't return any errors while issuing import statements. Ok for the end let's install the virtualenv so we can create a virtual python enviroment for each user and his Django instances

cd /opt/python2.6/bin
./easy_install virtualenv

And here we conclude the python instalation. Next order of business is mod_wsgi

mod_wsgi installation

cd /opt/python2.6/lib/python2.6/config/
ln -s ../../libpython2.6.so .
cd /usr/src/python26
wget http://modwsgi.googlecode.com/files/mod_wsgi-3.2.tar.gz
tar zxvf mod_wsgi-3.2.tar.gz
cd mod_wsgi-3.2
./configure –with-python=/opt/python2.6/bin/python
make
make install

This will install mod_wsgi in /usr/local/apache/modules/mod_wsgi.so Note that this wsgi module is built with python 2.6 and will not work with any other version. All we have to do now is add the mod_wsgi in our apache conf. You can do that on cpanel servers via WHM. Log into WHM , click on Apache Configuration then Include Editor then Pre-Virtualhost Include and select All versions Paste this:

LoadModule wsgi_module /usr/local/apache/modules/mod_wsgi.so
AddHandler wsgi-script .wsgi

** Save and restart apache.** And that's it. Our apache is now ready to serve python scripts via mod_wsgi Now all we have to do is install some Django instances for our user.

Setting up Django projects

I'll use '[username] ' for cpanel username reference and '[domain] ' for that user's domain. To match your needs you will have to replace those where appropriate. First of all you will have to decide if you will do empty virtual environments so that the user can decide what python site-packages will he use or will you preinstall some packages so that user can only update his virtualenv with packages that are missing. If you are choosing the first method user will have to have compile rights under security setting of cpanel WHM otherwise he will not be able to install packages as python mysql, PIL and some others. If you choose the former method you can preinstall those packages systemwide for our alternate python install, but whenever you update those packages all virtual environments will be updated with them. It's a matter of personal preference. I for myself rather like the clean virtualenv, and before delivering it to the client you as root preinstall in his virtualenv those packages requiring gcc rights. So let's create a virtualenv for our user:

cd /home/[username]
/opt/python2.6/bin/virtualenv --no-site-packages --distribute virtualenv
chown -R [username].[username] virtualenv

this will create a new directory __ /home/[username]/virtualenv __ with our new virtual python environment for our user. You will have to enable normal shell for this user, let's first check what shell this user has.

cat /etc/passwd |grep [username]

it should return something like this:

[username]:x:928:923::/home/[username]:/usr/local/cpanel/bin/jailshell

This user has jailshell enabled to change that into normal shell do this:

usermod -s /bin/bash [username]

You can also do this via WHM-> Manage Shell Access. From this point on we will do everything as the user and not root, until told otherwise.

su [username]
source virtualenv/bin/activate

And the promt will change to something like this:

(virtualenv)[username]@[domain] [~]#

that way we know we are loged in as user and we are using his virtualenv. Now let's install Django in this users environment, simply enter:

easy_install django

Now is also a good time to install additional python site-packages like mysql and PIL. First temporarily enable compilers for this user via WHM->Compiler Access->Allow specific users to use the compilers do the modules install with:

easy_install [module_name]

disable the compiler access afterwards

cd
mkdir djangosites
cd djangosites
django-admin.py startproject [projectname]

So by now we should have a directory structure like this:

/home/[username]/virtualenv < - python virtual environment
/home/[username]/djangosites <- django sites folder
/home/[username]/djangosites/[projectname] <- django project

Create the wsgi script for that project, usualy [projectname].wsgi in django sites folder

nano /home/[username]/djangosites/[projectname].wsgi

and paste the following code:

import sys
import site
import os
vepath = '/home/[username]/virtualenv/lib/python2.6/site-packages'
prev_sys_path = list(sys.path)
site.addsitedir(vepath)
sys.path.append('/home/[username]/djangosites')
new_sys_path = [p for p in sys.path if p not in prev_sys_path]
for item in new_sys_path:
sys.path.remove(item)
sys.path[:0] = new_sys_path
from django.core.handlers.wsgi import WSGIHandler
os.environ['DJANGO_SETTINGS_MODULE'] = '[projectname].settings'
application = WSGIHandler()

give the scripts execute permissions:

chmod +x /home/[username]/djangosites/[projectname].wsgi

and exit user login with:

exit

now you will have your root propmt at the shell:

root@servername [/home/username]#

create the apache include folder for that virtualhost:

mkdir -p /usr/local/apache/conf/userdata/std/2/[username]/[domain]/
nano /usr/local/apache/conf/userdata/std/2/[username]/[domain]/django.conf

and add:

<ifmodule mod_wsgi.c>
WSGIScriptAlias / /home/[username]/djangosites/[projectname].wsgi
WSGIDaemonProcess [username] processes=7 threads=1 display-name=%{GROUP}
WSGIProcessGroup [username]
WSGIApplicationGroup %{GLOBAL}
</ifmodule>

edit the virtualhost entry for that domain:

nano /usr/local/apache/conf/httpd.conf

and in that virtualhost add:

Include "/usr/local/apache/conf/userdata/std/2/[username]/[domain]/*.conf"

save & exit

test the apache configuration prior to reload:

service httpd configtest

Should say syntax OK at the end, if so reload the apache:

/scripts/restartsrv_httpd

And voila, you have your django instance up& running You can now add via User's cpanel media subdomain for django media files, and define the path to the subdomain root in setings.py media root can live inside public_html folder. You can also create additional subdomain for admin media and copy the admin media content to that subdoman. For example: admin-media.[domain]:

cp -r /home/[username]/virtualenv/lib/python2.6/site-packages/Django-1.2.1-py2.6.egg/django/contrib/admin/media/* /home/[username]/public_html/admin-media/

SSH port forwarding

Tue, 16 Feb 2010 20:58:36 +0000

In one of my previous post I made a tutorial how to bypass corporate firewalls and gain access into your office computer. It work well if you are at your home and you need ssh access (or any other service) to your office computer. However if the situation is reversed, and you need to access some outside service which your firewall is blocking then you would use this little tutorial with explanations. Although all this is covered in the ssh man pages, one always learn best by real life examples, so here I'll try to cover few of them.

To better explain our first problem look at the picture below:

First problem

We are located at our office computer which is behind very restrictive firewall, and we want to get to the non-standard service running on remote server.

Normally I'll use Mysql Administrator for example, to connect on my MySql database on a remote server. That communication would happen on port 3306, and for this to work Mysql Administrator must have appropriate rules set in our firewall to allow that traffic.

But what if traffic on that port is blocked?

Here is where we come to ssh port forwarding. If we have ssh access on any outside computer we can route our traffic through the tunnel and gain access to the service via standard ports.

Second problem

Ssh tunnel can be also used to establish connection from insecure networks to standard and non-standard services inside secured firewalled network as shown in picture bellow:

As you can see here, server is behind firewall and all the standard ports on that server (like http, pop, imap...) are allowed. Server is also running MySQL service which is listening on port 3306. To connect to it server's firewall should allow this incoming connection.

But what if it doesn't?

What if the network from which we are connecting is insecure and we wish to maintain our data private while communicating with our trusted, firewalled network?

Again we can solve this problem with ssh port forwarding. If we have clear and working ssh access on server or any other machine in the firewalled network, we can route our traffic through that ssh connection.

Solving the first problem

If our firewall is very restrictive (inbound and outbound), and you don't have control over it, you can use ssh port forwarding to your advantage. Essential things you will need are:

allowed ssh traffic on your restrictive firewall, port 22 by default

a remote server to which you can connect via ssh, and preferably control over that remote server's firewall.

If even port 22 is blocked in your restrictive firewall you can setup your outside ssh server to listen on some other port that is allowed through your firewall. You can than use -p switch in your ssh command to connect on your server. If you don't really know anything about ssh, you can always read ssh basics and than come back here.

So in our real example we want to connect to mysql service running on remote server and our firewall won't allow it. We have ssh access on that server so we will use it to tunnel this traffic.

To start up this tunnel this command will be used:

ssh -L 3306:localhost:3306 username@server

This will actually open up a port 3306 on our local computer listening on loopback interface through established ssh connection on to server's port 3306. If we already have mysql server running on local machine then the port 3306 is already in use, so we need to use another port on our loopback interface, so the command would look like:

ssh -L 3307:localhost:3306 username@server

Then we use our service client, in this case Mysql administrator and instruct it to connect to 127.0.0.1 at our specified port. We can use the same command to tunnel any other port and or service this way.

Extending this example

We can also use this connection method to our remote server for routing traffic to some other servers. Of course our remote server must to be able to connect to that remote service. This is usually very popular to forward traffic to some online games running on non standard ports, EvE, Warcraft, and any other game (this might produce additional lag on FPS games).

As shown on picture, for example we have outside gaming server running at port 66732, and that port is blocked in our firewall. We can use our remote server with ssh connection to establish a ssh tunnel and then route that traffic to our local computer.

To do so we would use this command:

ssh -L 66732:remote.gameserver:66732 username@our.server

On our loopback interface (127.0.0.1), this will create a listening port 66732 which will then be forwarded to remote.gameserver's port 66732 through our ssh connection on port 22. All you need to do is instruct your game client to connect on localhost. This can also be used in constructive purposes, like using your remote shell server to route traffic this way to remote mysql server on which you don't have ssh access but is available to your remote server via 3306 port. Bare in mind that your remote ssh server will have to be able to connect to remote.gameserver/mysql server on appropriate port, it your remote server have any outbound firewall rules filtering this traffic, this example will not work until you open that port.

As with reverse ssh port forwarding we can make this connection available to other computers on our LAN by specifying listening interface while establishing the tunnel. I'll go with remote gameserver example and enable our co-workers to connect via same ssh tunnel to remote gameserver without them needing to create their own tunnels.

If you have multiple network interfaces on your computer you will specify the one whit which you are connected to your co workers, but you can also enable it on all interfaces like this:

ssh -L 0.0.0.0:66732:remote.gameserver:66732 username@our.server

when you do netstat -ntl on your machine you will see it's listening on 0.0.0.0:66732. Your co-workers can now connect to your's office pc ip on that port and their connections will be also tunneled via this established ssh connection. Bare in mind that the remote.gameserver will see all the connections comming from our.server so if the remote.gameserver have any per ip connection count limit this will obviously be a problem.

Solving the second problem

How is this problem different form the first one. In essence it's not, only differences is that our firewall is permitting the non standard traffic, or we don't even have a firewall to worry about, but the server's firewalled network is very restrictive and its blocking our non standard ports. Ssh tunnel commands used in this example will be the same. However I can use this example for demonstrating why ssh tunnel can be useful for.

Say we don't have firewall and port limitations, but we are temporary on insecure network and server is on secured/trusted network. If we were to use any of the old plain test services like ftp, pop3, imap, synergy, etc... malicious hosts/users can sniff out that traffic and find out any usernames and passwords sent via plain text. Even the contents of the connection. So here's were ssh tunnel steps in again.

We can start an ssh tunnel from our insecure network to our secured server's network and tunnel any plain text/insecure traffic through it. By default ssh tunnel binds its self to loopback interface on our computer, which malicious network user doesn't have the access to, and as the ssh is encrypted, all the traffic passing through this tunnel will be plain gibberish to any malicious user sniffing our traffic on this insecure network.

Just like in one of the previous posts (secure synergy setup) we will use this tunnel to secure our traffic from eavesdropping. Ftp actually has sftp (ftp over ssh) so if you already have ssh you will want to use that instead of tunneling ftp traffic, but if for any reason you are not able to use it then this should work as well.

I'll take my example on pop3:

We establish ssh connection to secured remote server and tunnel the port 110 on our loopback interface to server's 110 through established ssh session. Then we connect with our mail client to localhost and preform plain text pop3 authentication through secure ssh tunnel.

ssh -L 110:localhost:110 user@secure.server

If you don't have access to the mail server's ssh then you can use another ssh host on secured network to route traffic with this:

ssh -L 110:mailserver:110 user@secure.server

Few useful tips

As mentioned few times before, perhaps the firewall will not allow standard ssh ports through, or your ssh server is running on different port in which case you should use -p switch with ssh. For example your ssh server is running on port 2210 then to forward pop3 traffic you would use:

ssh -p 2210 -L 110:mailserver:110 user@secure.server

You can also speed things up by using ssh keys and ssh-agent

And of course if you wish to use your ssh connection only for port forwarding an wish to put it into background you would use:

ssh -N -f -L 110:mailserver.110 user@secure.server

And from here it's all combinations of above used commands.

Have fun!

Secure synergy setup

Sun, 01 Feb 2009 20:50:21 +0000

Synergy is a nifty tool for cross platform clipboard, keyboard and mouse sharing. It's reasonably easy to configure synergy server for use with multiple synergy clients.

Doing so will spare you some time while working on multiple computers at your desk at once. I use it at office to connect my laptop's and office computer mouse, keyboard and clipboard and thus reducing or completely eliminating need to lean over my laptop every time I need to use it. Anyway, most of the people use it with quicksynergy wrapper allowing even easier setup, but what the synergy lack is a means of authentication and security in data transfers. I'll try to guide you how to make a secure synergy setup on untrusted networks.

So for a starter you will need to setup a synergy config file to use it with your synergy server. While using a quicksynergy may be easier we won't use it since it lacks some flexibility.

I'm using my laptop named blap and my office computer named kex. Blap is located to the left of kex so I will need a conf file looking like this:

section: screens
blap:
kex:
end
section: links
kex:
left = blap
blap:
right = kex
end

at the first section we define two screens, one for laptop and one for office computer each named by their host name. At the second section we define links between two screens which states that left from computer kex is computer blap. And for blap right edge of screen is linked with computer kex. We can define as many hosts we like in relative positions. You can consult manual page of synergys f or all available options.

When done configuring screens and links save that file as synergy.conf in your home directory.

Starting a server with:

synergys -c /home/branko/synergy.conf

will allow us to connect to our office computer using our laptop and merging screens.

Like stated earlier, synergy server have no means of authentication so any client within our network can connect to. Naturally if I'm on busy or untrusted network this isn't very appealing thought. O n top of that, all traffic between synergy server and client is unencrypted so anyone on local network can eavesdrop with tcpdump, wireshark or any other network capturing program. Anything that gets

System Message: ERROR/3 (<string>, line 32)

Unexpected indentation.

to clipboard is available to our malicious user on our local network.

System Message: WARNING/2 (<string>, line 33)

Block quote ends without a blank line; unexpected unindent.

So how can we implement some sort of encryption and authentication on our synergy server.

First we will add additional parameter to our synergy server startup line:

synergys -a 127.0.0.1 -c /home/branko/synergy.conf

this way synergy server will start listening on loopback network interface only, instead on all network interfaces. This way we are only allowing access to synergy server to locally authenticated use rs. You can now put this command in session startup.

Since server is now not available on any outside interface we must first login and authenticate our self to the office computer. While doing so we will also open a ssh tunnel to our laptop.

Prior to executing our synergy client on laptop I will need to execute:

ssh -N -f -L 24800:localhost:24800 branko@192.168.0.100

this will open up ssh connection to my office computer (192.168.0.100) for which I will need to login as user branko an when I do so port 24800 on 192.168.0.100 will be tunneled to my loc alhost's port 24800.

Now I can simply start up my synergy client on my laptop by executing:

synergyc localhost

Now all the traffic between my laptop and office computer is encrypted and as such information traveling trough the ssh tunnel are unavailable to possible eavesdropping, and since we started the serv er on a loopback interface no malicious client can be connected from outside. For the ease of use you can combine the above comands in single shell script and saving it in users private bin folder:

vim ~/bin/synergy

paste the text inside:

#!/bin/sh
ssh -N -f -L 24800:localhost:24800 username@synergyserver
synergyc localhost

Make it executable:

chmod +x ~/bin/synergy

And now you can simply type synergy at your terminal or run command prompt after pressing ALT + F2

Bypassing corporate firewall with reverse ssh port forwarding

Sun, 18 Jan 2009 20:49:02 +0000

Probably lots of you are behind some sort of very restrictive corporate firewall. Unable to access your office pc from home because of firewall policies. In normal cases this scenario is more than welcomed. No outsiders should be allowed to access internal parts of secure network! Ideally companies will setup secure VPN access allowing its employees to access their work computers and do some work remotely. What if you aren't one of the lucky ones having such option? You desperately need to access your office pc?

The problem

As shown on the picture above, we have our office PC behind very restrictive corporate firewall connected to Internet. Firewall will not allow any traffic originating from Internet to internal networ k except previously initiated traffic. Meaning you can contact remote hosts on Internet from your office PC and they can respond, but remote computers can't initiate connection to your office PC. Thi s is of course huge problem if you have to access your work materials on office PC from your home. Additionally corporate firewall will only allow certain traffic from your office PC to remote hosts. Meaning you can only establish FTP, SSH, HTTP, POP3... communications, all other ports are blocked.

How can you access your office PC then?

One way is to setup corporate VPN access allowing secure connections to internal network. Another method is to setup a port forwarding on corporate firewall so it redirects certain ports to your offi ce PC. But if you don't have the means to accomplish any of this then the only way to do it is to use ssh tunnels and reverse port forwarding.

The solution

If we can only contact remote hosts on certain ports, the solution would be to contact remote hosts via allowed port and piggyback the connection on already established link.

Something like shown on the picture above. Fortunately we can do this with ssh.

Real life example

I will assume that home PC is connected via dynamically assigned IP address. First thing you will need to make sure you have ssh server installed on your home PC and it should be accessible from Inte rnet. If you have some NAT routers, be sure to forward port 22 to your home PC. Secondly you will need to setup a dyndns account so you can connect to your home PC regardless of IP address changes. N ow the goal will be to connect to that home ssh server from our office PC.

For the purpose of this example i will name my home PC: bhome.dyndns.com Office computer name will be bwork.office.com bwork computer uses private IP range of 192.168.0.0/24 with address 192.168.0.100

So if the firewall is preventing outside connections to our bwork computer we must initiate connection from it.

We can do this with simple ssh command:

ssh -R 2210:localhost:22 bhome.dyndns.com

So what just happened here? We are initiating ssh connection ssh with reverse port forwarding option -R which will then open listening port 2210: who is going to be forwarded back to localhost's port :22 an d all this will happen on remote computer bhome.dyndns.com.

This connection represents the green line in the diagram above, and it's a legit connection as far as corporate firewall is concerned.

Now if weopen up a terminal on bhome computer, and type in:

ssh -p 2210 localhost

we will try to connect to localhost (bhome.dyndns.com) on port 2210. Since that port is setuped by remote ssh connection it will tunnel the request back via that link to the bwork.office.co m computer. This is the red line on the diagram above. Looking from firewall's perspective it's a legit traffic, since it is responding traffic on already initiated link from bwork c omputer.

Real life example 2

What if your home computer is not always on-line? Or perhaps you wish to access your office computer from multiple locations? For this you will have to have some dedicated server or VPS outside the c orporate firewall.

To accomplish this we will use the same command as previously, only this time we will open up a reverse ssh tunnel to remote server or VPS.

For the purpose of this example we will name the server bserver.outside.com with IP 89.xxx.xx.4

ssh -R 2210:localhost:22 bserver.outside.com

again this will open up reverse ssh tunnel to the machine 89.xxx.xx.4 (bserver.outside.com). So when we login to the server and issue the command:

ssh -p 2210 localhost

we will end up with bwork computer's ssh login prompt.

Can I use this previously established reverse ssh tunnel to the server to directly connect to my office computer?

Of course, but some slight modifications are required. By default ssh tunnels only bind to local address, and can be accessible only locally. Meaning, in the example above, you can't just type:

ssh -p 2210 bserver.outside.com

on your home PC and be connected to your office PC!

If you run:

netstat -ntl

on bserver you will see that the port 2210 is only listening on 127.0.0.1 IP address. To get it listen on interface connected to Internet we must enable GatewayPorts option in ssh server's config uration. By default GatewayPorts are disabled in sshd, but we can simply enable them:

vim /etc/ssh/sshd_config

then add:

GatewayPorts clientspecified

save the file and restart sshd:

/etc/init.d/ssh restart

We could have just enable GatewayPorts by typing On instead of clientspecified, that would route any ssh tunnel to network interface. This way we can control which tunnel will be accessible f rom outside, and on which interface.

So if we initiate reverse ssh tunnel like this:

ssh -R 89.xxx.xx.4:2210:localhost:22 bserver.outside.com

we will have bserver listening on port 2210 on network interface bound to ip 89.xxx.xx.4 and forwarding all traffic via established tunnel to bwork computer. If you omit the 89.xxx.xx.4 address from the command above server will again listen on port 2210 only on local loopback interface. If you have multiple network interfaces on server be sure to select the one you can connect to. To enable listening port on all interfaces, just use IP 0.0.0.0 in the command above

Now when we run:

ssh -p 2210 bserver.outside.com

from our home PC we will initiate ssh connection on port 2210 towards server bserver.outside.com (blue line). Server will then forward that traffic to office PC (red line) via the previously established reverse ssh tunnel (green line).

Of course you will have to open up port 2210 on server's firewall to be able to connect.

Some more fun with reverse tunnels

Fun doesn't stops there. Say I have a printer behind that corporate firewall. How can i connect to it? Easy... remember the first example? the command ssh -R is taking 5 arguments of which 4 are mandatory:

ssh -R [bind_address:]port:host:hostport

bind_address is the network address on which port will be listening, and forwarded to host (connected to network from which reverse tunnel originated) on hostport.

so if we issue the command like this on our bwork pc:

ssh -R 89.xxx.xx.4:2211:192.168.0.10:631 bserver.outside.com

we will get something like this:

so again we have previously established reverse ssh tunnel listening on port 2210 to channel the ssh connection towards office PC. Now with this new command we established the reverse ssh tunnel (yellow line) towards bserver which will listen for incoming connections on port 2211. When the home pc makes a data connection to port 2211 on bserver (brown line) it is t hen forwarded to office PC (black line) which is then redirected towards office printer at address 192.168.0.10 on port 631 (purple line). Remember, all this traffic is passing trough corporate firewall as legit traffic, even if the illustration perhaps shows otherwise.

Automating the task

By now we should have covered the basics on how to bypass corporate firewall in order to get to your office computer and network equipment. Now, ssh -R isn't really practical, it consumes one terminal, and as soon as it shuts down there is no tunnel and no outside connectivity for that matter. The easiest thing to do is putting a cron jo b that will connect to remote server if the connection fails, office computer reboots etc.

First of all generate ssh keys, and add them to ssh-agent so that script won't ask you for remote server's password or local key phassphrase all the time.

Next we will add two extra parameters to our command -N and -f so that the connection goes into the background.

the command will look like:

ssh -N -f -R [bind_address:]port:host:hostport

next we need a shell script that will be triggered by the cron. For this example we will use the Real life example 2:

#!/bin/sh
COMMAND="ssh -N -f -R 89.xxx.xx.4:2210:localhost:22 bserver.outside.com"
pgrep -f -x "$COMMAND" > /dev/null 2>&1 || $COMMAND

Edit this code so it suits your needs, and save it in your home dir as reverse_ssh_tunnel.sh

Now we need to add a crontab entry which will trigger this script every 5 minutes:

crontab -e

and add:

*/5 * * * * /bin/sh /home/username/reverse_ssh_tunnel.sh

If you are connecting to different user name on remote server you can edit your commands so they look like:

ssh -R [bind_address]:port:host:host_port username@remote_host

Have fun and be safe!

SSH basics

Mon, 17 Nov 2008 20:45:56 +0000

Using ssh and its functionality should be a second nature to all Linux sysadmins, for some users some aspects of ssh are still a mystery, so let's shed some light on it. Here you will not learn basics shell commands and usage, I will simply try to explain usage of ssh protocol itself, and it benefits. How to use ssh, how to setup keys, how to use ssh agent that will enable some extra functionality for programs like scp, rsync, etc.

First of all what is ssh?

SSH is client-server secure shell network protocol usually used for remote host or network device administration. Other than that it allows secure tunneling, TCP port and X11 forwarding, file transfers.

For now, let's stick to remote host administration. I'll be focusing on ssh client rather than configuring ssh server, suffice to say ssh server is a daemon, by default running on remote host and listening on tcp port 22.

SSH client is a program used to connect to sshd on remote host.

Simple usage would be:

bash# ssh username@hostname

If you're contacting remote hostname for the first time it will ask you to review and save remote host's fingerprint. It will be used in future connections to determine host's authenticity. If for some reason remote host changes its IP, hardware, location, key... you will be warned and denied access to remote host because it might be fraud, or some kind of man in the middle attack.

If you are sure that fingerprint change is valid you will have to remove previously learned fingerprint and save a new one.

If for some reason remote sshd is not listening on TCP port 22 you should give additional -p option to ssh client like this:

bash# ssh -p 2210 username@hostname

this way you will instruct your ssh client to connect to remote TCP port 2210.

By default sshd has the password authentication enabled so using examples above will prompt you for remote user's password. Sometimes you will find remote hosts have the password authentication disabled for security reasons. To "circumvent" this restriction ssh has an ability to authenticate with pre-generated keys.

How to generate ssh keys?

Note: if you are using some old Debian or Ubuntu distribution, before generating keypair verify that you have patched your libssl as noted here: http://www.ubuntu.com/usn/usn-612-1

To enable key authentication we must generate a new key pair. By default command:

bash# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
28:ce:58:0a:61:7b:b4:d6:7b:b2:e0:11:9e:d9:b2:77 root@branko.toic.org

will generate new default 2048bit rsa key, it will prompt you to enter a path where key will be saved and enter a passphrase. I strongly recommend that you use strong password on your key. I

If you saved your key in default location (~/.ssh/id_rsa or ~/.ssh/id_dsa) when contacting remote host ssh agent will try to use your key file as first method of authentication even if password auth is enabled on remote server. If you have saved your key file on some other location you will have to supply your ssh client with additional -i parameter followed by your private key location (later on you will learn how to overcome this parameter so don't panic just yet):

How this thing works anyway?

For now all we have is two keys generated. I will asume you have used default rsa key in default location ~/.ssh/id_rsa if you have made it somewhat different you will have to edit your commands accordingly.

You should by now have your keypair located at ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub first key (id_rsa) is your private key that you shouldn't distribute around, second key (id_rsa.pub) is public key which you will set up on remote hosts as authorized key for certain user(s).

When connecting to remote host it will try to locate ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2 files for that user to which you are connecting. If one of those file have your public key (content of your id_rsa.pub) that is matching your private key you will be authenticated and will be allowed to login, if not ssh will try other means of authentication such as password based if enabled by the server.

Distributing your public key

You now have to distribute content of id_rsa.pub to authorized_keys file on remote servers for each user name that we will use. To do so you must upload your id_rsa.pub file to remote server (upload it to your home directory for now) and issue command:

bash# cat ~/id_rsa.pub &gt;&gt; ~/.ssh/authorized_keys

This way we will append our key to authorized keys for that user.

If you yet have no means to connect via ssh to remote host because password auth is disabled when uploading make sure remote filename will be called authorized_keys. This way we will have content of our public key in authorized keys and will enable us to connect to remote host.

Caution: If authorized_keys file already exists on remote server, uploading our id_rsa.pub file over it will disable all other authorized keys, try other means of adding content of your id_rsa.pub to authorized_keys

Connecting to remote hosts

Now we can connect to remote host with same commands as before:

bash# ssh root@branko.toic.org
Enter passphrase for key '/home/branko/.ssh/id_rsa':

Here you will enter passphrase defined when we were creating keyfile.

Note: to change passphrase for current private key use command:
bash# ssh-keygen -f [private key location] -p

Now you maybe wondering how is this any different from password authentication? For one you can now distribute your public key file to any number of hosts and use single private key file to contact all off those hosts. You can even use same private key on more than one workstation so it's not needed to recreate steps above for each workstation. Other than that, it will reduce possibility of remote password brute force attacks on your servers, enables you to use applications that use your key files for contacting remote hosts like scp, rsync, etc.

Besides that, using ssh keys enables you some more functionality by using ssh-agent

Ssh-agent? What is that?

Ssh agent is simple shell tool that comes bundled with ssh client. It enables you to "put your keyfile and your passphrase in its hands".

Sounds awfully! Now why would I do that?

Consider this situation, you are working on dedicated workstation and you have 8h work time. In that period you will be contacting multiple remote hosts on multiple occasions. Entering passphrase one time after another may be acceptable at first, but later it becomes waste of time.

Ssh-agent allows you to unlock you private key so you won't be prompted for your passphrase each time you try to connect to remote host.

Also it allows you to add multiple private keys so you can us them all when connecting to remote hosts, if you have created keyfile that isn't in its default location, adding it to ssh-agent will not require you enter additional -i parameter to ssh client.

After finishing with your work you can simply remove your key from agent, and it will again prompt you for your passphrase when trying to connect to remote host.

Note: for Gnome or KDE users (or any DE for that matter) ssh-agent is integrated within DE keyring for the duration of your session

How do I use this ssh-agent?

First of all we need to start the ssh agent. One would say easy way of doing it is typing ssh-agent to terminal, that may be true but it will require you to set extra environment variables afterwards. Trying to run ssh-agent will start the process and output those variables, so even easiest way of doing it is to invoke ssh agent command with eval:

bash# eval 'ssh-agent'

that way we will have ssh agent and variables set at once.

Note: ssh-agent supports key lifetime, you can limit the time key can be in ssh agent by adding -t parameter followed by number of seconds or in other time format specified in sshd_config.

Now when the agent is running all we need to do is add our keyfile to agent with:

bash# ssh-add

It will then add your default private key located in ~/.ssh/id_rsa or id_dsa to agent. It will ask you for it's passphrase only this time. If you wish to add another private key from different location you should use:

bash# ssh-add [location to private key]
**Note:** adding **-t** parameter followed by lifetime in seconds will overwrite ssh-agents **-t** parameter.

To remove private key from ssh agent simply type:

bash# ssh-add -d

again this will only remove default key if you have additional key inserted you should use:

bash# ssh-add -d [location to private key]

to remove all private keys from ssh-agent simply type:

bash# ssh-add -D

Practical use of all above?

Using ssh keys in combination with ssh agent will save you a lot of time. Consider example above when you frequently use ssh client to connect to multiple hosts, this will save you troubles, with password managers, time consuming password finding and retyping etc.

Multiple network interfaces in Xen

Mon, 06 Oct 2008 19:44:41 +0000

By default xen tools comes with only one network interface enabled for your dom0 and domU machines. So what if you want to add some more? It's actually very simple.

All you need to do is run:

/etc/xen/scripts/network-bridge start vifnum=1 netdev=eth1 bridge=xenbr1

This will effectively create one extra xenbr attached to eth1 interface. You can repeat the above command for all your interfaces, and you can stop them in the same manner, just replace start with stop.

To enable this automatically you can create file named, multi-network-bridge:

vim /etc/xen/scripts/multi-network-bridge

paste this:

#!/bin/sh
/etc/xen/scripts/network-bridge $@ vifnum=0 netdev=eth0 bridge=xenbr0
/etc/xen/scripts/network-bridge $@ vifnum=1 netdev=eth1 bridge=xenbr1

Of course you can add up as many interfaces you like in this script. After you have added your interfaces, you need to edit xend-config.spx file:

vim /etc/xen/xend-config.spx

Find a line defining network script, it should by default look like this:

(network-script network-bridge)

Edit it so it contains your newly created multi network bridge script. In my case it should look like:

(network-script multi-network-bridge)

All you need to do now is restart xend service:

/etc/init.d/xend restart

New network bridge named xenbr1 should be available now.

How can I add up another network bridge to my domU machine?

It's pretty simple actually, you already have defined vif statements for current network interface, all you need to do now is edit that domU config file, precisely vif line and add up another xenbr interface.

For example, if my domU vif line looks like this:

vif = ['ip=xx.xxx.167.4, vifname=vifbran0, rate = 10000KB/s, bridge=xenbr0']

with another xenbr interface it should look like this:

vif = ['ip=89.201.167.4, vifname=vifbran0, rate = 10000KB/s, bridge=xenbr0', 'ip=192.168.1.10, vifname=vifbran1, rate = 10000KB/s, bridge=xenbr1']

Also if you wish to use ip conflict prevention you must add additional mac section in vif configuration. Restart your domU and voila, another network interface is present

Preventing ip conflicts in xen

Mon, 22 Sep 2008 19:07:40 +0000

Lately I was playing with stock xen kernel and virtualization, and I came across one relatively big problem. Let’s say I want to share my guest machines to, let’s say clients. You must give them root… because that’s whats VPS-es all all about, having root access to OS without having to purchase expensive hardware. Having that in mind they are by default untrusted and unpredictable, they can do god knows what in there!

So what caught my eye?

By default xen, and available management tools, don’t really have a way of sorting out IP conflicts in bridged mode. Basically you have bunch of scripts that will provision VPS alongside with IP address. Looking at the conf files you have vif and IP declarations in vm_xen.conf file.

But what is really preventing clients from entering:

ifconfig eth0 xxx.xxx.xxx.xxx

where xxx is ip of some super important server in same netmask?

Luckily, I came across this problem while still in testing, here’s what I found and came up with after 3 days intensive googling.

Xen supports IP declaration in vif statment of domU config file like this:

vif = ['ip=xxx.xxx.xxx.xxx, more parametars here....']

Also you can declare multiple IP's by simply putting space between them, like this:

vif = ['ip=xxx.xxx.xxx.xx1 xxx.xxx.xxx.xx2, more parametars here....']

For the purpose of IP conflict prevention make sure you declare unique mac address in vif section to.

So what does this IP thingy in vif do? Absolutely nothing (at least not yet)!

Next step is to install ebtables (http://ebtables.sourceforge.net/) on your distro. Then all we need to do is patch up a vif-bridge script located in /etc/xen/scripts/

So here’s the diff:

--- vif-bridge-org 2008-07-30 21:26:16.000000000 +0200
+++ vif-bridge 2008-07-30 21:30:59.000000000 +0200
@@ -57,15 +57,35 @@
online)
setup_bridge_port "$vif"
add_to_bridge "$bridge" "$vif"
- ;;
-
+ ebtables -N $vif
+ ebtables -P $vif DROP
+ ebtables -A INPUT -i $vif -j $vif
+ ebtables -A FORWARD -i $vif -j $vif
+ ebtables -A $vif -p ARP --arp-opcode 1 -j ACCEPT
+
+ if [ ! -z "$ip" ]
+ then
+ for oneip in $ip
+ do
+ ebtables -A $vif -p IPv4 --ip-src $oneip -j ACCEPT
+ ebtables -A $vif -p IPv4 --ip-dst $oneip -j ACCEPT
+ ebtables -A $vif -p ARP --arp-opcode 2 --arp-ip-src $oneip -j ACCEPT
+ done
+ ebtables -A $vif --log-prefix="arp-drop" --log-arp -j DROP
+ fi
+ ;;
+
offline)
do_without_error brctl delif "$bridge" "$vif"
do_without_error ifconfig "$vif" down
- ;;
+ do_without_error ebtables -D INPUT -i $vif -j $vif
+ do_without_error ebtables -D FORWARD -i $vif -j $vif
+ do_without_error ebtables -F $vif
+ do_without_error ebtables -X $vif
+ ;;
esac-handle_iptable
+#handle_iptable
log debug "Successful vif-bridge $command for $vif, bridge $bridge."
if [ "$command" == "online" ]

Asuming you use bridging scripts this effectively restricts IP address(es) from "vif = ['ip=xxx.xxx.xxx.xxx']" list to mac addresses in vif list. Restrictoins are done while booting up VPS and removed when powering it off. This way untrusted user is limited only to IP addresses defined in xen guest conf file. Trying to change existing IP address into another IP on network will only render that machine unresponsive.