MySQL 5, PHP4 as CGI, with PHP5 as module on CentOS

Experts Only….(Since Apache and Mysql configuring steps not included)

Download PHp4source http://www.php.net/downloads.php :

cd /usr/local/src/
wget http://some.mirror.get/php-4.4.5.tar.gz

UNTAR
tar -zxf php-4.4.5.tar.gz

CONFIGURE & COMPILE PHP4

cd php-4.4.5

./configure –prefix=/usr/local/php4 –enable-force-cgi-redirect –enable-fastcgi –with-config-file-path=/usr/local/etc/php4/cgi –with-curl –with-curl-dir=/usr/local/lib –with-gd –with-gd-dir=/usr/local/lib –with-gettext –with-jpeg-dir=/usr/local/lib –with-kerberos –with-mcrypt –with-mhash –with-mysql=/usr –with-pear –with-png-dir=/usr/local/lib –with-xml –with-zlib –with-zlib-dir=/usr/include –with-zip –enable-bcmath –enable-calendar –enable-ftp –enable-magic-quotes –enable-sockets –enable-track-vars –enable-mbstring –enable-memory-limit

You will most likely get failures that tell you which libraries you need to install, eventually, it will work. I needed to install flex and zzlib. You can always choose to remove an option above from the compile command if you can’t or don’t want to install a dependency.

Once the complie command succeeds, run:

make

then

make install

Make the php4 cgi folder and copy the compiled PHP module to the proper location:

mkdir -p /usr/local/etc/php4/cgi
cp /usr/local/src/php-4.4.2/php.ini-dist /usr/local/etc/php4/cgi/php.ini

Make a php4.conf file:

The previous PHP5 installation created a the file /etc/httpd/conf.d/php.conf- duplicate this file and rename it php4.conf, then edit the “DirectoryIndex” “Action” and “AddHandler” lines with the following information:

DirectoryIndex index.php4 index.php3
Action php4-script /cgi-bin/php
AddHandler php4-script .php3 .php4

and comment out the “LoadModule php5…” line

Create link to PHP4 in Client’s cgi-bin Directory
# Due to Security Issues the PHP4 CGI is installed at /usr/local/etc/php4/cgi/php.ini. In the Interworx virtual host setup using suexec, each user has their own cgi-bin. Do the following to link the PHP4 CGI into your hosting client’s cgi-bin directory.

cd /chroot/home/client/public_html/cgi-bin (ie:virtual host document root or the alias path of your site)
ln /usr/local/php4/bin/php php
chown client php
chgrp client php
chmod 755 php

Test your PHP installation
try creating a php.info doc for both versions of PHP:

This  can be your virtualhost document root or the alias path of your site.

/chroot/home/client/public_html/info.php4
/chroot/home/client/public_html/info.php
using the same code:

<HTML>
<BODY>
<?php
phpinfo();
?>
</BODY>
</HTML>

The phpinfo() function reports the version number, as well as the features that are compiled into PHP. You’ll see that info.php4 uses php4 and info.php5 uses php5.

.htaccess Instructions:
Instruct your customers to create .htaccess files when they want to force php4 to be used on their site, or in just certain folders:

Customers just need to place that .htaccess file in the ../public_html folder or whatever folder they want php4 to be used instead of the default handler for the server, PHP5, which is stipulated in /etc/httpd/conf.d/php.conf.

Wherever you customer puts this .htaccess file, PHP4 will be used on that folder and any of that folder’s sub-folders.

The .htaccess file should read:

Options + FollowSymlinks
Action php-script /cgi-bin/php
AddHandler php-script .php

Sub-Domain Issues with PHP as a CGI:

Placing an .htaccess file like the one above in a sub-domain folder doesn’t work! Your choice’s are:

1. Place the .htaccess file above in the client’s root site folder (/html/.htaccess) do that PHP4 is used on the entire site
2. Don’t use sub-domains (use www.client_domain.com/subdomain) as long as the folder isn’t a subdomain placing the .htaccess file above will apply php4 to that folder and it’s sub-folders only.

Option 1 isn’t as bad as it sounds- because php5 is an apache module, you can enable it on any folder (subdoamin or regular subfolder) using the .htaccess code below.You just have to realize that any individual files in the site’s root level (like index.php ) are going to be stuck with PHP4.

