DO THE BELOW AT YOUR OWN RISK. It worked fine for me on a CentOS 5 server and should be fine on any RH type system but if you mess up you may break ssh. Note that RH does keep up with security patches so this is not necessary but sometimes it is required.

cd /usr/local/src
wget http://www.openssl.org/source/openssl-0.9.8j.tar.gz
tar -zxf openssl-0.9.8j.tar.gz
cd openssl-0.9.8j
./config
make

cd /usr/local/src/
wget ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-5.2p1.tar.gz

tar -zxf openssh-5.2p1.tar.gz
cd openssh-5.2p1
./configure --prefix=/usr --sysconfdir=/etc/ssh --with-ssl-dir=/usr/local/src/openssl-0.9.8j --with-pam --with-libs=-ldl --without-zlib-version-check
make

make install

This is a very simple guide meant for people unfamiliar with upgrading kernels on a linux system. It is fairly simple to follow and I have done this on many servers so if you take your time and read though it you should have no problem. I take no responsibility if something goes wrong on your server because of this! This guide is formated for a RHEL server but if you understand the concept it can be applied to any rpm kernel.

Updated August with new versions


The kernel versions are constantly changing so this guide may fall out of date from time to time. The important thing to remember is when you are doing the up2date --download simply look at the version that is downloaded. That is going to be the latest version and in turn the version you want to install and boot to. RHEL or CentOS 5 follow the same basic method.

For who have recently notice that now DNSreport do verify if your DNS is recursive lookup or not, here is the tip on how to set it up.

open you named.conf and add before options { the follow lines:

acl "trusted" {
xxx.xxx.xxx.xxx;
yyy.yyy.yyy.yyy;
};

where xxx.xxx.xxx.xxx is your ip address same for yyy.yyy.yyy.yyy.
for cpanel users, you can find yours ips in the follow file: /etc/nameserverips

after that, inside the options add after the line "// query-source address * port 53;" the follow:
allow-recursion { trusted; };
allow-notify { trusted; };
allow-transfer { trusted; };

also uncomment the line "// query-source address * port 53;" "to query-source address * port 53;" with out the " (double-quotes).

restart your service.

Verify again your status with DNSreport.

Observation: you can also set up a version line it should be like:
version "Oh come on why do you want to know witch version my DNS server is ?";

this line can be add iside your named.conf

dear sirs,

is there any way , idea , function ... to put it into a .htaccess file .. to check a file content when somone request that file from the web ????

If somone hacked a web site and uploade a PHP shell ... of course he will request it via

the web like http://site.com/phpshell.php

here i want someting to check that phpshell contente ... if it find a shell script ..

it's prevent it displaying via the web .. if itsn't a shell script .. it's allow for its request and display the file content ..

waiting foe early replay ..

and I'm so sorry for my bad English

thanks & best regards ..

-Ahmed,

How-to: Determine is a server is hacked

This guide is not meant to be all inclusive for figuring out if a server is hacked however it should give you a pretty good idea if a server is hacked the method used. This guide is going to focus on getting hacked via a php injection attack which is the most common today. There are certainly others but chances are if the server has been compromised by a script kiddie you will be able to find it via this guide. As long as the server has not been rooted it is generally possible to clean up and find all of the tools and scripts that were put on the server. Once a server has been rooted it is impossible to determine without a doubt that you have cleared everything out and what can or cannot be trusted. Once a server has been rooted for sure the server should be reformated/reimaged before it is put back into production. If you are ever unsure of where to go next or woud like to hire somebody to take care of this please take a look TotalServerSolutions which is a company that I run and work for is very familiar with handling these types of problems and preventing them from happening. . Of course if you have had the server hacked once you need to make sure and secure it so that it does not get hacked as soon as it is put online again.

A recent problem with RHEL and cPanel causes some servers to crash on a daily or every couple of days basis. The normal symptoms of this sort of crashing are having the server crashing at the same time every time that it crashes. If you are having these problems I would suggest that you go ahead and just disable the auditd for now since the system can run fine without it and it seems to be causing a lot of trouble for some people. The below has worked fine for me on hundreds of servers and should not cause any issues.

No security system is perfect and it is always good to have some forms of intrusion detection just incase somebody does get in you can be notified. Do not immediatly get worried if in an email you get a positive, many of them are false and from upgrades. I would first suggest running "rkhunter -c" from ssh and looking at the errors. If it is a few bad binaries you should check to see what was updated recently. If you have a rootkit detected you should start to worry because it is very uncommon for a false positive on a rootkit or trojan.

A firewall is a very good idea for a server. Though many people think that a firewall is instant protection that will do everything it really is not. A firewall will help prevent some things but it is not going to stop everything. It is just one piece of the security network that is being woven. I recommend advanced protection firewall (APF) by rfxnetworks. APF will block unused outgoing and incoming ports. It can also be configured to use information from some block lists. The below port list will work for cPanel. For the other control panels you will need to add in the administration ports.

The purpose of syctl hardening is to help prevent spoofing and dos attacks. This short guide will show what I have found to be a good configuration for the sysctl.conf configuration file. The most important of the variables listed below is the enabling of syn cookie protection. Only place the bottom two if you do not want your server to respond to ICMP echo, commonly referred to as ICMP ping or just ping requests.


NOTICE: Make sure that eth0 is your primary interface, if it is not replace eth0 with eth1 in the code below.

-----command-----
pico -w /etc/sysctl.conf
-----command-----

Now paste the following into the file, you can overwrite the current information.

How-To: Secure your temp directories


Every system needs temporary folders that any user is able to read and write BUT these directories should not be able to execute programs or scripts. Though this will only protect you from somebody running the script directly it will help with a large portion of the automated rootkits and trojans that script kiddies use. They will still be able to put the files on the system but they will be unable to execute them and create the back door. One of the biggest problems is php injection via apache in which people will have apache download and then run an exploit. Securing the temp directories is probably the single biggest thing you can do towards securing your server.

Miscellaneous system tweaks

In this guide I am going to go over some basic system tweaks that will help the security of your server. None of are that big of a deal but every little bit helps secure your server more.

Updated Feb 18 to include enabling syncookies

This guide will not actually help in a physical sense to secure your server but it help prevent against many automated attacks that attack based on version number. If a cracker is starting to probe your system for holes it is common to check all the version numbers for your services. This guide will disable some of the common system daemons from reporting what version they are. This is called security by obscurity and you should not rely on it! It is just one of the many little things that you can do to help lower your systems chance of getting hacked.

One way to stop one of the more basic attacks on a server is mod_evasive.This how-to will walk though the process of installing and configuring mod_evasive. This apache module will help protect against people sending too many requests to the webserver in an attempt to flood it. If it detects too many connections the offending ip will be blocked from the accessing apache for This is especially useful when the server is continuously getting attacked. With this default configuration it will block the offending ip for 10 minutes. If it continues to try and flood mod_evasive will automatically add more time to this.

*Update* Feb 1 2005 - Now links to the latest version of mod_evasive from the old name of mod_dosevasive.