Monthly Archives: December 2008

php5 works the same as php4 and it saves the permissions and etc. E.g. no problems with nobody as well.


1. Make sure you has Apache installed and workind with php4. It doesn’t matter if you run mod_php4 or php4/phpsuexec, but I recommend to have phpsuexec based install (Warning: if you are running mod_php4 and would like to switch to phpsuexec, read the threads in this forum or you may end up with numerous broken scripts!);

2. You would need to compile php 5. To do this use the SSH sessing logged as root.
Then execute preparation commands (based on cPanel for better compatibility):

/scripts/checkccompiler rm -rf /home/cpphpbuild mkdir /home/cpphpbuild cd /home/cpphpbuild wget tar xfzv php-5.0.5.tar.gz cd php-5.0.5

Make sure that we do enabled Sendmail support:

echo “#define HAVE_SENDMAIL 1” >> /home/cpphpbuild/php-5.0.5/main/php_config.h

It is recommended to apply the mail-header patch which allows to track the script which sent an email. You may skip this step.

wget patch -p1 < /home/cpphpbuild/php-5.0.5/php-5.0.5-mail-header.patch

Then one of the most important steps. It is the configuring of the php. It would be better if you undestand these options. You may use the configure from your existing php. To get them type the following:

php -i | grep configure | sed “s/’//g” | sed “s/’//g”

As you may see there are two same sed, however they are diferent! The second single quote should looks like & # 0 3 9 ; (without spaces!!) and this is for some cases when single quote sign shown as the code.
You will get the almost clean configure you are currently using. The several important hints on this.
a) REMOVE the “–with-apxs=/usr/local/apache/bin/apxs” from the line. We are going to compile CGI version and it WILL broke the Apache!

b) Make sure you have the following prefixes and suffixes to install to the proper directories – otherwise currently installed php could be broken:
–prefix=/usr/local/php5 –exec-prefix=/usr/local/php5 –program-suffix=5

c) Add the necessary options for proper CGI redirects from Apache:
–enable-force-cgi-redirect –enable-discard-path

The result line will looks like this (please, do not use it – it has no CURL and PostgreSQL support – you better to follow steps above):

./configure –prefix=/usr/local/php5 –exec-prefix=/usr/local/php5 –program-suffix=5 –with-xml –enable-bcmath –enable-calendar –enable-ftp –with-gd –enable-exif –with-jpeg-dir=/usr –with-png-dir=/usr –with-xpm-dir=/usr/X11R6 –with-imap –with-imap-ssl –with-kerberos –enable-mbstring –with-mbstring=all –enable-mbstr-enc-trans –with-mcrypt –with-mhash –enable-magic-quotes –with-mysql=/usr –with-openssl –enable-discard-path –with-pear –enable-sockets –enable-track-vars –with-ttf –with-freetype-dir=/usr –enable-versioning –with-zlib –with-pspell –with-gettext –enable-inline-optimization –disable-debug –enable-force-cgi-redirect –enable-discard-path

So, we are ready to start the compiling. Execute “make install” and it starts…
If the process fails for any reason, carefully read the errors – usually they are self-explaining. In MOST cases errors are because of the inproper configure params.

Then run the cPanel script to complete:

The compiled version of php should be copied to the cPanel cgi-sys:

cp -f /usr/local/php5/bin/php5 /usr/local/cpanel/cgi-sys/php5 chown root:wheel /usr/local/cpanel/cgi-sys/php5

Our installation has no php.ini file yet. On MOST systems Zend Optimizer installed. In this case you may just create the symlink:

ln -s /usr/local/Zend/etc/php.ini /usr/local/php5/lib/php.ini

Otherwise copy the default php.ini and edit it if needed:

cp -p /home/cpphpbuild/php-5.0.5/php.ini-recommended /usr/local/php5/lib/php.ini chown root.root /usr/local/php5/lib/php.ini chmod 644 /usr/local/php5/lib/php.ini

It is recommended to add the following line to the php.ini at the bottom (it is a MUST if you compile php4 instead php5!). Note that this line will broke regular php4. As a common rule – if you are using the same php.ini, do not add this line:

cgi.fix_pathinfo = 1 ; needed for CGI/FastCGI mode

Now we need to add several lines to Apache.

Run editor (you may use “vi” or “pico -w”):
pico -w /usr/local/apache/conf/httpd.conf

Scroll down (better use the built-in search) to the “”
There we should to add index.php5 after, but before index.php4. Result would looks like this:

DirectoryIndex index.html index.wml index.cgi index.shtml index.jsp index.js index.php5 iindex.php4 index.php3 index.php index.phtml ndex.htm default.htm default.html home.htm

This to allow index.php5 as index file.

Continue editing. Find the “AddType application/x-httpd-php .phtml” and after it add this:

Action application/x-httpd-php5 “/cgi-sys/php5” AddHandler application/x-httpd-php5 .php5

This is the directives for Apache to use own php5 for files with extensions .php5

Check if we could find this line “ScriptAlias /cgi-sys/ /usr/local/cpanel/cgi-sys/”
If not – add it or our directive will not work. By default cPanel add this line. Just to warn you.

Save the file and quit.

Verify that you not broke the Apache config by running:

service httpd configtest

You SHOULD to get “Syntax OK” at the end and possible some minor warnings about “NameVirtualHost directive” – it is OK.
Warning: if you get ERROR – DO NOT RESTART APACHE AND LOCATE THE ISSUE. Otherwise Apache will not start at all!

When you make sure it is OK restart the Apache:

service httpd stop service httpd startssl

Check that Apache come ok:

lynx –dump http://localhost/whm-server-status;

It will show you the Apache status.

Well, I should congratulate you – you have done it!

To test php5 upload the simple php file with the following content to any of your sites and name this file phpinfo.php AND ANOTHER COPY phpinfo.php5:

Then launch browser and point to phpinfo.php file first to see that php4 still OK


mod_layout is an Apache module that provides both a Footer and Header directive to automagically include output from other URIs at the beginning and ending of a Web page. It can be used to wrap documents for a standard look and feel for a site (or to insert banners on any given document in a site). Currently known to support mod_perl, PHP and Apache JServ. Should support just about any type of handler.

How to Install

1. download it first of all




2. uncompress it


tar xvfz mod_layout-3.2.tar.gz



cd tar xvfz mod_layout-3.2.tar.gz

and open the Makefile first

and find following


# the used tools
CC=`apxs -q CC`

Replace the values with the following details :


# the used tools
CC=`/usr/local/apache/bin/apxs -q CC`
INC=-I`/usr/local/apache/bin/apxs -q INCLUDEDIR` `$(APXS) -q CFLAGS` #-DLAYOUT_FILEOWNER_NAME
LD_SHLIB=`/usr/local/apache/bin/apxs -q LDFLAGS_SHLIB`

save the file Makefile

and then



make install

PHP and Apache has a history of not being able to track which users are sending out mail through the PHP mail function from the nobody user causing leaks in formmail scripts and malicious users to spam from your server without you knowing who or where.

Watching your exim_mainlog doesn’t exactly help, you see th email going out but you can’t track from which user or script is sending it. This is a quick and dirty way to get around the nobody spam problem on your Linux server.

If you check out your PHP.ini file you’ll notice that your mail program is set to: /usr/sbin/sendmail and 99.99% of PHP scripts will just use the built in mail(); function for PHP – so everything will go through /usr/sbin/sendmail =)

We assume you’re using Apache 1.3x, PHP 4.3x and Exim. This may work on other systems but we’re only tested it on a Cpanel/WHM Red Hat Enterprise system.

10 Minutes, Root access required.

Step 1)
Login to your server and su – to root.

Step 2)
Turn off exim while we do this so it doesn’t freak out.
/etc/init.d/exim stop

Step 3)
Backup your original /usr/sbin/sendmail file. On systems using Exim MTA, the sendmail file is just basically a pointer to Exim itself.
mv /usr/sbin/sendmail /usr/sbin/sendmail.hidden

Step 4)
Create the spam monitoring script for the new sendmail.
pico /usr/sbin/sendmail

Paste in the following:


# use strict;
use Env;
my $date = `date`;
chomp $date;
open (INFO, “>>/var/log/spam_log”) || die “Failed to open file ::$!”;
my $uid = $>;
my @info = getpwuid($uid);
print INFO “$date – $REMOTE_ADDR ran $SCRIPT_NAME at $SERVER_NAME n”;
else {

print INFO “$date – $PWD – @infon”;

my $mailprog = ‘/usr/sbin/sendmail.hidden’;
foreach (@ARGV) {
$arg=”$arg” . ” $_”;

open (MAIL,”|$mailprog $arg”) || die “cannot open $mailprog: $!n”;
while ( ) {
print MAIL;
close (INFO);
close (MAIL);

Step 5)
Change the new sendmail permissions
chmod +x /usr/sbin/sendmail

Step 6)
Create a new log file to keep a history of all mail going out of the server using web scripts
touch /var/log/spam_log

chmod 0777 /var/log/spam_log

Step 7)
Start Exim up again.
/etc/init.d/exim start