Quick summary:
1. Place the .htaccess file above in the client’s /html folder- now their site uses php4 by default
2. Any folders you wish to override with PHP5 must have the following .htaccess file at the sub-domain/sub-folder’s root (/html/subdomain_folder/.htaccess) using this syntax:

Options +FollowSymlinks
AddHandler php5-script .php
AddType text/html .php

Advertisements
Published in: on January 30, 2010 at 2:58 pm  Comments Off on MySQL 5, PHP4 as CGI, with PHP5 as module on CentOS  

Checking for rootkits with rkhunter

Rootkits
A rootkit is software that is installed on your server with the purpose of hiding the fact that your server has been compromised and providing access to your server so that the intruder can easily return.  It is important to understand that in order for an intruder to install a rootkit they  will have to have gained the rights to do so on your server.  This means that the first line of defense is good security that prevents the installation of a rootkit.  If you are looking for a self-directed training package that contains documentation, Labs and movies check out the Self-Directed Ubuntu Training or Live Ubuntu Courses.

There are at least six basic categories of rootkits which  all serve the same purpose. That is, they prevent the intruder’s malicious software from showing screen output to the unsuspecting user, and they prevent the malicious software from leaving traces in the system logs.   They also prevent the malicious software from showing up in a “ps” or “top” process list.

Firmware rootkits
One of the most difficult rootkits to discover is the firmware rootkit that is placed in the code that exists in the ACPI or PCI cards or your system clock.  Firmware rootkits can be installed in any flashable code on your motherboard or any cards that you install.   The difficulties here will be that you cannot fix this by reinstalling your operating system or wiping your hard drives.

Virtualized rootkits change a computer’s boot-up sequence so that the rootkits get loaded instead of the operating system.  Once the rootkits are running in memory, the original operating system loads and then runs in a virtual machine as a guest operating system.  The rootkit can then intercept hardware calls from the original operating system in order to conceal the presence of any malicious software or activity.

Kernel rootkits
When Linux boots up, it loads kernel extensions, or modules.  Loadable Kernel Module, or LKM rootkits, can modify these modules to make them do the intruder’s bidding. These are also very difficult to detect.  They can subvert any attempt to detect them and can prevent removal.  On the other hand, they can be prevented.  On a known clean system, just recompile the Linux kernel without support for loadable kernel modules.

Boot Loader rootkits
In this rootkit the boot loader is replaced with a modified boot loader which is used to achieve the goals of the intruder.

Library rootkits
These rootkits work by modifying the operating system’s libraries that provide system calls.  They will either patch the library files, hook onto them, or outright replace them.

Application level rootkits
These are sometimes referred to as “traditional” rootkits.  That’s because they’re the oldest variety.   Application level rootkits replace system utility programs with their own trojaned versions.  On Linux, the affected system utilities include login, ls, du, netstat, ifconfig, ps and top.  When the unsuspecting user invokes one of these counterfeit utilities, it’ll will do what the user wants done, but in the background, it will also do something for the intruder.

One way to check these utilities is to invoke them with the -/ option switch.  If the command works with that switch, it’s an sign that its executable file is infected.

Rootkit Hunter
Rootkit Hunter performs a more comprehensive check than chkrootkit, and takes somewhat longer to run.  If your distro’s package repository doesn’t have it, you can download it from the author’s website.  The site is: http://rootkit.nl/projects or you can download it from sourceforge.net.

To perform a check of your system, enter:

rkhunter -c

Here is a typical summary which is listed at the end of the check.
System checks summary
=====================

File properties checks…
Files checked: 129
Suspect files: 0

Rootkit checks…
Rootkits checked : 115
Possible rootkits: 0

Applications checks…
Applications checked: 7
Suspect applications: 0

The system checks took: 2 minutes and 21 seconds

All results have been written to the logfile (/var/log/rkhunter.log)

One or more warnings have been found while checking the system.
Please check the log file (/var/log/rkhunter.log)

To update Rootkit Hunter, enter:

rkhunter –update

If you do a test and it discovers some programs have changed but you are sure that the changes occurred as the result of an upgrade you will want to upgrade those changes with rkhunter so that it does not continually report those as problems.  Note that rkhunter will only be able to tell you that changes have occurred not why they have changed, that is your responsibility to find out.

