404 Not found error along with the original 404 error_document !

When trying to access a non-existent page / file in a domain,  do you get an additional 404 Not Found error which should actually be redirected to an ErrorDocument ?

For Eg, when I try to access a non-existent file within my account
I get the following :

Not Found :The requested URL /~joelta/noactualfile was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

How do I remove the above error log for the error document ?  ( the one in red font )

Use the following lines in the .htaccess file of the domain :


ErrorDocument 400 default
ErrorDocument 401 default
ErrorDocument 403 default
ErrorDocument 404 default
ErrorDocument 410 default
ErrorDocument 500 default


This should do the trick !


Hiding PHP extension in IIS using URL rewrite module

We have some situations in which we need to hide the extension of a webpage to the end users. Mostly this is concerned with the server security. Here we discuss about hiding the PHP extension of a wepage deployed in an IIS server .

We can easily implement this in Linux using codes passed via .htaccess file. In the case of Windows we will use URL-rewrite module to achieve the same. By default, this module is not installed alongside IIS, so we need to install it via Microsoft Web Platform Installer (WPI).

After the installation of URL-rewrite module, we need to edit the web.conf file in the root directory.

Say for example, we have a php website ‘www.abc.com’ and its root folder is C:/inetpub/wwwroot/www.abc.com. We need to hide the php extension of the page, www.abc.com/test.php. That is, we need to rewrite this url into www.abc.com/test. Lets now edit the web.conf file located at the root folder of the site (C:/inetpub/wwwroot/www.abc.com).

Attaching a sample web.conf file to make it clear :

<?xml version=”1.0″ encoding=”utf-8″ ?>





         <rule name=”test rule” enabled=”false” stopProcessing=”true”>

              <match url=”^gif” />

               <action type=”Rewrite” url=”{R:0}.aspx” />






In our case look for the <rewrite> option in the web.conf file. After finding <rewrite> tag, copy the below mentioned configuration and paste it under the <rewrite> tag.

<rule name=”PHP Hiding”>

     <match url=”(.*)” />

         <conditions logicalGrouping=”MatchAll”>

             <add input=”{REQUEST_FILENAME}” matchType=”IsFile” negate=”true” />

             <add input=”{REQUEST_FILENAME}” matchType=”IsDirectory” negate=”true” />


     <action type=”Rewrite” url=”{R:1}.php” />


After this, the webpage will always be displayed as www.abc.com/test instead of www.abc.com/test.php

The Ghost vulnerability – CVE-2015-0235

So there we have another vulnerability affecting the world of opensource. Nick-named as GHOST Vulnerability,  it affects the glibc library shipped along with the linux systems. It has been assigned CVE-2015-0235

As per redhat, GHOST is a ‘buffer overflow’ bug affecting the gethostbyname() and gethostbyname2() function calls in the glibc library.

If this vulnerability is exploited, it allows a remote attacker to make an application call to either of these functions to execute arbitrary code with the permissions of the user running the application. The   attacker can trigger a buffer overflow by supplying an invalid hostname argument to an application which uses gethostbyname() function.

You can check if your server is vulnerable executing the following checker in your server.

# vi ghost.sh

#Version 3
# Credit : Red Hat, Inc - https://access.redhat.com/labs/ghost/
echo "Installed glibc version(s)"

