php4 and php5 in same cpanel machine

18 12 2008

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

HOW-TO

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):
Code:

/scripts/checkccompiler rm -rf /home/cpphpbuild mkdir /home/cpphpbuild cd /home/cpphpbuild wget http://layer1.cpanel.net/buildapache/1/php-5.0.5.tar.gz tar xfzv php-5.0.5.tar.gz cd php-5.0.5

Make sure that we do enabled Sendmail support:
Code:

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.
Code:

wget http://choon.net/opensource/php/php-5.0.5-mail-header.patch 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:
Code:

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):
Code:

./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:
/scripts/findphpversion

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

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:
Code:

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:
Code:

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:
Code:

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 index.jp, but before index.php4. Result would looks like this:
Code:

DirectoryIndex index.html index.wml index.cgi index.shtml index.jsp index.js index.jp 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:
Code:

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:
Code:

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:
Code:

service httpd stop service httpd startssl

Check that Apache come ok:
Code:

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:
Code:

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





mod_layout installation

18 12 2008

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

wget http://fresh.t-systems-sfr.com/unix/src/www/mod_layout-3.2.tar.gz

or

wget http://www.tangent.org/download/mod_layout-3.2.1.tar.gz

2. uncompress it

Code:

tar xvfz mod_layout-3.2.tar.gz

3.

Code:

cd tar xvfz mod_layout-3.2.tar.gz

and open the Makefile first

and find following

Code:

# the used tools
APXS=apxs
APACHECTL=apachectl
CC=`apxs -q CC`
INC=-I`apxs -q INCLUDEDIR` `$(APXS) -q CFLAGS` #-DLAYOUT_FILEOWNER_NAME
LD_SHLIB=`apxs -q LDFLAGS_SHLIB`

Replace the values with the following details :

Code:

# the used tools
APXS=/usr/local/apache/bin/apxs
APACHECTL=apachectl
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

Code:

make

make install





preventing nobody spammer in PHP

18 12 2008

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 =)

Requirements:
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.

Time:
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:

#!/usr/local/bin/perl

# 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);
if($REMOTE_ADDR) {
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

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

ADD BELOW:

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

Notes:
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 =)





compile kernel with module-init-tools

16 12 2008

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 http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.7.tar.bz2
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 System.map /boot/System.map-2.6.7
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.
[Grub]

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
[lilo]

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

image=/boot/vmlinuz-2.6.7
label=2.6.7
append=”root=LABEL=/”
read-only
initrd=/boot/initrd-2.6.7.img

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 http://www.kernel.org/pub/linux/kernel/people/rusty/modules/module-init-tools-3.0.tar.gz
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.





Define server Load in linux servers

16 12 2008

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 2.7.2.3) #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    12-35-86-1.ea.co  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

PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
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.





secure PHP in the server

14 12 2008

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. PHP.net 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.
See http://us2.php.net/register_globals

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.





How to clean a hacked server ?

14 12 2008

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

chkrootkit

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: libncurses.so.4: 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/lidps1.so (for pstree hiding)
/usr/include/hosts.h (for netstat and net-hiding)
/usr/include/log.h (for log hiding)
/lib/lblip.tk/ (backdoored ssh configuration files are in this directory)
/dev/sdr0 (systems md5 checksum)
/lib/ldd.so {placing tks(sniffer), tkp(parser) and tksb(log cleaner)}

Infected Binaries:

top, ps, pstree lsof, md5sum, dir, login, encrypt,ifconfig,find,ls,slocate,
tks,tksb,top,tkpnetstat,pg,syslogd,sz

Infected Librairies:
libproc.a,libproc.so.2.0.6,libproc.so

BackDoor: (located at /lib/lblip.tk)

shdc
shhk.pub
shk
shrs

——————————————————–

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

procps*.rpm
psmisc*.rpm
findutils*.rpm
fileutils*.rpm
util-linux*.rpm
net-tools*.rpm
textutils*.rpm
sysklogd*.rpm

Step 3.
After the system is up

cd /lib
rm -rf lblip.tk

Step 4.
remove the configuration files given above.

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

procps*.rpm
psmisc*.rpm
findutils*.rpm
fileutils*.rpm
util-linux*.rpm
net-tools*.rpm
textutils*.rpm
sysklogd*.rpm

– 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
193.60

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…





BFD ( brute force detection )

14 12 2008

BFD is a modular shell script for parsing applicable logs and checking for authentication failures. There is not much complexity or detail to BFD yet and likewise it is very straight-forward in its installation, configuration and usage. The reason behind BFD is very simple; the fact there is little to no authentication and brute force auditing programs in the linux community that work in conjunction with a firewall or real-time facility to place bans. BFD is available at: http://www.rfxnetworks.com/bfd.php

This guide will show you how to install and configure BFD to protect your system from brute force hack attempts.

Requirements:
- You MUST have APF Firewall Installed before installing BFD – it works with APF and requires some APF files to operate.
- Root SSH access to your server

Updated: April 13, 2005

Lets begin!
Login to your server through SSH and su to the root user.