rkhunter –propupd

Run without User Input
In order to run rkhunter as a  cron job, or without user input,  you must make a few modifications.  Other wise, during the course of its scan, it will stop several times and ask the user to press “Enter”.  Use the command:

rkhunter –cronjob

Report only Problems
You can run rkhunter so that it will only report problems that it discovers.

rkunter –cronjob –rwo

Email Your Account
You will need to edit two lines to enter your email and check your mail command header setting.  This command will work for Sendmail but not Postfix.

MAIL-ON-WARNING=youremail@example.com   root@mydomain
MAIL_CMD=mail -s “[rkhunter] Warnings found for ${HOST_NAME}”

If you are using Postfix as the mail server you will want to modify the default line so it looks like this:
MAIL_CMD=/usr/sbin/sendmail

This is the message you will receive is there is a problem.

”Please inspect this machine, because it may be infected.”

False Positives
You may have to uncomment lines in the rkhunter.conf file to allow for some hidden directories.  You may also have to enter the lines and issues that are discovered for your system that are false positives.  Of course, you will want to verify either that rkhunter discovered these on a new system or that you are sure they do not represent intrusion.

LOGFILE=/var/log/rkhunter.log

If you allow the root user to login using SSH, change this line.
ALLOW_SSH_ROOT_USER=yes

You may need to allow some directories and files to stop the false positives.
#ALLOWHIDDENDIR=/etc/.java
ALLOWHIDDENDIR=/dev/.udev
#ALLOWHIDDENDIR=/dev/.udevdb
#ALLOWHIDDENDIR=/dev/.udev.tdb
ALLOWHIDDENDIR=/dev/.static
ALLOWHIDDENDIR=/dev/.initramfs
#ALLOWHIDDENDIR=/dev/.SRC-unix

ALLOWHIDDENFILE=/usr/share/man/man1/..1.gz
ALLOWHIDDENFILE=/usr/bin/.fipscheck.hmac
ALLOWHIDDENFILE=/usr/bin/.ssh.hmac
ALLOWHIDDENFILE=/usr/sbin/.sshd.hmac

SCRIPTWHITELIST=/sbin/ifup
SCRIPTWHITELIST=/sbin/ifdown
SCRIPTWHITELIST=/usr/bin/groups
SCRIPTWHITELIST=/usr/bin/ldd
SCRIPTWHITELIST=/usr/bin/whatis

Enter the applications you want to whitelist.  This is a possible list for a CentOS system apache on Ubuntu is called apache2 instead of httpd.

APP_WHITELIST=”httpd sshd PHP named”
Here is an example of the output that you need to fix in order to eliminate false positives.

rkhunter –cronjob –rwo
Warning: Hidden directory found: /dev/.udev
Warning: Hidden file found: /usr/share/man/man1/..1.gz: gzip compressed data, from Unix, max compression
Warning: Hidden file found: /usr/bin/.fipscheck.hmac: ASCII text
Warning: Hidden file found: /usr/bin/.ssh.hmac: ASCII text
Warning: Hidden file found: /usr/sbin/.sshd.hmac: ASCII text

One or more warnings have been found while checking the system.
Please check the log file (/var/log/rkhunter.log)

Published in: on January 27, 2010 at 8:05 am  Comments Off on Checking for rootkits with rkhunter  

Password protect a web directory with .htaccess

Apache references the .htaccess file in web document directories for access control information and other uses. A simple configuration allows password protection with multiple username/password combinations.

In the directory to be protected, create a .htaccess file with contents like this:

AuthType Basic

AuthUserFile /safe/dir/htpasswd

AuthName “Text displayed in popup”

require valid-user

There are many other options for .htaccess, but these are basic password related options to get started. The AuthUserFile refers to a fully qualified file that should not be in the web server document directories. The htpasswd file can be named anything, there can be multiple files storing passwords for .htaccess, and each can be shared for use in multiple directories.

To create the first and second user/password pairs, use:

htpasswd -cb /safe/dir/htpasswd user1 password1

htpasswd -b /safe/dir/htpasswd user2 PaSsWoRd2

Additional user/password pairs can be added using the second form. Be certain to protect the htpasswd file.

Published in: on January 23, 2010 at 2:15 pm  Comments Off on Password protect a web directory with .htaccess  