for glibc_nvr in $( rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' glibc ); do
glibc_ver=$( echo "$glibc_nvr" | awk -F- '{ print $2 }' )
glibc_maj=$( echo "$glibc_ver" | awk -F. '{ print $1 }')
glibc_min=$( echo "$glibc_ver" | awk -F. '{ print $2 }')

echo -n "- $glibc_nvr: "
if [ "$glibc_maj" -gt 2 -o \
\( "$glibc_maj" -eq 2 -a "$glibc_min" -ge 18 \) ]; then
# fixed upstream version
echo 'not vulnerable'
# all RHEL updates include CVE in rpm %changelog
if rpm -q --changelog "$glibc_nvr" | grep -q 'CVE-2015-0235'; then
echo "not vulnerable"
echo "vulnerable"

if [ $rv -ne 0 ]; then
cat <<EOF

This system is vulnerable to CVE-2015-0235.
exit $rv

# chmod +x ghost.sh

# ./ghost.sh

After running the above script, if the result is something like this :

Installed glibc version(s)
– glibc-2.5-123.el5_11.1.i686: not vulnerable
– glibc-2.5-123.el5_11.1.x86_64: not vulnerable

The server is free from GHOST vulnerablity, on the other hand, if the result is something like this :

Installed glibc version(s)
– glibc-2.5-118.el5_10.2.x86_64: vulnerable
– glibc-2.5-118.el5_10.2.i686: vulnerable

You will need to update glibc at the earliest ( most of the distro’s have pushed an update )

If you are on a CentOS/Redhat machine, run the following command

# yum update glibc*

Once the update is complete, reboot your server.


Finding an issue with Zend Optimizer ?

When you open your webpage, are you getting the message that “Zend Optimizer not installed“, when you are pretty sure that it is installed in your server ? You are also sure that nothing has changed in the server and you get this message all of a sudden.

This file was encoded by the Zend Encoder / Zend SafeGuard Suite. In order to run it, please install the freely available Zend Optimizer, version xx.xx or later."

You can verify it from the result of # php -v, if zend optimizer is installed, you will get a result something like this :

“with Zend Optimizer vxx.xx, Copyright (c) 1998-2009, by Zend Technologies”

Even with this result, if you are getting an error that shows optimizer is not installed, then there is an issue with your codes. You might look at the particular PHP file and might see enormous codes. More likely the domain is compromised.  You will need to clean up the site / restore the domain from a clean backup.


Handy tool to monitor file creation in your server !

When you have a live server, there might be situations in which you or your clients would need to have a list of files which have been created. This can be very helpful for example when you have a backdoor to your server and to track and close any vulnerabilities within the server. These days we are seeing lots of malicious scripts being uploaded due to vulnerabilities in plugins or themes used for the CMS’s in the server. Tracking those locations manually can be a tedious job.

Luckily, you have a command ‘inotifywait’ to track the changes to a file or the file creation itself. Install inotifywait along with inotify-tools using the following command in a RPM based server :

# yum install inotify-tools

Once the installation is complete, go ahead and create a script like :

# vi /etc/init.d/inotifywaitd



if [ $# != 1 ];then
echo "Usage: /etc/init.d/inotifywaitd {start|stop}"
exit 1

if [ ! -d ${DIR} ];then
mkdir ${DIR}
case $1 in


for i in `ls -d /home/*/public_html`
user=$(echo "${i}"|cut -d\/ -f3)
${INOTIFY_CMD} -m -r -e create --format '%f' ${i} > ${DIR}/${user}&


stop) pkill inotifywait ;;

*) echo "Usage: /etc/init.d/inotifywaitd {start|stop}" ;;


# chmod 755 /etc/init.d/inotifywaitd

/etc/init.d/inotifywaitd start

The above script will monitor if there are any newly created files coming under the document root of each of the users and if there is a newly created file, it will report it as a line in the file  /root/newfiles/$username. This can become a really handy tool when you are going through an inspection phase in your server 😉

Installing LAMP – Ubuntu 14.04 !

LAMP is a group of open source which is deployed usually to host websites. In LAMP ‘L’ stands for Linux, the OS which provides the platform, ‘A’ stands for Apache, the webserver, ‘M’ stands for MySQL, the database server and ‘P’ stands for PHP which processes the dynamic content.

First, let’s install Apache webserver.

Open your terminal and type the following to install Apache via apt :

sudo apt-get install apache2

Once the web-server is installed, you can verify that if its able to serve the webpages by simply opening your server IP in a browser :


You would be able to see the default Apache2 ubuntu page which looks like :

apache2 ubuntu

We can now install the MySQL server from the terminal.

# sudo apt-get install mysql-server php5-mysql

We will need to install the package ‘php5-mysql ‘ which provides modules for MySQL database connections directly from PHP scripts

During the installation, you will need to confirm a password for the MySQL “root” user. This is an administrative account in MySQL that has increased privileges.


Once the installation is complete, type the following to create the database directory structure :