Step 8)
Monitor your spam_log file for spam, try using any formmail or script that uses a mail function – a message board, a contact script.
tail – f /var/log/spam_log

Sample Log Output

Mon Apr 11 07:12:21 EDT 2005 – /home/username/public_html/directory/subdirectory – nobody x 99 99 Nobody / /sbin/nologin

Log Rotation Details
Your spam_log file isn’t set to be rotated so it might get to be very large quickly. Keep an eye on it and consider adding it to your logrotation.

pico /etc/logrotate.conf

# no packages own wtmp — we’ll rotate them here
/var/log/wtmp {
create 0664 root utmp
rotate 1


# SPAM LOG rotation
/var/log/spam_log {
create 0777 root root
rotate 1

You may also want to chattr + i /usr/sbin/sendmail so it doesn’t get overwritten.

Enjoy knowing you can see nobody is actually somebody =)

Compiling the kernel
Wanted to try out the 2.6 edition kernel? Never knew how to do it? Well heres how! Includes everything from compiling the kernel to configuring your bootloader.

Lets Begin!

cd /usr/src
wget -c
tar xvfj linux-2.6.7.tar.bz2
cd linux-2.6.7
make clean && make mrproper
make oldconfig  ( or make menuconfig )
make bzImage
make modules
make modules_install

( i prefer this method rather then just “make” )

If you get alot of errors about .ko modules when you run make modules_install you need to update your modutils package with module-init-tools, see below.

Now to copy the files over for the kernel itself.

cp .config /boot/config-2.6.7
cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.7
cp /boot/
mkinitrd /boot/initrd-2.6.7.img 2.6.7

You may experience an error such as this:

/dev/mapper/control: open failed: No such file or directory

if you receive that error run the following commands:

rm -rf /boot/initrd-2.6.7.img
mkinitrd –omit-lvm-modules /boot/initrd-2.6.7.img 2.6.7

Now to add it to the grub / lilo configuration.

Your config will look something like this. Please note you need to follow the format for your current config.

title Red Hat Linux (2.6.7)
root (hd0,0)
kernel /vmlinuz-2.6.7 ro root=LABEL=/
initrd /initrd-2.6.7.img

Add your new entry to the top of the kernel list. Set the default to your working kernel. NOTE: the first kernel in the list is “0”. (ex. default=1)

Now exit. Type “grub” at the bash prompt.

savedefault –default=0 –once

issue that at the grub prompt then use quit to exit. Once your reboot you need to go back in and set the default to the 2.6 kernel by setting default=0

Your config will look something like this. Please note you need to follow the format for your current config.


Leave the default as is.

/sbin/lilo -v -v
/sbin/lilo -R 2.6.7

Once it reboots and comes back online you can change the default to be 2.6.7 and /sbin/lilo -v -v

The above tells you how to enable failsafe in your kernels. SO that if the box panics the dc tech does not have to console in he just has to reboot the box.
How to install module-init-tools:

cd /usr/src
wget -c
tar -zxvf module-init-tools-3.0.tar.gz
cd module-init-tools-3.0
./configure –prefix=””
make moveold
make install
./generate-modprobe.conf /etc/modprobe.conf
How to determine what boot loader you are using?

dd if=/dev/hda bs=512 count=1 2>&1 | grep GRUB
dd if=/dev/hda bs=512 count=1 2>&1 | grep LILO

one of them will kick back something like:

root@w00t [~]# dd if=/dev/hda bs=512 count=1 2>&1 | grep GRUB
Binary file (standard input) matches
root@w00t [~]#

which means its using grub.

The load average tries to measure the number of active processes at any time. As a measure of CPU utilization, the load average is simplistic, poorly defined, but far from useless. High load averages usually mean that the system is being used heavily and the response time is correspondingly slow. What’s high? … Ideally, you’d like a load average under, say, 3, … Ultimately, ‘high’ means high enough so that you don’t need uptime to tell you that the system is overloaded.

When seeing the results of the load averages, they are for the past 1, 5, and 15 minutes.

How to check the servers load?
There are a few different ways to keep an eye on your servers load, the first thing you need to do is login to your server by SSH.

Method 1 – using the uptime command:
The uptime shell command produces the following output:

[pax:~]% uptime
9:40am  up 9 days, 10:36,  4 users,  load average: 0.02, 0.01, 0.00

It shows the time since the system was last booted, the number of active user processes and something called the load average.

Method 2 – using the procinfo command:
On Linux systems, the procinfo command produces the following output:

[pax:~]% procinfo
Linux 2.0.36 (root@pax) (gcc #1 Wed Jul 25 21:40:16 EST 2001 [pax]

Memory:      Total        Used        Free      Shared     Buffers      Cached
Mem:         95564       90252        5312       31412       33104       26412
Swap:        68508           0       68508

Bootup: Sun Jul 21 15:21:15 2002    Load average: 0.15 0.03 0.01 2/58 8557

The load average appears in the lower left corner of this output.

Method 3 – using the w command:
The w command produces the following output:

[pax:~]% w
9:40am  up 9 days, 10:35,  4 users,  load average: 0.02, 0.01, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT
mir      ttyp0    :0.0             Fri10pm  3days  0.09s  0.09s  bash
neil     ttyp2  9:40am  0.00s  0.29s  0.15s  w

Notice that the first line of the output is identical to the output of the uptime command.

Method 4 – using the top command – prefered:
The top command is a more recent addition to the UNIX command set that ranks processes according to the amount of CPU time they consume. It produces the following output:

4:09am  up 12:48,  1 user,  load average: 0.02, 0.27, 0.17
58 processes: 57 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  0.5% user,  0.9% system,  0.0% nice, 98.5% idle
Mem:   95564K av,  78704K used,  16860K free,  32836K shrd,  40132K buff
Swap:  68508K av,      0K used,  68508K free                 14508K cached

5909 neil      13   0   720  720   552 R       0  1.5  0.7   0:01 top
1 root       0   0   396  396   328 S       0  0.0  0.4   0:02 init
2 root       0   0     0    0     0 SW      0  0.0  0.0   0:00 kflushd
3 root     -12 -12     0    0     0 SW<     0  0.0  0.0   0:00 kswapd

We like to use the top command because it also shows server uptime, memory information and the list of processes that you can sort by CPU usage, etc.

Other system monitoring tools – SIM (System Integrity Monitor)
The folks at R-fx networks have developed this utility that has a variety of features such as;
– Ability to auto restart system with definable critical load level
– System load monitor with customizable warnings & actions
– Priority change configurable for services, at warning or critical load level

For more information on SIM please visit the R-fx networks SIM page

What is a good load, bad load and in between?
I know you’re asking, “so what is a good system load or what is a bad load?” Anything around 1.0 and below is fine, try to stick to under 1.0 for regular load averages. If you notice your server slowing down, check the load first. We hosted a site that was mentioned on the media (TV, News, Radio) recently and the server skyrocketed because of the huge wave of traffic. The load went from 0.25 to 37.00 just because the server was getting hammered.

When your regular average starts to creep up around 2.0 then your server is very busy and you should consider getting another machine or upgrading your hardware. When I say regular average, I mean when the system is idle during the day and isn’t processing all your logs or backing up data.

Having an overloaded server can lead to many problems and should always be avoided. I hope this guide was helpful by giving you some more insight to server loads, what to use to monitor them and what is a good and bad load average.

Securing PHP

Well PHP is one of the most popular applications that run on Linux and Windows servers today. It’s also one of the main sources for servers and user accounts getting compromised. I want to go over some of the things you can do to help lock down PHP, securing php and securing php.ini

First off you want to figure out how you can edit php.ini This is the main configuration file for PHP. You can find it by logging into shell and typing in the following:

# php -i |grep php.ini

Turn on safe_mode

Safe mode is an easy way to lock down the security and functions you can use. explains php safe_mode as, “The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren’t very realistic, many people, especially ISP’s, use safe mode for now.”

I highly recommend you enable safe_mode on production servers, especially in shared environments. This will stop exec functions and others that can easily prevent a security breach.

See our article on Customizing PHP Safe Mode

Disable Dangerous PHP Functions

PHP has a lot of potential to mess up your server and hack user accounts and even get root. I’ve seen many times where users use an insecure PHP script as an entry point to a server to start unleashing dangerous commands and taking control.

Search the php.ini file for:
disable_functions =

Add the following:

disable_functions = dl,system,exec,passthru,shell_exec

Turn off Register Globals

Register_globals will inject your scripts with all sorts of variables, like request variables from HTML forms. This coupled with the fact that PHP doesn’t require variable initialization means writing insecure code is that much easier.

register_globals = On

Replace it with

register_globals = Off

Run PHP through PHPsuexec Preventing Nobody Access

The biggest problem with PHP is that on cPanel servers is that PHP will run as nobody. When someone sets a script to 777 access that means the nobody user has write access to that file. So if someone on the same shared server wrote a script to search the system for 777 files they could inject anything they wanted, compromising the unsuspecting users account.

PHPsuexec makes PHP run as the user so 777 permissions are not allowed. There are a few downfalls to PHPsuexec but I think it’s required on a shared environment for the security of everyone.  Safe_mode doesn’t prevent you from compromising other users files. This is where PHPsuexec comes in, it stops the user from being able to read another users files. It also makes it easier for you, the administrator, to track PHP mail function spamming and lots of other issues caused by PHP scripts because now you can easily track it ot the users account responsible.

For this you will need to recompile PHP with suexec. On cPanel /scripts/easyapach has this build in.

I hope this has summed up some of the things you can do to help secure PHP on your server. There’s also open_base protection which you can use to prevent users from reading other users files.

Detect and Clean a hacked server T0rnkit Tutorial

T0rn Rootkit

Tornkit is a rootkit, a set of programs that is used by an intruder to have unrestricted access to a compromised Linux system. Tornkit is also attempts to hide its presence.

The t0rn rootkit is designed for speed. By that I mean that it was designed to install quickly on Linux machines. T0rn can do this because it takes very little skill to install and run. All of the binaries that the attacker would need come pre-compiled and the installation process is as simple as ./t0rn. T0rn comes standard with a log cleaner called t0rnsb, a sniffer named t0rns and a log parser called t0rnp.

I am including this so that you all diag and clean up your hacked server.

First of all,
Login to WHM as root
Click Tweak Settings
and please remove the tick from
Allow cPanel users to reset their password via email

Step 1. run chkrootkit, and you will see some INFECTED lines. It will also report that some process are hidden from the ps


Checking `ifconfig’… INFECTED
Checking `login’… INFECTED
Checking `pstree’… INFECTED
and also:
Checking `lkm’… You have X process hidden for ps command
Warning: Possible LKM Trojan installed

Step 2.  /etc/init.d/syslog restart

Shutting down kernel logger: [ OK ]
Shutting down system logger: [ OK ]
Starting system logger: [FAILED]
Starting kernel logger: [ OK ]

Step 3. top

top: error while loading shared libraries: cannot open shared object file: No such file or directory

Step 4. tail /etc/rc.d/rc.sysinit

# Xntps (NTPv3 daemon) startup..
/usr/sbin/xntps -q


OK.. looks like someone got to your server as well. Since we know what rootkit it is, let us investigate further.

Configuration files
<please use cat /path/filename/ to read what the files contain>

/usr/include/file.h (for file hiding)
/usr/include/proc.h (for ps proc hiding)
/lib/ (for pstree hiding)
/usr/include/hosts.h (for netstat and net-hiding)
/usr/include/log.h (for log hiding)
/lib/ (backdoored ssh configuration files are in this directory)
/dev/sdr0 (systems md5 checksum)
/lib/ {placing tks(sniffer), tkp(parser) and tksb(log cleaner)}

Infected Binaries:

top, ps, pstree lsof, md5sum, dir, login, encrypt,ifconfig,find,ls,slocate,

Infected Librairies:

BackDoor: (located at /lib/



Now, Lets start the cleaning process:

Step 1.
pico /etc/rc.d/rc.sysinit

remove the lines that show

# Xntps (NTPv3 daemon) startup..
/usr/sbin/xntps -q

Step 2.
reboot the system

WARNING: 2 servers got their kernel removed after reboot.
If your’s is the case and that is what the DataCenter complains after reboot, please ask them to do the following:

reboot the system using the redhat CD into rescue mode
chroot to the /mnt/sysimage
reinstall kernel packages

that should fix it.

— since already in resuce mode, perhaps also ask them to –force install the following rpm’s


Step 3.
After the system is up

cd /lib
rm -rf

Step 4.
remove the configuration files given above.

Step 5.
cat /etc/redhat-release
note down your version of redhat, then from
search for the following rpm’s


— and rpm –force install them

Step 6.
if you see the hosts.h file, it says to hide all IP’s from

cat /usr/include/hosts.h

thus, if you want, you can block all the IP’s from 193.60 to your server via iptables.

Step 7.
If all goes OK,
please reboot the server, and run chkrootkit again…