To find the hacked website (Gumblar/Martuz)..

To find the website is hacked by someone or badware scripts running on the server. You can find here…

http://unmaskparasites.com/

This site should be healthy report…. If the report shows badware running..

You need to clean the site on the server & restore the old backup..

Then send review to google web tools &b google will unblock from google blacklist.

Email me for further doubts..

Thanks

Published in: on January 23, 2010 at 2:09 pm  Comments Off on To find the hacked website (Gumblar/Martuz)..  

Installing Redmine & Redmine Migration Guide

Requirements

Operating system

Redmine should run on most Unix, Linux, Mac and Windows systems as long as ruby is available on this platform.

Ruby & Ruby on Rails

The required Ruby and Ruby on Rails versions for a given Redmine version is:

Redmine version Supported Ruby versions Required Rails version
current trunk ruby 1.8.6, 1.8.7 Rails 2.2.2
trunk before r2493 ruby 1.8.6, 1.8.7 Rails 2.1.2
0.8.x ruby 1.8.6, 1.8.7 Rails 2.1.2
0.7.x ruby 1.8.6 Rails 2.0.2

Official releases include the appropriate Rails version in their vendor directory. So no particular action is needed.

If you checkout the source from the Redmine repository, you can install a specific Rails version on your machine by running:

gem install rails -v=2.2.2

Notes:

  • RubyGems 1.3.1 is required
  • Rake 0.8.3 is required

Database

  • MySQL 4.1 or higher (recommended) [One exception- the ruby mysql gem does not currently support mysql 5.1]
    • make sure to install the C bindings for ruby that dramatically improve performance. You can get them by running gem install mysql.
  • PostgreSQL 8
    • make sure your database datestyle is set to ISO (Postgresql default setting). You can set it using: ALTER DATABASE "redmine_db" SET datestyle="ISO,MDY";
  • SQLite 3

Optional components

  • SCM binaries (eg. svn), for repository browsing (must be available in your PATH). See RedmineRepositories for SCM compatibility and requirements.
  • RMagick (to enable Gantt export to png image)

Installation

1. Download and extract the archive or checkout Redmine.

2. Create an empty database and accompanying user named redmine for example.

For MySQL:

create database redmine character set utf8;
create user 'redmine'@'localhost' identified by 'my_password';
grant all privileges on redmine.* to 'redmine'@'localhost';

3. Copy config/database.yml.example to config/database.yml and edit this file in order to configure your database settings for “production” environment.

Example for a MySQL database:

production:
  adapter: mysql
  database: redmine
  host: localhost
  username: redmine
  password: my_password

Example for a PostgreSQL database:

production:
  adapter: postgresql
  database: <your_database_name>
  host: <postgres_host>
  username: <postgres_user>
  password: <postgres_user_password>
  encoding: utf8
  schema_search_path: <database_schema> (default - public)

4. Generate a session store secret (r2493 and higher only. 0.8.x users can skip this step) ***

Redmine stores session data in cookies by default, which requires a secret to be generated. This can be done by running:

rake config/initializers/session_store.rb

5. Create the database structure, by running the following command under the application root directory:

rake db:migrate RAILS_ENV="production"

It will create tables and an administrator account.

6. Insert default configuration data in database, by running the following command:

rake redmine:load_default_data RAILS_ENV="production"

This step is optional but highly recommended, as you can define your own configuration from scratch. It will load default roles, trackers, statuses, workflows and enumerations.

7. Setting up permissions

NB: Windows users have to skip this section.

The user who runs Redmine must have write permission on the following subdirectories: fileslogtmp (create the last one if not present).

Assuming you run Redmine with a redmine user:

mkdir tmp public/plugin_assets
sudo chown -R redmine:redmine files log tmp public/plugin_assets
sudo chmod -R 755 files log tmp public/plugin_assets

8. Test the installation by running WEBrick web server:

ruby script/server webrick -e production

Once WEBrick has started, point your browser to http://localhost:3000/. You should now see the application welcome page.

9. Use default administrator account to log in:

  • login: admin
  • password: admin

You can go to Admin & Settings to modify application settings.

Source: http://www.redmine.org/wiki/redmine/RedmineInstall

Published in: on January 23, 2010 at 1:55 pm  Comments Off on Installing Redmine & Redmine Migration Guide