ServerBuddies Support Blog

Suhosin Install Guide

Suhosin is an advanced protection system for PHP installations.

It was designed to protect servers and users from known and unknown flaws in PHP applications and the PHP core. Suhosin comes in two independent parts, that can be used separately or in combination.

The first part is a small patch against the PHP core, that implements a few low-level protections against bufferoverflows or format string vulnerabilities and the second part is a powerful PHP extension that implements all the other protections.

Installing the Extension

Source - http://download.suhosin.org/suhosin-0.9.29.tgz

The next step is unpacking the extension tarball and performing the usual compilation steps for PHP extensions.

This should install suhosin in the correct extension directory. The final step is adding a load directive to php.ini

Now copy suhosin.so to /usr/lib/php/extensions which php.ini points to.

Checking PHP

Find where your current PHP.ini is and then add the suhosin.so extension to php.ini

Check your /var/log/messages for logs of Suhosin

OSSEC Open Source Host-based Intrusion Detection System.

OSSEC is an Open Source Host-based Intrusion Detection System. It performs log analysis, integrity checking, Windows registry monitoring, rootkit detection, real-time alerting and active response. It runs on most operating systems, including Linux, OpenBSD, FreeBSD, MacOS, Solaris and Windows. A list with all supported platforms is available http://www.ossec.net/main/supported-systems

If you have one system to monitor, you can install the OSSEC HIDS locally on that box and do everything from there.

However, if you are administering a few systems, you can select one to be your OSSEC server and the others to be OSSEC agents, forwarding events to the server for analysis. One of the greatest benefits of the OSSEC HIDS is its scalability, allowing you to monitor multiple systems from a central point.

The best option is to select one of your machines to be the OSSEC server and perform the “server” installation on it. Then, choose the “agent” installation for the others.

Your IDS and rootkit rules will be just in one box, making it much easier to administer and configure.

Please make sure that you understand the type of installation you are choosing (manager, agent, local, etc) and are also aware of the order (always install the manager first).

Extract the compressed package and run the “./install.sh” script (It will guide you through the installation).

Remember to open the port 1514 (UDP) if there is a firewall between the server and the agents (if you didn’t choose the local installation).

Start the OSSEC HIDS.

Installing Root Check

RootCheck scans the system looking for possible trojans ,scans the ports for malicious activity ,and checks for rootkits,and also the logs,permissions and more.
Rootcheck is a very simple software. Just download, unpack, compile and execute it. It will scan the system and print if it found or not anything.

Installation Instructions

Login to your server and su to root.

This will take you to an interactive installtion. Make sure you have CPAN on
your box because rootcheck requires the Perl Modules IO::Interface.

If the installtion is finished you will get this message

Compilation sucessfull. Ready to go.
———————————————————
That’s it! If everything went ok, you should be ready to run RootCheck. If you any doubts about installation, please refer to INSTALL file.
You can also find additional information at :
http://www.ossec.net/rootcheck/
Improves, patches, comments are very welcome.
———————————————————
Scanning the System

Now you are ready to run rootcheck.
There are quite a few options butthe simplest one is

If the installation was perfect you would get a progress screen of the scan after which the results wiill be writen into results.txt the result is quite explanatory and gives details of all suspected files.

There is also an example file that explains the different options for root check

More Information about rootcheck is available at http://www.ossec.net/main/rootcheck

Force fsck on next boot on Red Hat Enterprise Linux

If you only want to run fsck on the next boot, execute the following as the root user:

The file “forcefsck” will be deleted automatically after fsck is finished.

This will only run the file system check on the next reboot. By touching the file “forcefsck” in the / directory, it will force the system to perform a full file system check.

You can force an automatic full check by changing the check interval using tune2fs (-c and/or -i). For example:

The below command would tell the init scripts to run fsck on hda2 at every boot.

*tune2fs - adjust tunable filesystem parameters on ext2/ext3 filesystems

Adjust the number of mounts after which the filesystem will be checked by e2fsck(8). If max-mount-counts is 0 or -1, the number of times the filesystem is mounted will be disregarded by e2fsck(8) and the kernel.

Set the number of times the filesystem has been mounted. If set to a greater value than the max-mount-counts parameter set by the -c option, e2fsck(8) will check the filesystem at the next reboot.

Adjust the maximal time between two filesystem checks. No post fix or d result in days, m in months, and w in weeks. A value of zero will disable the time-dependent checking.

It is strongly recommended that either -c (mount-count-dependent) or -i (time-dependent) checking be enabled to force periodic full e2fsck(8) checking of the filesystem.

Examples that show some features of TCP wrapper

If you just want to restrict ssh connections without configuring or using /etc/hosts.deny, you can add the following entries to /etc/hosts.allow:

The version of TCP wrapper that comes with Red Hat also supports the extended options documented in the hosts_options(5)man page. Here is an example how an additional program can be spawned in e.g. the /etc/hosts.allow file:

For information on the % expansions, see “man 5 hosts_access”.

The TCP wrapper is quite flexible.

And xinetd provides its own set of host-based and time-based access control functions. You can even tell xinetd to limit the rate of incoming connections.

The TCP wrapper is quite flexible. And xinetd provides its own set of host-based and time-based access control functions. You can even tell xinetd to limit the rate of incoming connections.