sudo mysql_install_db

Once this is done, we will have to follow some steps to make the MySQL configuration a safe one :

sudo mysql_secure_installation

You will have to enter the MySQL root password and then move ahead with some straightforward questions. You can decide whether to remove the sample db’s, and stuffs like disabling remote root logins etc. This is all with the MySQL installation.

After MySQL, we will move ahead with installing PHP in the server :

sudo apt-get install php5 libapache2-mod-php5

You can also decide if you wish to install the PHP modules along with this, modules like – php5-gd etc. You either install it now, or at a later time. An example would be like :

# sudo apt-get install php5-gd

With this, the installation of LAMP stack is over. We can now move ahead and test if the webserver is able to parse the pages without any issues.

Create a test php page  inside /var/www/html :

# vi /var/www/html/phpinfo.php


// Show all information, defaults to INFO_ALL


Now try to open the phpinfo page from your browser,


The SSLv3 vulnerability – What do I need to do ? !

It looks like opensource is constantly being hit with vulnerabilities these days ! but yea, as a wise man once said, the more people use and learn on a stuff, the more loopholes you get to find and fix.

So the recent vulnerability is with the SSLv3 protocol which has been tagged as a secure protocol for establishing secure communication between the client and the server until now.

You can check if your services are bound to this vulnerability by checking using this online server tester at :


( you may need a redhat login to get through )

Or you can check using the following one-liner from a shell :

# openssl s_client -connect 'ServerIP or hostname':<'port'> -ssl3


# openssl s_client -connect xx.xx.xx.xx:443 -ssl3

The above command when initiated should result something like this if its not vulnerable :



xxxxxxxxxx :error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1256:SSL alert number 40

xxxxxxxxxxx :error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:


If your service bound on the port is vulnerable to SSLv3 vulnerability, you would see a SSL handshake being established.

You would need to individually disable SSL v3 for each of the services.

To disable SSLv3 for httpd follow the steps given below :

Open your SSL directive file, ( if configured ), ie, the file /etc/httpd/conf.d/ssl.conf or the top-level configuration file, or inside the default virtual host configuration for an address and specify the following :

SSLProtocol All -SSLv2 -SSLv3

The above SSLProtocol directive disables SSLv2 and SSLv3

If you use a WHM/cPanel server, this can be done from WHM as follows :

WHM » Service Configuration » Apache Configuration » Include Editor » Pre Main Include

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on

Save the above lines and restart the service.

For the moment, patches are still being released for each of the services.  As of now, consider patching your httpd service as the first step and then move on to other services once fixes are available.

Also, there a lot of suggestions in the forums to disable the SSL ciphers for SSLv3 in cPanel configuration so that all the services would get disabled in using SSLv3. However, if you are on centos 5, the base SSL version would be 0.98.e and there is no other ciphers included in it, ie, there are no TLS protocols along with it , which would mean if you change your cPanel to disable SSLv3, you wont be able to access anything over the browser.

You can change /var/cpanel/conf/cpsrvd/ssl_socket_args and give the following to disable SSLv3 :


As i said, if you are on openssl 0.9.8.e, giving the following would break everything and you would need to give back what was originally in the file /var/cpanel/conf/cpsrvd/ssl_socket_args, ie,


You can check your current openssl version and the available ciphers in your installation using the following commands :

# openssl version -a
# openssl ciphers -v

If you need to upgrade your Openssl to a latest version, check this post here.

So now, as a server admin you should disable SSLv3 ( first and foremost for your httpd service ) for the security of your users.

As a user, you should disable SSLv3 in your browser now to secure yourself when visiting websites which still  support SSLv3.

DDoS protection guide – Part 2

We have discussed about DDoS hitting Webservers in this post. It can also attack the DNS servers, which is often called as DNS Amplification Attacks.

In Simple words, the attack can be explained as follows :

Someone makes an inquiry to you, on how to reach a particular destination. You are not actually sure of the location either, so you ask your friends nearer to you, and if you don’t get an answer from them, you are determined to somehow get an answer and you start inquiring further until you get one. ( Basically you do not know this ‘someone’ who requested your help)

