Use the following commands to install Xen on a Debian Etch machine:

apt-get install xen-linux-system-2.6.18-4-xen-686 libc6-xen bridge-utils

This will install the Xen kernel (2.6.18-5-xen-686 #1 SMP), the libc6-xen libraries which is optimized for the Xen hypervisor and the utilities for configuring the Linux ethernet bridge.

Next up is a reboot into your newly installed kernel:

reboot

Once the machine is back online you need to install the xen-tools package which allows you easily create new guest Xen domains on your Debian Etch host:

apt-get install xen-tools

Next, modify the Xen config file (/etc/xen/xend-config.sxp) and enable:

(network-script network-bridge)

You also need to modify /etc/xen-tools/xen-tools.conf to set kernel and initrd parameters as well as the disk and sizing options for your vistual servers.

You can easily find out what your kernel and initrd image is named by typing:

ls /boot/vmlinuz* /boot/initrd*

This will list the kernel and initrd names for your system. Remember, your after the xen kernel and initrd images!

/boot/initrd.img-2.6.18-5-xen-686

/boot/vmlinuz-2.6.18-5-xen-686

Continue and edit the xen-tools configuration file

vi /etc/xen-tools/xen-tools.conf

#
# Default kernel and ramdisk to use for the virtual servers
#
kernel = /boot/vmlinuz-2.6.18-5-xen-686
initrd = /boot/initrd.img-2.6.18-5-xen-686

dir = /data/vservers
debootstrap = 1
gateway   = 172.16.0.1
netmask   = 255.255.255.0

size   = 6Gb
memory = 256Mb
swap   = 256Mb
fs     = ext3
dist   = etch
image  = sparse

Next, create the directory where your virtual servers will reside:

mkdir -p /data/vservers/domains

Now your ready to create your first virtual server! Use the following command to create it:

xen-create-image -hostname=dns -ip=172.16.0.25 -passwd

It will take a minute or two to create the virtual server after which you can fire it up by using:

xm create dns.cfg

Your virtual server should be started up and ready for you to use.. You can either ssh to the IP you created the server with or attach to it from the host using:

xm console dns

Have fun with your Xen virtual machine!

Incoming search terms:

• bridge-utils programing (1)
• debian etch xentools (1)
• debian xen install (1)
• virtualisation centos debian xen (1)
• virtualisation xen noyau débian (1)

I do not issue any guarantee that this will work for you!

1 Preliminary Note

I want to serve the Icinga web interface from a vhost called www.example.com/example.com here with the document root /var/www/www.example.com/web.

You should have a working LEMP installation, as shown in this tutorial:

• Installing Nginx With PHP5 (And PHP-FPM) And MySQL Support On Ubuntu 11.10

A note for Ubuntu users:

Because we must run all the steps from this tutorial with root privileges, we can either prepend all commands in this tutorial with the string sudo, or we become root right now by typing

sudo su

2 Installing Fcgiwrap

As Icinga mostly uses CGI scripts, we need to install a CGI wrapper so that nginx can serve those scripts. We install fcgiwrap for this:

apt-get install fcgiwrap

3 Installing Icinga

Icinga can be installed as follows:

apt-get install icinga icinga-doc icinga-phpapi

You might see the following questions:

General type of mail configuration: <– Internet Site
System mail name: <– server1.example.com
Apache servers to configure for icinga: <– none (we don’t use Apache, so we don’t need to configure it)
Configure database for icinga-idoutils with dbconfig-common? <– No
Workgroup/Domain Name: <– WORKGROUP

4 Configuring PHP

Icinga has a PHP API, therefore we need PHP support if you want to use that API.

APC is a free and open PHP opcode cacher for caching and optimizing PHP intermediate code. It’s similar to other PHP opcode cachers, such as eAccelerator and XCache. It is strongly recommended to have one of these installed to speed up your PHP page.

APC can be installed as follows:

apt-get install php-apc

If you use PHP-FPM as your FastCGI daemon (like in Installing Nginx With PHP5 (And PHP-FPM) And MySQL Support On Ubuntu 11.10), restart it as follows:

/etc/init.d/php5-fpm restart

If you use lighttpd’s spawn-fcgi program as your FastCGI daemon (like in Installing Nginx With PHP5 And MySQL Support On Debian Squeeze), we must kill the current spawn-fcgi process (running on port 9000) and create a new one. Run

netstat -tap

to find out the PID of the current spawn-fcgi process:

root@server1:~# netstat -tap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 *:sunrpc                *:*                     LISTEN      734/portmap
tcp        0      0 *:www                   *:*                     LISTEN      2987/nginx
tcp        0      0 *:ssh                   *:*                     LISTEN      1531/sshd
tcp        0      0 *:57174                 *:*                     LISTEN      748/rpc.statd
tcp        0      0 localhost.localdom:smtp *:*                     LISTEN      1507/exim4
tcp        0      0 localhost.localdom:9000 *:*                     LISTEN      1542/php5-cgi
tcp        0      0 localhost.localdo:mysql *:*                     LISTEN      1168/mysqld
tcp        0     52 server1.example.com:ssh 192.168.0.198:2462      ESTABLISHED 1557/0
tcp6       0      0 [::]:www                [::]:*                  LISTEN      2987/nginx
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN      1531/sshd
tcp6       0      0 ip6-localhost:smtp      [::]:*                  LISTEN      1507/exim4
root@server1:~#

In the above output, the PID is 1542, so we can kill the current process as follows:

kill -9 1542

Afterwards we create a new spawn-fcgi process:

/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -g www-data -f /usr/bin/php5-cgi -P /var/run/fastcgi-php.pid

5 Configuring nginx

We must password-protect the Icinga web interface, therefore I create the password file /etc/icinga/htpasswd.users with the username icingaadmin. To create the password file, we need the tool htpasswd which is part of the apache2-utils package which we install as follows:

apt-get install apache2-utils

Afterwards we create the password file:

htpasswd -c /etc/icinga/htpasswd.users icingaadmin

The document root of my www.example.com web site is /var/www/www.example.com/web – if it doesn’t exist, create it as follows:

mkdir -p /var/www/www.example.com/web

Next we create an nginx vhost configuration for our www.example.com vhost in the /etc/nginx/sites-available/ directory as follows:

vi /etc/nginx/sites-available/www.example.com.vhost

server {
       listen 80;
       server_name www.example.com example.com;
       root /var/www/www.example.com/web;

       if ($http_host != "www.example.com") {
                 rewrite ^ http://www.example.com$request_uri permanent;
       }

       index index.php index.html index.htm;

       location = /favicon.ico {
                log_not_found off;
                access_log off;
                expires max;
       }

       location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
       }

       # Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac).
       location ~ /\. {
                deny all;
                access_log off;
                log_not_found off;
       }

       location / {
                root   /usr/share/icinga/htdocs;
                index  index.html;

                auth_basic              "Restricted";
                auth_basic_user_file    /etc/icinga/htpasswd.users;

       }

       location /icinga/stylesheets {
                alias /etc/icinga/stylesheets;
       }
       location /stylesheets {
                alias /etc/icinga/stylesheets;
       }
       location /icinga/images {
                alias /usr/share/icinga/htdocs/images;
       }

       location ~ \.cgi$ {
                # define root directory for CGIs
                root /usr/lib/cgi-bin/icinga;
                rewrite ^/icinga/cgi-bin/(.*)\.cgi /$1.cgi break;
                rewrite ^/cgi-bin/icinga/(.*)\.cgi /$1.cgi break;

                include /etc/nginx/fastcgi_params;
                fastcgi_pass  unix:/var/run/fcgiwrap.socket;
                fastcgi_index index.php;
                fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;

                auth_basic              "Restricted";
                auth_basic_user_file    /etc/icinga/htpasswd.users;

                fastcgi_param  AUTH_USER          $remote_user;
                fastcgi_param  REMOTE_USER        $remote_user;
       }

       location ~ ^/icinga-api/(.+\.php)$ {
                root   /usr/share/icinga/htdocs;
                try_files $uri =404;
                include /etc/nginx/fastcgi_params;
                fastcgi_pass 127.0.0.1:9000;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_index index.php;

                auth_basic              "Restricted";
                auth_basic_user_file    /etc/icinga/htpasswd.users;

                fastcgi_param  AUTH_USER          $remote_user;
                fastcgi_param  REMOTE_USER        $remote_user;
       }
}