1. cd /root/downloads or another temporary folder where you store your files.

2. wget http://www.rfxnetworks.com/downloads/bfd-current.tar.gz

3. tar -xvzf bfd-current.tar.gz

4. cd bfd-0.7

5. Run the install file: ./install.sh
You will receive a message saying it has been installed

.: BFD installed
Install path:    /usr/local/bfd
Config path:     /usr/local/bfd/conf.bfd
Executable path: /usr/local/sbin/bfd

6. Lets edit the configuration file: pico /usr/local/bfd/conf.bfd

7. Enable brute force hack attempt alerts:
Find: ALERT_USR=”0″   CHANGE TO: ALERT_USR=”1″

Find: EMAIL_USR=”root” CHANGE TO: EMAIL_USR=”your@yourdomain.com”

Save the changes: Ctrl+X then Y

8. Prevent locking yourself out!
pico -w /usr/local/bfd/ignore.hosts and add your own trusted IPs
Eg: 192.168.1.1

Save the changes: Ctrl+X then Y

BFD uses APF’ cli insert feature
and as such will override any allow_hosts.rules entries users have in-place.
So be sure to add your trusted ip addresses to the ignore file to prevent
locking yourself out.

9. Run the program!
/usr/local/sbin/bfd -s

10. Customize your applicatoins brute force configuration
Check out the rules directory in your /usr/local/bfd

Here you’ll find all kinds of pre-made rules for popular services such as Apache, and ProFTPD w00t!
If you have any clue about shell scripting you can customize them or create new rules for enhanced brute force detection and prevent attacks.

Thanks to RFX Networks for creating another great script for the community, Brute Force Detection is excellent!





Ban an IP address in Linux

14 12 2008

Have a user that keeps hammering your FTP or trying to login over and over and over again that you just want to ban and never see again? We’ll show a quick and dirty method to ban an IP address from the server.

We commonly receive questions like:
“I would like to ban that ip address to prevent the access to the server.

how can i ban that Ip address from the server?”

Simple!

1) Login to the server as and su  – to root.

2) If you are running iptables, you can enter:

iptables -A INPUT -s <IP> -j DROP

3) If you have APF firewall installed

apf -d <ip>

4) When you reboot this IP ban will be removed, meaning the IP will no longer be banned anymore.
If you have APF you can get around this by opening the deny hosts file.

pico /etc/apf/deny_hosts.rules

Scroll to the bottom and paste in the IP address.
Ctrl+X then Y to save the changes and exit.

5) Restart APF
/etc/apf/apf -r





Apache log files

14 12 2008

Configure Web Logs in Apache

One of the many pieces of the Website puzzle is Web logs. Traffic analysis is central to most Websites, and the key to getting the most out of your traffic analysis revolves around how you configure your Web logs. Apache is one of the most — if not the most — powerful open source solutions for Website operations. You will find that Apache’s Web logging features are flexible for the single Website or for managing numerous domains requiring Web log analysis.

For the single site, Apache is pretty much configured for logging in the default install. The initial httpd.conf file (found in /etc/httpd/conf/httpd.conf in most cases) should have a section on logs that looks similar to this (Apache 2.0.x), with descriptive comments for each item. Your default logs folder will be found in /etc/httpd/logs . This location can be changed when dealing with multiple Websites, as we’ll see later. For now, let’s review this section of log configuration.

ErrorLog logs/error_log

LogLevel warn

LogFormat “%h %l %u %t “%r” %>s %b “%{Referer}i” “%{User-Agent}i”" combined
LogFormat “%h %l %u %t “%r” %>s %b” common
LogFormat “%{Referer}i -> %U” referer
LogFormat “%{User-agent}i” agent

CustomLog logs/access_log combined
Error Logs

The error log contains messages sent from Apache for errors encountered during the course of operation. This log is very useful for troubleshooting Apache issues on the server side.

Apache Log Tip: If you are monitoring errors or testing your server, you can use the command line to interactively watch log entries. Open a shell session and type “tail –f /path/to/error_log” . This will show you the last few entries in the file and also continue to show new entries as they occur.

There are no real customization options available, other than telling Apache where to establish the file, and what level of error logging you seek to capture. First, let’s look at the error log configuration code from httpd.conf.

ErrorLog logs/error_log

You may wish to store all error-related information in one error log. If so, the above is fine, even for multiple domains. However, you can specify an error log file for each individual domain you have. This is done in the <VirtualHost> container with an entry like this:

<VirtualHost 10.0.0.2>
DocumentRoot “/home/sites/domain1/html/”
ServerName domain1.com
ErrorLog /home/sites/domain1/logs/error.log
</VirtualHost>

If you are responsible for reviewing error log files as a server administrator, it is recommended that you maintain a single error log. If you’re hosting for clients, and they are responsible for monitoring the error logs, it’s more convenient to specify individual error logs they can access at their own convenience.

The setting that controls the level of error logging to capture follows below.

LogLevel warn

Apache’s definitions for their error log levels are as follows:

Level                                             Descr
===================================
Emerg        Emergencies – system is unstable
alert        Action must be taken immediately
Crit        Critical conditions
Error        Error conditions
Warn        Warn conditions
Notice        Normal but significant condition
Info        Informational
Debug        Debug level messages

Tracking Website Activity

Often by default, Apache will generate three activity logs: access, agent and referrer. These track the accesses to your Website, the browsers being used to access the site and referring urls that your site visitors have arrived from.

It is commonplace now to utilize Apache’s “combined” log format, which compiles all three of these logs into one logfile. This is very convenient when using traffic analysis software as a majority of these third-party programs are easiest to configure and schedule when only dealing with one log file per domain.

Let’s break down the code in the combined log format and see what it all means.

LogFormat “%h %l %u %t “%r” %>s %b “%{Referer}i” “%{User-Agent}i”" combined

LogFormat starts the line and simply tells Apache you are defining a log file type (or nickname), in this case, combined. Now let’s look at the cryptic symbols that make up this log file definition.

Apache Logs 2 – Click for larger image

To review all of the available configuration codes for generating a custom log, see Apache’s [1] docs on the module_log_config , which powers log files in Apache.

Apache Log Tip: You could capture more from the HTTP header if you so desired. A full listing and definition of data in the header is found at the World Wide Web Consortium [2] .

For a single Website, the default entry would suffice:

CustomLog logs/access_log combined

However, for logging multiple sites, you have a few options. The most common is to identify individual log files for each domain. This is seen in the example below, again using the log directive within the <VirtualHost> container for each domain.

<VirtualHost 10.0.0.2>
DocumentRoot “/home/sites/domain1/html/”
ServerName domain1.com
ErrorLog /home/sites/domain1/logs/error.log
CustomLog /home/sites/domain1/logs/web.log
</VirtualHost>

<VirtualHost 10.0.0.3>
DocumentRoot “/home/sites/domain2/html/”
ServerName domain2.com
ErrorLog /home/sites/domain2/logs/error.log
CustomLog /home/sites/domain2/logs/web.log
</VirtualHost>

<VirtualHost 10.0.0.4>
DocumentRoot “/home/sites/domain3/html/”
ServerName domain3.com
ErrorLog /home/sites/domain3/logs/error.log
CustomLog /home/sites/domain3/logs/web.log
</VirtualHost>

In the above example, we have three domains with three unique Web logs (using the combined format we defined earlier). A traffic analysis package could then be scheduled to process these logs and generate reports for each domain independently.

This method works well for most hosts. However, there may be situations where this could become unmanageable. Apache recommends a special single log file for large virtual host environments and provides a tool for generating individual logs per individual domain.

We will call this log type the cvh format, standing for “common virtual host.” Simply by adding a %v (which stands for virtual host) to the beginning of the combined log format defined earlier and giving it a new nickname of cvh, we can compile all domains into one log file, then automatically split them into individual log files for processing by a traffic analysis package.

LogFormat “%v %h %l %u %t “%r” %>s %b “%{Referer}i” “%{User-Agent}i”" cvh

In this case, we do not make any CustomLog entries in the <VirtualHost> containers and simply have one log file generated by Apache. A program created by Apache called split_logfile is included in the src/support directory of your Apache sources. If you did not compile from source or do not have the sources, you can get the Perl script [3] .

The individual log files created from your master log file will be named for each domain (virtual host) and look like: virtualhost.log.
Log Rotation

Finally, we want to address log rotation. High traffic sites will generate very large log files, which will quickly swallow up valuable disk space on your server. You can use log rotation to manage this process.

There are many ways to handle log rotation, and various third-party tools are available as well. However, we’re focusing on configurations native to Apache, so we will look at a simple log rotation scheme here. I’ll include links to more flexible and sophisticated log rotation options in a moment.

This example uses a rudimentary shell script to move the current Web log to an archive log, compresses the old file and keeps an archive for as long as 12 months, then restarts Apache with a pause to allow the log files to be switched out.

mv web11.tgz web12.tgz
mv web10.tgz web11.tgz
mv web9.tgz  web10.tgz
mv web8.tgz  web9.tgz
mv web7.tgz  web8.tgz
mv web6.tgz  web7.tgz
mv web5.tgz  web6.tgz
mv web5.tgz  web6.tgz
mv web4.tgz  web5.tgz
mv web3.tgz  web4.tgz
mv web2.tgz  web3.tgz
mv web1.tgz  web2.tgz
mv web.tgz   web1.tgz
mv web.log   web.old
/usr/sbin/apachectl graceful
sleep 300
tar cvfz web.tgz web.old

This code can be copied into a file called logrotate.sh , and placed inside the folder where your web.log file is stored (or whatever you name your log file, e.g. access_log, etc.). Just be sure to modify for your log file names and also chmod (change permissions on the file) to 755 so it becomes an executable.

This works fine for a single busy site. If you have more complex requirements for log rotation, be sure to see some of the following sites. In addition, many Linux distributions now come with a log rotation included. For example, Red Hat 9 comes with logrotate.d , a log rotation daemon which is highly configurable. To find out more, on your Linux system with logrotate.d installed, type man logrotate .