And this ‘someone’ has not stopped there. He has asked this same question to lots many other people whom like you are determined to get an answer. He would conclude by saying, if you get an answer, please ring me to 111 – a fake number of some unknown poor guy.

Similarly, an attacker spoofs IP addresses ( he might spoof it to an IP to which he would like to carry a DDoS attack – called as the target – like the fake 111 number ) and sends a request to your DNS server asking to resolve a domain. Your DNS server would not have any details about it in your local db’s. So it goes around the internet trying to resolve the domain and as a result the request-queries and the reply-queries increase beyond a limit as the attacker sends more and more request queries.

Now, remember your server might be 1 in 10000 out of which the attacker would direct the reply’s to a target. ( If source IP of the DNS query was spoofed to that of the target’s IP )

So basically, this sort of DDoS attacks, not only affects the ‘target’ but also all the DNS server’s participating in this attack, as they are flooded with queries ( request and reply )

Attackers will typically submit a request for as much zone information as possible to maximize the amplification effect. In most attacks of this type, the spoofed queries sent by the attacker are of the type, “ANY,” which returns all known information about a DNS zone in a single request. Because the size of the response is considerably larger than the request, the attacker is able to increase the amount of traffic being generated by these DNS services and in the end- the amount of traffic directed at the target would be huge.

So, how can we prevent this from happening ?

Going back to our previous illustration, when that ‘someone’ asked you for a help, its you who sought to find an answer. You could have said :

“Im sorry, I dont know the route to that destination. Neither do i know you, so i cant spend my time/energy in assisting you.

This is where you can make your DNS server a closed resolver.

More on this is found in this post

And suppose, consider this, your DNS server is closed, still it would receive the queries from the attacker and your server would have to reply to those DNS queries. Just that it is not a part of the attack. These replies too might hinder your services if too much requests are being directed to your server.

Here you can use iptables to set a rate-limit on the queries reaching your DNS port.

First make sure the recent module is loaded in the server
This module is needed to get this particular aspect of iptables working.

First rule is set to move all the packets received in port 53 to a new chain

# iptables -N blocklist ( create a new chain )
# iptables -A INPUT -p udp --dport 53 -j blocklist


# iptables -A blocklist -m recent --set --name DNSQF --rsource ( creating a db DNSQF to capture the packets )

# iptables -A blocklist -m recent --update --seconds 5 --hitcount 15 --name DNSQF --rsource -j DROP

( set the rule for the db DNSQF which stores recent IPs )

The above rule implies to drop every packets after the 15th one, in a time-frame of 5 seconds.

Availing these rules in iptables, can in way help to reduce the traffic in your server, when DNS queries are made to your server, even when it is a closed resolver.

cPanel – Blocking spam – in addition to SpamAssassin !

SpamAssassin is just a great tool to block the incoming spams to your server. However, you might just need some other tools in addition to SpamAssassin, if you feel lotta spams are making it past SA.

Two of my suggestions from WHM are :

1. Enable the RBL option from WHM , which will check each of the IPs that is attempting to send mails to your server and if the IP is in the RBL list , it will automatically block the mails.

This option can be found from WHM as follows :

Home »Service Configuration »Exim Configuration Manager>> RBLs>>Manage Custom RBLs

You can enable the in-build lists or add your RBL lists from above.

2. Enable the setting to Reject SPF failures , which will reject emails from domain names without valid SPF records.

You can enable this option from :

WHM » Service Configuration » Exim Configuration Manager>>ACL

These two tweaks are seen as very effective when it comes to reject unwanted spams from hitting your server !

Still getting incoming spam ? Then you might need to think of training SpamAssassin. You can check this post here on more info on that.


Error – /bin/rm: Argument list too long !

When trying to delete the files of a folder ( using # rm ) with lots of contents in it , you might get this error :

/bin/rm : Argument list too long

The traditional # rm command will not be able to delete too many files in a directory.

To get around this, use the command given below. Please note that the below command will delete all the files in the current directory in which you are logged into.

# find . -name '*' | xargs rm

( Again, make sure your pwd is the directory which you want to delete the files from, else, i have no words to describe it 😀 )