To enable the vhost, we create a symlink to it from the /etc/nginx/sites-enabled/ directory:

cd /etc/nginx/sites-enabled/
ln -s /etc/nginx/sites-available/www.example.com.vhost www.example.com.vhost

Reload nginx for the changes to take effect:

/etc/init.d/nginx reload

That’s it! Now we can go to http://www.example.com. Log in with the username icingaadmin…

… and afterwards you should see the Icinga web interface:

If you want to learn more about Icinga configuration, please check out this tutorial: Server Monitoring With Icinga On Debian Squeeze

6 Links

• Icinga: https://www.icinga.org/
• Icinga Documentation: http://docs.icinga.org/latest/en/
• Nagios: http://www.nagios.org/
• nginx: http://nginx.org/
• nginx Wiki: http://wiki.nginx.org/
• Debian: http://www.debian.org/
• Ubuntu: http://www.ubuntu.com/

Incoming search terms:

• iso debian icinga (2)
• tutorial icinga debian (1)
• plesk sur wheezy (1)
• Nginx plesk 10 debian 6 (1)
• nginx php5 4 installer debian (1)
• ngingx centos icinga (1)
• Ngin On Debian Squeeze (1)
• apt-get install icinga (1)
• Icinga Tutorial Ubuntu (1)
• icinga iso (1)

2. Prerequisites

3. Asterisk PBX configurations

4. Explanation

4. Uploaded files

Incoming search terms:

• linux network callback (2)
• asterisk 10 callback (1)
• type=friend means that this user can make and receive calls (1)
• plesk micro updates 9 5 0 linux (1)
• network callback programming (1)
• linux CALLBACK windows (1)
• linux Callback Solution (1)
• linux callback example (1)
• Idefisk Examples (1)
• asterisk pbx callback for windows (1)

1. Installation

In order to compile mod_slotlimit, you will need to have apxs2 (APache eXtension tool) installed and configured with Apache.

The follow command will install it:

apt-get install apache2-prefork-dev

Now we download the source package present at http://sourceforge.net/projects/mod-slotlimit/ or download it using wget application and this direct link to the repository:

wget http://kent.dl.sourceforge.net/sourceforge/mod-slotlimit/mod_slotlimit.tar.gz

Next open archive, compile and install module with those commands:

tar zxvf mod_slotlimit.tar.gz
cd mod_slotlimit-1.0
make
make install

Add in the main config file of your web server the following command in order to load mod_slotlimit module.

vi /etc/apache2/httpd.conf

2. Configuration

Before we are able to write our configuration, we should known what directives are supported by this module.

For more information read mod_slotlimit’s documentation:

AvailableSlotsPercent – Percentage of apache slots available in order to activate dynamic slot allocation algorithm
MaxConnectionsPerSite – Max connections for each running site
LimitSite – Specific site to limit
LimitSiteConnections – Max connections for “LimitSite”
ClientIpLimit – Number of maximum simultaneous connection per IP
ForceVhostName – Force vhost hostname in scoreboard. Useful when vhost hostname do not match site visited, for example if you’re using mod_vhost_alias

Now we open config file of our web server in order to write the configuration:

vi /etc/apache2/apache2.conf

Finally we restart Apache:

/etc/init.d/apache2 restart

3. Links

• mod_slotlimit: http://sourceforge.net/projects/mod-slotlimit/
• Apache: http://httpd.apache.org
• Debian: http://www.debian.org

Incoming search terms:

• msc_pcre c:70: error: invalid application of âsizeofâ to incomplete type âpcre_extraâ (2)
• apache mod_slotlimit so windows (1)

I highly recommend you read the entire guide before you start, it will most certainly help.

There is a lot of swapping between client and server as I try my best to confuse you, so stay sharp!

Prerequisites

You will need all the required build tools installed as we are going to compile Samhain. Here is a quick refresher:

Red Hat

yum groupinstall “Development Tools”

Debian

apt-get install build-essential

NOTE: Please keep in mind that development tools on production servers is perhaps not the best of ideas. These packages may further assist the wannebe hacker, fill up precious megabyte or eat your cat. It is recommended to build the required packages on your build server, test them, create rpm / deb package and then deploy said packages on your production environment.

Here is a short check list to follow:

1. You will need MySQL and Apache running on your server. This guide will assume a vanilla MySQL and Apache configuration. I leave it up to the reader to figure out how to install and configure these services on your favourite distribution.
2. You will need the MySQL development package (generaly mysql-devel) installed for the server side of things.
3. MySQL must have a root password set. If the MySQL root password is not set, go and do that first. While your at MySQL, you may want to look at this : /usr/bin/mysql_secure_installation
4. The server and client(s) host name must be fully qualified.
5. The server and client(s) /etc/host file must be correct (really correct, not Red Hat default correct), and DNS must be working for both forward and reverse lookups.
6. Port 50888 TCP should be open, or whatever port you set when building.
7. ImageMagick is required on the client.

Download And Install

http://www.la-samhna.de/samhain/s_download.html

The above page has a full description of where to download the latest version of Samhain, and how to verify the integrity of the package. It is critical that the integrity of the package is checked. If you do not have a good foundation to build on, your house will surely crumble

Server Setup

Yule is the server side component of Samhain.

After you have extracted and checked the package, make sure you are the root user, in the top level directory of the unpacked source files.

We start by creating a user for the service, and generating a gpg key as that user:

adduser yule
su - yule
gpg --gen-key

You will be asked the following questions:

gpg (GnuPG) 1.4.5; Copyright (C) 2006 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
gpg: directory `/home/mytest/.gnupg’ created
gpg: new configuration file `/home/yule/.gnupg/gpg.conf’ created
gpg: WARNING: options in `/home/yule/.gnupg/gpg.conf’ are not yet active during this run
gpg: keyring `/home/yule/.gnupg/secring.gpg’ created
gpg: keyring `/home/yule/.gnupg/pubring.gpg’ created
Please select what kind of key you want:
(1) DSA and Elgamal (default)
(2) DSA (sign only)
(5) RSA (sign only)
Your selection? <– The default is fine, just press ENTER
DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096 <– 4096 For the paranoid
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 2y <– Some may feel 2 years is to long, it’s up to you …
Key expires at Sat 15 Dec 2012 22:24:38 GMT
Is this correct? (y/N) y <– If you are happy and you know it clap your hands
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
“Heinrich Heine (Der Dichter)<heinrichh@duesseldorf.de>”

Real name: yules <– Whatever name you want to use
Email address: yules@you.com <– Some e-mail address
Comment: 20 questions is a fun game
You selected this USER-ID:
“yules (20 questions) <yules@you.com>”

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O <– If you are happy, OK it
You need a Passphrase to protect your secret key.

Enter passphrase: This is a long passphrase ! <– Enter a strong passphrase
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
++++++++++++++++++++++++++++++++++++++++.++++++++++.++++++++++.++++++++++..+++++.+++++++++++++++.++++++++++.++++++++++++++++++++++++++++++
++++++++++………………………………………………………………………..+++++

Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 284 more bytes)

gpg: /home/yule/.gnupg/trustdb.gpg: trustdb created
gpg: key B7043C9A marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2012-12-15
pub 1024D/B7043C9A 2010-12-16 [expires: 2012-12-15]
Key fingerprint = 421E CFE8 533E 017F 95C8 170A DB54 28E7 B704 3C9A
uid yules (20 questions) <yules@you.com>
sub 4096g/EB230E29 2010-12-16 [expires: 2012-12-15]

Quit this shell, so that we are back to the root user.

exit

So now we have a gpg key, lets get on with building the packages.

The default gpg binary does not support the TIGER192 checksum. As such, we first build a vanilla Samhain binary so that we can get that capability from the Samhain binary.

./configure
make

Right, now we build the real thing …

./configure --with-gpg=/usr/bin/gpg --enable-network=server --with-database=mysql --enable-xml-log --with-port=50888 --enable-identity=yule
make
make install

At this point, the following should come up:

You need to sign the configuration file now
/usr/bin/gpg -a –clearsign yulerc
using –homedir /home/yule/.gnupg
gpg: WARNING: unsafe ownership on homedir `/home/yule/.gnupg’
You need a passphrase to unlock the secret key for
user: “yules (20 questions) <yules@you.com>”
1024-bit DSA key, ID BAFB6B91, created 2010-12-21
Enter passphrase: This is a long passphrase ! <– This is the passphrase we set earlier.

Side note: I am unsure why gpg is complaining about the ownership, as the permissions is just fine.

Now install the initialization script, set up MySQL user / permission and fix some file permissions.

make install-boot
mysql -p < sql_init/samhain.mysql.init
echo "grant select, insert on samhain.log to samhain@localhost IDENTIFIED BY 'samhain';" | mysql -p <-- This will ask for your root MySQL password.
echo "FLUSH PRIVILEGES;" | mysql -p <-- This will ask for your root MySQL password.
chown yule:yule /var/log/yule
chown yule:yule /etc/yulerc
chown yule:yule /var/lib/yule

Set yule to start at boot.

Red Hat

chkconfig --add yule
chkconfig yule on

Debian

update-rc.d yule defaults

Start yule with:

/etc/init.d/yule start

Yule may complain with something like :

<log sev=”WARN” tstamp=”2010-12-21T11:46:42+0000″ msg=”Invalid line 102 in configuration file: incorrect format, unrecognized option, or missing section header” />
<log sev=”WARN” tstamp=”2010-12-21T11:46:42+0000″ msg=”Invalid line 106 in configuration file: incorrect format, unrecognized option, or missing section header” />

However, the service should start fine. These two warnings are due to the [Database] header being commented out. Either uncomment it, or comment said two lines out. They are true by default.

For a list of configuration options with full explanations, see http://la-samhna.de/samhain/manual/compilation-options.html

Apache Configuration

Add the following in:

Red Hat

/etc/httpd/conf.d/samhain.conf

Debian

/etc/apache2/conf.d/samhain.conf

<Directory "/var/log/yule/">
   Options ExecCGI
   AllowOverride None
   Order allow,deny
   Allow from all
</Directory>
Alias /yule.html "/var/log/yule/yule.html"

Then reload Apache with:

Red Hat

service httpd restart

Debian

/etc/init.d/apache2 restart

Now visit http://yourserver/yule.hml

Client Setup

Log in on the server you wish to install the Samhain client on and make sure you are the root user. Also make sure you have all the essential build packages installed, refer to the overview for installation of these essential build packages.

First, we need a gpg key for root.

See previous example for detailed steps.

gpg –gen-key

Now we need to pull out the fingerprint for this key, so that we can use it when building the Samhain binary.

MY_FP=`gpg –fingerprint root | grep fingerpr | sed ‘s/ //g’ | awk ‘BEGIN { FS = “=” } ; {print $2}’`

As before, we need TIGER192 checksum capability first.

./configure
make

Now, since we are having a bit of fun, we are going to change the name of the binary and process. Classical security by obscurity. I’m picking the name john, a general purpose password cracker. Pick a name that will not stand out in a process listing and shout out “THIS IS A HIDS PROCESS !!!!11″. Then again, know how much/little a name change actually hides what this binary does before you rely on it to hide you’re HIDS from a l33t haxor.

We further specify that the configuration and data files should be pulled from the server. If you want to take this one step further, look into the following compile options : –enable-khide,–enable-suidcheck and –with-kcheck=/path/to/System.map

Make sure to change IP_OF_YOUR_SERVER to the actual IP address of your Yule server.

./configure –with-gpg=/usr/bin/gpg –enable-network=client –with-config-file=REQ_FROM_SERVER –with-data-file=REQ_FROM_SERVER/var/lib/john/john \
–enable-stealth=129 –enable-install-name=john –enable-srp –with-fp=$MY_FP –with-port=50888 \
–with-logserver=IP_OF_YOUR_SERVER –with-sender=john
make

Make the required directories, copy the binary over (with the correct name) and put the initialization script in place.

mkdir /var/lib/john/
cp init/samhain.startLinux /etc/init.d/john
chmod 744 /etc/init.d/john
cp samhain /usr/local/sbin/john
cp samhain_setpwd /usr/local/sbin/john_setpwd
cp samhain_stealth /usr/local/sbin/john_stealth
cd /usr/local/sbin

Set the password and overwrite the binary.

/usr/local/sbin/john_setpwd john jingle 161718abcd212324
mv john.jingle john

“jingle” Does not matter, it’s just the append and the number is what you want in 16 bit 0-9, A-F (A.K.A HEX). You can use yule -G on the server to generate a random number for you.

The output should look something like:

INFO old password found
INFO replaced: f7c312aaaa12c3f7 by: 161718abcd212324
INFO finished

Change the description in the initialization script.

sed -i ‘s/File Integrity Checking/Password Cracking/’ /etc/init.d/john

Make sure the daemon starts at boot.

Red Hat

chkconfig --add john
chkconfig john on

Debian

update-rc.d john defaults

A Little Work On The Server

The HEX key we just embedded in the client binary, we need it now to tell the server about that client.

/usr/local/sbin/yule -P 161718abcd212324 | sed ‘s/HOSTNAME/CliENT_HOSTNAME_HERE/’ >> /etc/yulerc <– Make sure to put the client host name (FQDN) in.

Edit /etc/yulerc and move the key above the GPG signature.

For example, the last couple of lines of /etc/yulerc mihgt look like this:

# Client=HOSTNAME@00000000@C39F0EEFBC64E4A8BBF72349637CC07577F714B420B62882
# Client=HOSTNAME@8F81BA58956F8F42@8932D08C49CA76BD843C51EDD1D6640510FA032A7A2403E572BBDA2E5C6B753991CF7E091141D20A2499C5CD3E14C1639D17482E14E1548E5246ACF4E7193D524CDDAC9C9D6A9A36C596B4ECC68BEB0C5BB7082224946FC98E3ADE214EA1343E2DA8DF4229D4D8572AD8679228928A787B6E5390D3A713102FFCC9D0B2188C92
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFNEI7oerU1Wrr7a5ERAkWqAJ9sZEuRLp8rPOjXdUokT03bEfjGuwCfa+Tr
pDK7/KmGj3Hx8vRMufxNx7A=
=zI4S
-----END PGP SIGNATURE-----
Client=rhc2.sys.local@F1DF72033799940C@37FC42534A812B2351007A24820537466495F97ED352EFC1D9DCAEACBBF5CB98AEF183057CE6D101151F112693C2DAE361435CED1C95E822272FE287A56B4D38EE91B00830A56AE2F26E4738DF099CAEF3372342BE0ACDB78C12FD176EED1FBA376A0399537F848B6FA9AD4E61E6C771A5566F43D62C1F9836AB976CB1111545

We need to change that to look like this:

# Client=HOSTNAME@00000000@C39F0EEFBC64E4A8BBF72349637CC07577F714B420B62882
# Client=HOSTNAME@8F81BA58956F8F42@8932D08C49CA76BD843C51EDD1D6640510FA032A7A2403E572BBDA2E5C6B753991CF7E091141D20A2499C5CD3E14C1639D17482E14E1548E5246ACF4E7193D524CDDAC9C9D6A9A36C596B4ECC68BEB0C5BB7082224946FC98E3ADE214EA1343E2DA8DF4229D4D8572AD8679228928A787B6E5390D3A713102FFCC9D0B2188C92
Client=rhc2.sys.local@F1DF72033799940C@37FC42534A812B2351007A24820537466495F97ED352EFC1D9DCAEACBBF5CB98AEF183057CE6D101151F112693C2DAE361435CED1C95E822272FE287A56B4D38EE91B00830A56AE2F26E4738DF099CAEF3372342BE0ACDB78C12FD176EED1FBA376A0399537F848B6FA9AD4E61E6C771A5566F43D62C1F9836AB976CB1111545
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFNEI7oerU1Wrr7a5ERAkWqAJ9sZEuRLp8rPOjXdUokT03bEfjGuwCfa+Tr
pDK7/KmGj3Hx8vRMufxNx7A=
=zI4S
-----END PGP SIGNATURE-----

The following steps are always required when you’ve made changes to the configuration files.

Edit /etc/yulerc and remove the first 3 and last 7 lines, this is the GPG/PGP signature.

Example:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
There will be another line here later on.
#####################################################################
#
# Configuration file template for yule.
#
#####################################################################

Lots of Yule configuration removed ...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFNEI7oerU1Wrr7a5ERAkWqAJ9sZEuRLp8rPOjXdUokT03bEfjGuwCfa+Tr
pDK7/KmGj3Hx8vRMufxNx7A=
=zI4S
-----END PGP SIGNATURE-----

Then sign the configuration file again with the user yule and copy the file in place as the root user:

su – yule
gpg -o yulerc.asc -a –clearsign –not-dash-escaped /etc/yulerc <– Type in the passphrase we set earlier.
exit
/bin/mv /home/yule/yulerc.asc /etc/yulerc
service yule reload

A Little More Work On The Client

We will need to create the configuration file and embed it into a postscript file. Make sure you have Imagemagick installed, as you will need convert.

Go and download a good looking picture like http://apod.nasa.gov/apod/image/0903/tycho_chandra_big.jpg. You will want at least a 200K size image, if not larger, to hide the configuration file in it. Also, it is handy to have an original configuration file as backup.

NOTE: The following steps has to be done each time you wish to modify the configuration file of the client.

cd TOPLEVEL_OF_SOURCE_DIR
wget http://apod.nasa.gov/apod/image/0903/tycho_chandra_big.jpg
convert tycho_chandra_big.jpg tycho_chandra_big.ps <– Convert the JPG to a postscript file.
cp samhainrc.linux rc.`hostname` <– Get a default configuration.
gpg -a –clearsign –not-dash-escaped rc.`hostname` <– Clear sign the configuration.
mv rc.`hostname`.asc rc.`hostname` <– Move the signed file to the normal file name for the configuration file.
/usr/local/sbin/john_stealth -s tycho_chandra_big.ps rc.`hostname`<– Steganographically hide the configuration file inside the postscript file.
rm rc.`hostname` tycho_chandra_big.* <– Remove the “clean” files.

Make sure that the resulting postscript file is not very large, or Samhain will fail to download it. I do not have exact numbers, but from experience 66Mb is too large

Now copy the file over to your server:

scp tycho_chandra_big.ps YULE_SERVER:~/rc.`hostname` <– Assuming scp with root. In real life, please do not open ssh for root.

Back to the server:

cp ~/rc.CliENT_FQDN /var/lib/yule/ <– Make sure to fill in the clients FQDN.
chown yule:yule /var/lib/yule/rc.CliENT_FQDN <– Make sure to fill in the clients FQDN.

Back to the client:

/usr/local/sbin/john -t init -p info

This will now build the database in /var/lib/john. Don’t worry about all the output at this stage, we are just getting things up and running now.

After we have a database, we have to sign it and copy it over to the server.

gpg -a –clearsign –not-dash-escaped /var/lib/john/john
scp /var/lib/john/john.asc YULE_SERVER:~/file.`hostname` <– Assuming scp with root. In real life, please do not open ssh for root.
rm /var/lib/john/john*

Back to the server, we move this file to the correct place:

mv ~/file.CliENT_FQDN /var/lib/yule
chown yule:yule /var/lib/yule/*

It is important that all configuration files start with rc and all database files start with file.

Troubleshooting

Trouble, what trouble?

1. Start with tailing the log file on the server : tail -f /var/log/yule/yule_log
2. Change the log level in /etc/yulerc to info or above (always remember to re-sign the configuration file as described).
3. Recompile without some of the options to test.
4. Have a look at this link : http://www.la-samhna.de/samhain/s_documentation.html

Clean Up

Now we don’t want to be leaving breadcrumbs behind us, some clean up is required.

1. Delete all the source files and any tarballs that was downloaded if you built directly on a production server.
2. Delete all entries from your shell history.
3. Remove all the development packages that was installed if you built directly on a production server.
4. Remove /usr/local/sbin/john_stealth and /usr/local/sbin/john_setpwd.

Basically, get rid of any evidence of what you just did.

Tuning

Arguably, this is where the guide should start. Samhain does not understand what is right and what is wrong for this particular server. As such, you need to tune it. The simplest way is to build Samhain without any options what so ever like:

./configure
make
mkdir /var/lib/samhain/

Put the configuration file in /etc/samhainrc, and run

samhain -t init -p info > my_output 2>&1

You can then examine the output file and make the appropriate changes to the Samhain configuration file. The database will be created in /var/lib/samhain. Do not run samhain -t init more than once without deleting the database.

Once you are happy with the configuration, build Samhain in server / client mode.

NOTE: It is however rather important that you profile your server and tune Samhain before it is connected to the Internet.

Honey Pot!

Now for a bit of fun. We really do want intruders to let us know they are on our system. So, we create 2 (or more) files with catchy names and tell Samhain to monitor those files for any changes (that includes access times).

cp /etc/passwd /home/cracked_passwords
cp /etc/hosts /home/customers/credit_cards_2008.xls

Now, in Samhain’s configuration file, there is a section called [IgnoreNone], add these files in that section. You can test this by simply catting those files and then run the check. The output should be something like:

CRIT : [2009-04-27T21:33:11+0100] msg=<POliCY [User1] ——–T->, path=</home/cracked_passwords>, atime_old=<[2009-04-27T20:25:39]>,
atime_new=[2009-04-27T20:32:37]>,

Nagios Integration

I have not tested this yet, this is just on top of my head, so it may well be very wrong.

So now we have alerts for when things go wrong. By default, the standard Nagios plugin pack ships with check_log. Our Nagios check command will look something like:

check_log -F /var/log/yule_log -O /var/log/yule/yule_nagios_diff_log -q "ERROR|CRIT|ALERT"

You will need to modify how to alert on this particular service. By default Nagios will check 3 times before alerting, but with check_log you will never get an alert. The reason is as follows:

1. check 1: The check returns an error, as it spotted your query (lets say CRIT) in the difference from the old stored log file and the current running log file. The check command now updates the old stored log file.
2. check 2: There is no longer a difference between the old stored log file and the current running one, thus the check passes OK.

Either modify Nagios to alert after a single failure, or write a wrapper specifically for this check to create a lock file somewhere. You then check for this lock file and alert if it exists. Both approaches have some down sides. If we alert on a single check, be prepared for false alerts due to packet loss or a shift in the force. If we create a lock file, you will have to manually remove it.

Now that we are monitoring the log file for changes detected, we also need to monitor that the client process is still up and running. Of course, you will also want to monitor that the server process is running all the time.

I am sure someone will come up with a better way of Nagios integration, like I said, this is just thinking out loud.

What It All Means

At the end of the day, the clear text configuration of each machine being monitored, is neither kept on the client nor on the server. The clear text configuration files should be kept on a different machine inside an encrypted partition.

Nagios makes sure we are alerted of anything (via e-mail or SMS) and hopefully, an intruder will bite on the honey so that we can see him, potentially, even quicker.

Further more, you can not access any help files (such as ./samhain –help or man pages) to indicate that there is a HIDS running on the client.

Of course, if you get access to the server, you can see all the clients who logs in. There are further compiler options so that the logs are also encrypted.

Layers

In the voice of Shrek: “Security is like an onion, it has many layers.” Remember that host based intrusion detection is just one more layer in this onion. You also need a good firewall, network intrusion detection, monitoring, centralised logging, log analysis, TCP wrappers, SELinux (or some other mandatory access control mechanism), brute force blockers like fail2ban and much more.

As an example of this, the entire host based intrusion detection is rendered moot if the hacker just kills the process and you are not using monitoring to make sure that the service is running.

Please do not hesitate to contact me with any corrections or improvements or even some constructive criticism.

Incoming search terms:

• samhain centos (2)
• centos intrusion detection (2)
• installing samhain centos (2)
• SAMHAIN windows (2)
• samhain plesk (2)
• samhain install on windows machine (1)
• samhain linux (1)
• samhain network (1)
• samhain rhel6 (1)
• samhain server reverse lookup failed (1)

A. You can migrate users from old Linux server to new Linux sever with standard commands such as tar, awk, scp and others. This is also useful if you are using old Linux distribution such as Redhat 9 or Debian 2.x.

Following files/dirs are required for traditional Linux user management:
* /etc/passwd – contains various pieces of information for each user account

* /etc/shadow – contains the encrypted password information for user’s accounts and optional the password aging information.

* /etc/group – defines the groups to which users belong

* /etc/gshadow – group shadow file (contains the encrypted password for group)

* /var/spool/mail – Generally user emails are stored here.

* /home – All Users data is stored here.

You need to backup all of the above files and directories from old server to new Linux server.

Commands to type on old Linux system

First create a tar ball of old uses (old Linux system). Create a directory:
# mkdir /root/move/
Setup UID filter limit:
# export UGIDLIMIT=500
Now copy /etc/passwd accounts to /root/move/passwd.mig using awk to filter out system account (i.e. only copy user accounts)
# awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > /root/move/passwd.mig
Copy /etc/group file:
# awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > /root/move/group.mig
Copy /etc/shadow file:
# awk -v LIMIT=$UGIDLIMIT -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/passwd | tee - |egrep -f - /etc/shadow > /root/move/shadow.mig
Copy /etc/gshadow (rarely used):
# cp /etc/gshadow /root/move/gshadow.mig
Make a backup of /home and /var/spool/mail dirs:
# tar -zcvpf /root/move/home.tar.gz /home
# tar -zcvpf /root/move/mail.tar.gz /var/spool/mail

Where,

• Users that are added to the Linux system always start with UID and GID values of as specified by Linux distribution or set by admin. Limits according to different Linux distro:
  • RHEL/CentOS/Fedora Core : Default is 500 and upper limit is 65534 (/etc/libuser.conf).
  • Debian and Ubuntu Linux : Default is 1000 and upper limit is 29999 (/etc/adduser.conf).
• You should never ever create any new system user accounts on the newly installed Cent OS Linux. So above awk command filter out UID according to Linux distro.
• export UGIDLIMIT=500 – setup UID start limit for normal user account. Set this value as per your Linux distro.
• awk -v LIMIT=$UGIDLIMIT -F: ‘($3>=LIMIT) && ($3!=65534)’ /etc/passwd > /root/move/passwd.mig – You need to pass UGIDLIMIT variable to awk using -v option (it assigns value of shell variable UGIDLIMIT to awk program variable LIMIT). Option -F: sets the field separator to : . Finally awk read each line from /etc/passwd, filter out system accounts and generates new file /root/move/passwd.mig. Same logic is applies to rest of awk command.
• tar -zcvpf /root/move/home.tar.gz /home – Make a backup of users /home dir
• tar -zcvpf /root/move/mail.tar.gz /var/spool/mail – Make a backup of users mail dir

Use scp or usb pen or tape to copy /root/move to a new Linux system.
# scp -r /root/move/* user@new.linuxserver.com:/path/to/location

Commands to type on new Linux system

First, make a backup of current users and passwords:
# mkdir /root/newsusers.bak
# cp /etc/passwd /etc/shadow /etc/group /etc/gshadow /root/newsusers.bak

Now restore passwd and other files in /etc/
# cd /path/to/location
# cat passwd.mig >> /etc/passwd
# cat group.mig >> /etc/group
# cat shadow.mig >> /etc/shadow
# /bin/cp gshadow.mig /etc/gshadow

Please note that you must use >> (append) and not > (create) shell redirection.

Now copy and extract home.tar.gz to new server /home
# cd /
# tar -zxvf /path/to/location/home.tar.gz

Now copy and extract mail.tar.gz (Mails) to new server /var/spool/mail
# cd /
# tar -zxvf /path/to/location/mail.tar.gz

Now reboot system; when the Linux comes back, your user accounts will work as they did before on old system:
# reboot

Please note that if you are new to Linux perform above commands in a sandbox environment. Above technique can be used to UNIX to UNIX OR UNIX to Linux account migration. You need to make couple of changes but overall the concept remains the same.

Further readings

• Read man pages of awk, passwd(5), shadow(5), group(5), tar command

Updated for accuracy.

Incoming search terms:

• move or migrate user accounts from old server to a new centos server (3)
• cpanel user accounts /etc/passwd (1)
• plesk /etc/passwd (1)
• move maildir on plesk to directadmin (1)
• migrating plesk to directadmin (1)
• migrate users to new centos server (1)
• migrate mail from linux plesk to cpanel (1)
• migrate cpanel uid mail (1)
• mail migration plesk windows linux (1)
• shell script for migrate groups /etc/group (1)

Why LEMP instead of LAMP? NGINX is a great replacement for Apache with very low memory footprint and great stability.

Note: i will use the name yourdomain.com for all configurations on a fresh minimal installation of Ubuntu Feisty Fawn server edition.

We will have to install first Postfix to deal with emails and then Dovecot to deliver them with pop3 only (imap uses too much memory). But before that, let’s install some useful tools we need:

apt-get install wget telnet build-essential

1. Installation of Postfix

apt-get install postfix libsasl2 sasl2-bin libsasl2-modules libdb3-util procmail

Now the beautiful blue screen will appear and Postfix will ask you some questions. Answer as follow:

General type of configuration? <– Internet Site
Mail name? <– yourdomain.com

Then run:

dpkg-reconfigure postfix

Again, you’ll be asked some questions:

General type of configuration? <– Internet Site
Where should mail for root go <– [blank]
Mail name? <– yourdomain.com
Other destinations to accept mail for? (blank for none) <– yourdomain.com, localhost.yourdomain.com, localhost.localdomain, localhost
Force synchronous updates on mail queue? <– No
Local networks? <– 127.0.0.0/8
Use procmail for local delivery? <– Yes
Mailbox size limit <– 0
Local address extension character? <– +
Internet protocols to use? <– all

Type then the following commands (you can copy everything below and paste it in your terminal in one row, it will work but don’t forget to hit enter to validate the last command):

postconf -e ‘smtpd_sasl_local_domain =’
postconf -e ‘smtpd_sasl_auth_enable = yes’
postconf -e ‘smtpd_sasl_security_options = noanonymous’
postconf -e ‘broken_sasl_auth_clients = yes’
postconf -e ‘smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination’
postconf -e ‘inet_interfaces = all’
echo ‘pwcheck_method: saslauthd’ >> /etc/postfix/sasl/smtpd.conf
echo ‘mech_list: plain login’ >> /etc/postfix/sasl/smtpd.conf

Now we have to create the certificates for TLS that will be available both for Postfix and Dovecot:

mkdir /etc/ssl/yourdomain (the folder name can be of course anything such as the name of your mother…)
cd /etc/ssl/yourdomain
openssl genrsa -des3 -rand /etc/hosts -out yourdomain.key 1024

chmod 600 yourdomain.key
openssl req -new -key yourdomain.key -out yourdomain.csr

openssl x509 -req -days 3650 -in yourdomain.csr -signkey yourdomain.key -out yourdomain.crt

openssl rsa -in yourdomain.key -out yourdomain.key.unencrypted

mv -f yourdomain.key.unencrypted yourdomain.key
openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650

Next we configure Postfix for TLS:

postconf -e ‘smtpd_tls_auth_only = no’
postconf -e ‘smtp_use_tls = yes’
postconf -e ‘smtpd_use_tls = yes’
postconf -e ‘smtp_tls_note_starttls_offer = yes’
postconf -e ‘smtpd_tls_key_file = /etc/ssl/yourdomain/yourdomain.key’
postconf -e ‘smtpd_tls_cert_file = /etc/ssl/yourdomain/yourdomain.crt’
postconf -e ‘smtpd_tls_CAfile = /etc/ssl/yourdomain/cacert.pem’
postconf -e ‘smtpd_tls_loglevel = 1′
postconf -e ‘smtpd_tls_received_header = yes’
postconf -e ‘smtpd_tls_session_cache_timeout = 3600s’
postconf -e ‘tls_random_source = dev:/dev/urandom’
postconf -e ‘myhostname = yourdomain.com’

Restart Postfix:

/etc/init.d/postfix restart

Authentication will be done by saslauthd. We have to change a few things to make it work properly. Because Postfix runs chrooted in /var/spool/postfix we have to do the following:

mkdir -p /var/spool/postfix/var/run/saslauthd

Now we have to edit /etc/default/saslauthd in order to activate saslauthd. Set START to yes and change the line OPTIONS=”-c” to OPTIONS=”-c -m /var/spool/postfix/var/run/saslauthd -r”:

vi /etc/default/saslauthd

#
# Settings for saslauthd daemon
#
# Should saslauthd run automatically on startup? (default: no)
START=yes
# Which authentication mechanisms should saslauthd use? (default: pam)
#
# Available options in this Debian package:
# getpwent  -- use the getpwent() library function
# kerberos5 -- use Kerberos 5
# pam       -- use PAM
# rimap     -- use a remote IMAP server
# shadow    -- use the local shadow password file
# sasldb    -- use the local sasldb database file
# ldap      -- use LDAP (configuration is in /etc/saslauthd.conf)
#
# Only one option may be used at a time. See the saslauthd man page
# for more information.
#
# Example: MECHANISMS="pam"
MECHANISMS="pam"
# Additional options for this mechanism. (default: none)
# See the saslauthd man page for information about mech-specific options.
MECH_OPTIONS=""
# How many saslauthd processes should we run? (default: 5)
# A value of 0 will fork a new process for each connection.
THREADS=5
# Other options (default: -c)
# See the saslauthd man page for information about these options.
#
# Example for postfix users: "-c -m /var/spool/postfix/var/run/saslauthd"
# Note: See /usr/share/doc/sasl2-bin/README.Debian
OPTIONS="-c  -m /var/spool/postfix/var/run/saslauthd -

Start then saslauthd:

/etc/init.d/saslauthd start

To see if SMTP-AUTH and TLS work properly now run the following command:

telnet yourdomain.com 25

After you have established the connection to your Postfix mail server type

ehlo yourdomain.com

The output should look something like:

250-yourdomain.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

We have now Postfix running. If you add users (adduser command) Postfix will deliver then directly emails in users mail box located in the home folder.

2. Installation of Dovecot

Dovecot configuration is pretty straight forward (remember we will use only pop3 protocol to save memory):

apt-get install dovecot-common dovecot-pop3d

Open then dovecot conf situated in /etc/dovecot/. You have to add manually the protocol you want to use (pop3 pop3s

# Protocols we want to be serving: imap imaps pop3 pop3s
# If you only want to use dovecot-auth, you can set this to "none".
#protocols = imap imaps
protocols = pop3s pop3

And uncomment the two following lines to tell Dovecot where to fint the certificate you have creted earlier

ssl_cert_file = /etc/ssl/yourdomain/yourdomain.crt
ssl_key_file = /etc/ssl/yourdomain/yourdomain.key

You have then to restart Dovecot

/etc/init.d/dovecot restart

and we have now a functionnal mail server.

3. Installation of PHP5 (along with xcache)

apt-get install php5-cli php5-cgi php5-mysql php5-xcache

Note that xcache has to be implemented manually by adding the following lines in the php.ini located in /etc/php5/cgi/ (please tune this config according to your system).

[xcache-common]
extension = xcache.so
[xcache.admin]
xcache.admin.user = "mOo"
; xcache.admin.pass = md5($your_password)
xcache.admin.pass = ""
[xcache]
; ini only settings, all the values here is default unless explained
; select low level shm/allocator scheme implemenation
xcache.shm_scheme =        "mmap"
; to disable: xcache.size=0
; to enable : xcache.size=64M etc (any size > 0) and your system mmap allows
xcache.size  =                32M
; set to cpu count (cat /proc/cpuinfo |grep -c processor)
xcache.count =                 1
; just a hash hints, you can always store count(items) > slots
xcache.slots =                8K
; ttl of the cache item, 0=forever
xcache.ttl   =                 0
; interval of gc scanning expired items, 0=no scan, other values is in seconds
xcache.gc_interval =           0
; same as aboves but for variable cache
xcache.var_size  =            32M
xcache.var_count =             1
xcache.var_slots =            8K
; default ttl
xcache.var_ttl   =             0
xcache.var_maxttl   =          0
xcache.var_gc_interval =     300
xcache.test =                Off
; N/A for /dev/zero
xcache.readonly_protection = Off
; for *nix, xcache.mmap_path is a file path, not directory.
; Use something like "/tmp/xcache" if you want to turn on ReadonlyProtection
; 2 group of php won't share the same /tmp/xcache
; for win32, xcache.mmap_path=anonymous map name, not file path
xcache.mmap_path =    "/dev/zero"
; leave it blank(disabled) or "/tmp/phpcore/"
; make sure it's writable by php (without checking open_basedir)
xcache.coredump_directory =   ""
; per request settings
xcache.cacher =               On
xcache.stat   =               On
xcache.optimizer =            On
[xcache.coverager]
; per request settings
; enable coverage data collecting for xcache.coveragedump_directory and xcache_coverager_start/stop/get/clean() functions (will hurt executing performance)
xcache.coverager =          Off
; ini only settings
; make sure it's readable (care open_basedir) by coverage viewer script
; requires xcache.coverager=On
xcache.coveragedump_directory = ""

Note: you have to adjust manually the xcache.size and xcache.var_size according to your server (it’s on 0 by default, meaning that xcache isn’t enabled at all). One other thing is the xcache.count variable. If you have a vps that takes advantage of 2 processors, you can put 2 instead of one.

You can do that right now even if your php configuration isn’t loaded yet so everything will be in good order when Nginx and fcgi process will be started.

4. Installation of Mysql and PhpMyAdmin

apt-get install mysql mysql-server

There is often a problem with mysql to setup the root password. So the best thing to do is first stopping mysql:

/etc/init.d/mysql stop

Then update the user table

mysqld –skip-grant-tables –skip-networking &

mysql mysql

UPDATE user SET password=PASSWORD(‘yourrootpassword’) WHERE User=”root” AND Host=”localhost”;

quit

/etc/init.d/mysql restart

5. Installation of NGINX (Ubuntu only, see below for Debian users)

The nginx version proposed by Feisty is a prehistoric one (not to mention drapper). Fortunately, there’s a place you can get the latest stable version, or if you are adventurous, the latest dev version.

Note for Debian users: I didn’t find a recent .deb package so you have either the choice to compile from sources or to do a apt-get install nginx to have a not so new version. For more informations about Nginx please go to the Nginx Wiki website. You can find there the sources and a good doc about all the modules (ssl, auth_basic and so on).

wget http://technokracy.net/nginx/nginx_0.5.32~grrr-1_i386.deb

(Note that if you are running on AMD replace i386 by amd64.)

Then type:

dpkg -i nginx_0.5.32~grrr-1_i386.deb

Nginx is now up and running on default port 8000 (just in case you already have Apache or anything else on port 80).

The default root folder is Nginx-default and is located in /var/www/

To change that and to start to listen to the fast-cgi we will launch next, you have to open /etc/nginx/sites-available/default.

vi /etc/nginx/sites-available/default

You can find there all the obvious options to change and add (or uncomment the original php paragraph):

        location ~ \.php$ {
        include /etc/nginx/fastcgi_params;
        fastcgi_pass  127.0.0.1:9000;
        fastcgi_index index.php;
        fastcgi_param  SCRIPT_FILENAME  /var/www/nginx-default$fastcgi_script_name;
    }

We’ve just asked Nginx to listen to fcgi on port 9000. So we have to start now the fcgi process. I’ve chosen to use spawn-fcgi and to make my own init script of it (so the process will start after reboot). To have spawn-fcgi you have to get lighttpd configured but without the need to install it. Let’s grab the latest version:

wget http://www.lighttpd.net/download/lighttpd-1.4.18.tar.bz2

tar -xvjf lighttpd-1.4.18.tar.bz2

cd lighttpd-1.4.18

./configure

make

cp src/spawn-fcgi /usr/bin/spawn-fcgi

Note that we did not type make install so lighttpd is not running!

Then we create a shell script we can call php-fastcgi or whatever you want and place that file in /usr/bin/ to make it simple (as php5-cgi and spawn-fcgi are already there…).

touch /usr/bin/php-fastcgi

Then edit it:

vi /usr/bin/php-fastcgi

and add the following:

#!/bin/sh
/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -f /usr/bin/php5-cgi

That means every time this script will be called, fcgi will be spawned on port 9000 for user www-data (default user).

To make it work at startup we need now to create an init script:

touch /etc/init.d/init-fastcgi

Edit and add:

vi /etc/init.d/init-fastcgi

#!/bin/bash
PHP_SCRIPT=/usr/bin/php-fastcgi
RETVAL=0
case "$1" in
    start)
      $PHP_SCRIPT
      RETVAL=$?
  ;;
    stop)
      killall -9 php
      RETVAL=$?
  ;;
    restart)
      killall -9 php
      $PHP_SCRIPT
      RETVAL=$?
  ;;
    *)
      echo "Usage: php-fastcgi {start|stop|restart}"
      exit 1
  ;;
esac
exit $RETVAL

You may have to change the permissions there by typing:

chmod 755 /etc/init.d/init-fastcgi

Check then if it works by typing:

/etc/init.d/init-fastcgi start

You should have an answer from spawn-fcgi attributing a PID process. To make now everything working after reboot type:

update-rc.d init-fastcgi defaults

And we are done. To check if php is working as fast-cgi you can first type:

ps ax | grep php

To check then if Nginx is listening to php, create an echo command in an empty php file:

<? echo phpinfo(); ?>

Incoming search terms:

• nginx directadmin (9)
• lemp howto (5)
• lemp with cpanel (3)
• vm lemp nginx (2)
• directadmin nginx howto (2)
• install lemp rhel6 (1)
• ubuntu libdb3-util (1)
• rhel6 /etc/saslauthd conf (1)
• postfix ldap dovecot ubuntu (1)
• cpanel replacement lemp (1)

=> Install lighttpd
=> Prepare the file system for the jail
=> Run FastCGI PHP and MySQL from the jail
=> Add Perl support to the jail
=> Take care of sendmail
=> Run multiple domains (virtual hosting) from chrooted jail etc

Please note that information outlined below is for advanced UNIX users or admins only .

Note: If you are using Ubuntu Linux read this howto.

Step # 1: Install lighttpd, php4-cgi and mysql server

Use apt-get command to install packages:# apt-get install lighttpd php4-cgi php4-cli php4-mysql mysql-server Note: If you need other php modules just install them using apt-get command.

Step # 2: Prepare the file system

Create a directory called /webroot:# mkdir /webroot

Create temporary /webroot/tmp directory:# mkdir /webroot/tmp/
# chmod 1777 /webroot/tmp/

Create /etc directory to store php.ini file:# mkdir /webroot/etc

Create a log directory for lighttpd web server:# mkdir -p /webroot/var/log/lighttpd
# chown www-data:www-data /webroot/var/log/lighttpd

Create a cache directory:# mkdir -p /webroot/var/tmp/lighttpd/cache/compress/
# chown www-data:www-data /webroot/var/tmp/lighttpd/cache/compress/

Create a lighttpd home directory for virtual hosting
# mkdir -p /webroot/home/lighttpd
# chown www-data:www-data /webroot/home/lighttpd
# chmod 0700 /webroot/home/lighttpd
# ls -dl /webroot/home/lighttpd
Output:

drwx------  2 www-data www-data 4096 Oct  5 23:15 /webroot/home/lighttpd

A handy shell script (l2chroot [download] ) to copy necessary shared system libraries:

#!/bin/bash
BASE="/webroot"
if [ $# -eq 0 ]; then
  echo "Syntax : $0 /path/to/executable"
  echo "Example: $0 /usr/bin/php5-cgi"
  exit 1
fi
[ ! $BASE ] && mkdir -p $BASE || :
# iggy ld-linux* file as it is not shared one
FILES="$(ldd $1 | awk '{ print $3 }' |egrep -v ^'\(')"
echo "Copying shared files/libs to $BASE..."
for i in $FILES
do
  d="$(dirname $i)"
  [ ! -d $BASE$d ] && mkdir -p $BASE$d || :
  /bin/cp $i $BASE$d
done
# copy /lib/ld-linux* or /lib64/ld-linux* to $BASE/$sldlsubdir
# get ld-linux full file location
sldl="$(ldd $1 | grep 'ld-linux' | awk '{ print $1}')"
# now get sub-dir
sldlsubdir="$(dirname $sldl)"
if [ ! -f $BASE$sldl ];
then
  echo "Copying $sldl $BASE$sldlsubdir..."
  /bin/cp $sldl $BASE$sldlsubdir
else
  :
fi

Put l2chroot in /bin directory and set executable permission:# wget http://www.cyberciti.biz/files/lighttpd/l2chroot.txt
# mv l2chroot.txt l2chroot
# cp l2chroot /bin
# chmod +x /bin/l2chroot

Step 3: Put PHP in the jail

Now you need to copy PHP executable files and necessary extensions (php-mysql) to /webroot directory.
# mkdir -p /webroot/usr/bin
# cp /usr/bin/php4-cgi /webroot/usr/bin/
# cp /usr/bin/php4 /webroot/usr/bin/
Copy /etc/php4/cgi/php.ini file to /webroot/etc/ directory.
# cd /webroot/etc/
# cp -avr /etc/php4 .

Now copy other config files in jail:
# cp /etc/hosts /webroot/etc/
# cp /etc/nsswitch.conf /webroot/etc/
# cp /etc/resolv.conf /webroot/etc/
# cp /etc/services /webroot/etc/
# cp /etc/localtime /webroot/etc/

Copy all php shared libraries used by /usr/bin/php4 and /usr/bin/php4-cgi using your l2chroot script:
# /bin/l2chroot /usr/bin/php4
# /bin/l2chroot /usr/bin/php4-cgi

Now you have all shared libraries in /webroot directory. You can verify this with ls command. There is one more file, which you need to copy manually – /lib/ld-linux.so.2:
# cp /lib/ld-linux.so.2 /webroot/lib

Step 4: Put php MySQL extension in the jail

To access MySQL database server you need to use php4-mysql extension.
Copy php mysql extension from /usr/lib/php4/20050606 directory, use following command to determine exact location of mysql.so file:
# dpkg -L php4-mysqlOutput:

/.
/usr
/usr/lib
/usr/lib/php4
/usr/lib/php4/20050606
/usr/lib/php4/20050606/mysql.so
/usr/share
/usr/share/doc
/usr/share/doc/php4-mysql

Copy /usr/lib/php4/20050606/mysql.so file to /webroot/usr/lib/php4/20050606/mysql.so and related shared libs using /bin/l2chroot script:
# mkdir -p /webroot/usr/lib/php4/20050606
# cp /usr/lib/php4/20050606/mysql.so /webroot/usr/lib/php4/20050606/
# /bin/l2chroot /usr/lib/php4/20050606/mysql.so

Repeat above procedure to copy all your php shared modules such as php-imap (required for webmail), php-gd (GD module for php4 used by wordpress and other softwares), php-memcache etc.

Step # 5: Configure lighttpd to run from chrooted jail

Make sure fastcgi module is enabled:
# lighty-enable-mod fastcgiOutput:

Available modules: auth cgi cml fastcgi proxy simple-vhost ssi ssl trigger-b4-dl userdir
Already enabled modules:
Enabling fastcgi: ok
Run /etc/init.d/lighttpd force-reload to enable changes

Configure lighttpd by editing /etc/lighttpd/lighttpd.conf file:
# vi /etc/lighttpd/lighttpd.conf

The most importat part is server.chroot directive. Open config file:
# vi /etc/lighttpd/lighttpd.conf
Set server.chroot to /webroot:
server.chroot = "/webroot"

Above directive applies chroot() call to directory called /webroot. Once applied no one (except root user) can access file system outside /webroot directory.

Rest of the configuration directives is documented very well in file itself. Start your lighttpd:
# /etc/init.d/lighttpd start

Test jail setup

Create two test php files in /webroot/home/lighttpd

• db.php : Test MySQL database connectivity, make sure you modify this file for correct MySQL server hostname, username and password.
• test.php : Test php via phpinfo()

Open a web browser and type url http://yourdomain.com/test.php and http://yourdomain.com/db.php.

Congratulations, if you are able to run both db.php and test.php w/o problem. Always refer to /var/log/message (outside /webroot directory) for troubleshooting purpose. If you see error message that read as follows (tail -f /var/log/message) :

php5-cgi[7325]: segfault at 0000000000001e98 rip 00002ad2cf6bd101 rsp 00007fffdb3f1ed0 error 4

To fix this problem, copy all shared libs from /lib and /usr/lib to /chroot (or /lib64 & /usr/lib if you are using 64 bit Linux) directory. But please do NOT copy any executable files from /bin/ /usr/bin or /usr/sbin directory.
# cp -avr /lib/* /webroot/lib/
# cp -avr /usr/lib/* /webroot/usr/lib/
Follow these instructions for more information.

Size of the /webroot jail

Here is size of webroot jail:
# du -chOutput:

28K     ./var/www
104K    ./var/log/lighttpd
108K    ./var/log
4.0K    ./var/run
4.0K    ./var/tmp/lighttpd/cache/compress
8.0K    ./var/tmp/lighttpd/cache
12K     ./var/tmp/lighttpd
16K     ./var/tmp
160K    ./var
4.0K    ./tmp
5.9M    ./usr/bin
2.7M    ./usr/lib/i686/cmov
2.7M    ./usr/lib/i686
48K     ./usr/lib/php4/20050606
52K     ./usr/lib/php4
7.5M    ./usr/lib
14M     ./usr
1.7M    ./lib/tls
2.0M    ./lib
44K     ./etc/php4/cgi
48K     ./etc/php4
56K     ./etc
16K     ./home/lighttpd
20K     ./home
16M     .
16M total 

As you see our jail only took 16MB disk space. I will address rest of the issues such as perl support and sendmail problem tomorrow

Continue reading the rest of Lighttpd series articles.

Updated for accuracy.

Incoming search terms:

• centos chroot jail lighttpd 2012 (2)
• lighttpd php debian (2)
• Starting lighttpd: /bin/bash: /usr/sbin/lighttpd: No such file or directory in fedora (1)
• run php in jail windows (1)
• php chroot issues windows (1)
• mysql chrooted bash plesk (1)
• linux plesk php chroot (1)
• lighttpd php jail mysql (1)
• lighttpd chroot jail security (1)
• directadmin jail resolv conf (1)

Earlier, I used to type the command /root/fs.dsl.start via the sudo command. However, while reading the man page of interfaces command I came across the post-up option which run command after bringing the interface up. Following step demonstrates the usage of post-up option:

1) Copy your firewall shell script to /etc/network/if-up.d/ directory:
# cp /root/fw.dsl.start /etc/network/if-up.d/

2) Open Debian / Ubuntu networking configuration file /etc/network/interfaces:
# vi /etc/network/interfaces

3) Setup post-up option, append following line to eth0 configuration section:
# post-up /etc/network/if-up.d/fw.dsl.start

Where,

• post-up command : Run command or shell script after bringing the interface eth0 up.

Here is my /etc/network/interfaces after modification:

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
name Ethernet LAN card
address 192.168.1.1
netmask 255.255.255.0
broadcast 192.168.1.255
network 192.168.1.0
gateway 192.168.1.254
post-up /etc/network/if-up.d/fw.dsl.start

4) Save and close the file. Restart networking service:
# /etc/init.d/networking restart

5) Verify that iptables rules are loaded:
# iptables -L -n -v

Additional Options

To run command before bringing the interface up, enter:
pre-up command
pre-up /scripts/networking.accounting_on
To run command before taking the interface down, enter:
pre-down command
To run command or script after taking the interface down, enter:
post-down command
post-down /path/to/script.sh

Example: Setting Up Static Routing

The up and down options can be used to set up Debian static routing as follows as soon as eth0 interface available or down:
up route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.8.18.17
down route del -net 10.0.0.0 netmask 255.0.0.0 gw 10.8.18.17

Incoming search terms:

• centos execute a script when interface eth0 comes up (1)
• centos execute command on interface up (1)
• centos execute script when eth0 up (1)
• centos iptables firewall script (1)
• centos network post-up script (1)
• if-up d eth0 debian (1)
• rum command on network up centos (1)
• run script after eth0 interface comes up centos (1)

You create a script as follows and use it to stop or flush the iptables rules.

Please don’t type rules at command prompt. Use the script to speed up work.

Procedure for Debian / Ubuntu Linux

A) Create /root/fw.stop /etc/init.d/fw.stop script using text editor such as vi:

#!/bin/sh
echo "Stopping firewall and allowing everyone..."
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

(B) Make sure you can execute the script:
# chmod +x /root/fw.stop

(C) You can run the script:
# /root/fw.stop

A note for RedHat and friends Linux user

Please note that RedHat enterprise Linux (RHEL) and Fedora / Centos Linux comes with pre-installed script, which can be used to stop the firewall:
#/etc/init.d/iptables stop

Incoming search terms:

• /etc/init d/iptables stop no such file or directory centos (1)
• script ipchains plesk (1)
• plesk flush firewall (1)
• flush plesk iptables (1)
• flush plesk firewall (1)
• flush firewalll rules plesk (1)
• debian iptables directadmin (1)
• cpanel remove iptables rules (1)
• cpanel iptables rules delete (1)
• cpanel init network iptables (1)