Apache Abuse: Source IP identification


Some times the webserver become loaded heavily due to large no. of inbound connections and makes the server sluggish or non-responsive. This is quite evident during DOS or DDOS attacks. You can use the following script to identify the IP and the no. of connections active on a server using the following commands


netstat -ntu | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -n


netstat -plan | grep :80 | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -n


The output would look like the following


The first column represents the no. of connections while the second column represents the source IP


Post to Twitter Tweet This Post

Continue Reading

Fix Maldet “Lightning Scan” Issues


Sometimes you will see a maldet scan gets finished at the very moment it was initiated. Moreover nothing will be detected after the ‘lightning scan’. Well, that’s not normal.

root@server [~]# maldet -b -a ~user

Linux Malware Detect v1.4.1
(C) 2002-2011, R-fx Networks <proj@r-fx.org>
(C) 2011, Ryan MacDonald <ryan@r-fx.org>
inotifywait (C) 2007, Rohan McGovern <rohan@mcgovern.id.au>
This program may be freely redistributed under the terms of the GNU GPL v2

maldet(330625): {scan} launching scan of /home/usert to background, see /usr/local/maldetect/event_log for progress

root@server [~]# tail /usr/local/maldetect/event_log
Feb 13 04:06:35 server maldet(997832): {sigup} local signature set is version 201302097471
Feb 13 04:06:35 server maldet(997832): {sigup} latest signature set already installed
Feb 13 19:53:24 server maldet(330625): {scan} launching scan of /home/user to background, see /usr/local/maldetect/event_log for progress
Feb 13 19:53:24 server maldet(330625): {scan} signatures loaded: 10695 (8827 MD5 / 1868 HEX)
Feb 13 19:53:24 server maldet(330625): {scan} building file list for /home/user, this might take awhile…
Feb 13 19:53:26 server maldet(330625): {scan} file list completed, found 6574 files…
Feb 13 19:53:26 server maldet(330625): {scan} found ClamAV clamscan binary, using as scanner engine…
Feb 13 19:53:26 server maldet(330625): {scan} scan of /home/user (6574 files) in progress…
Feb 13 19:53:26 server maldet(330625): {scan} scan completed on /home/user: files 6574, malware hits 0, cleaned hits 0
Feb 13 19:53:26 server maldet(330625): {scan} scan report saved, to view run: maldet –report 021313-1953.330625


This is not usual, it would take atleast a minute to complete the scan, so there is something wrong with the Scan signatures. 

How it works

The Maldet signature databases update every night. If there is a connection issue or something with the remote host it’ll create a 0 byte file and break. Thus there is nothing to be compared against during that scan and that is why it ends so fast.


This is the command to fix this issue, read on to the explanation

root@server [~]# cd /usr/local/maldetect && rm -rf sigs/ && mkdir sigs/ && maldet -u

# cd /usr/local/maldetect && rm -rf sigs/ && mkdir sigs/ && maldet -u
cat: /usr/local/maldetect/sigs/maldet.sigs.ver: No such file or directory
Linux Malware Detect v1.4.1
(C) 2002-2011, R-fx Networks <proj@r-fx.org>
(C) 2011, Ryan MacDonald <ryan@r-fx.org>
inotifywait (C) 2007, Rohan McGovern <rohan@mcgovern.id.au>
This program may be freely redistributed under the terms of the GNU GPL v2

maldet(350347): {sigup} performing signature update check…
maldet(350347): {sigup} could not determine signature version
maldet(350347): {sigup} signature files missing or corrupted, forcing update…
maldet(350347): {sigup} new signature set (201302097471) available
maldet(350347): {sigup} downloaded http://www.rfxn.com/downloads/md5.dat
maldet(350347): {sigup} downloaded http://www.rfxn.com/downloads/hex.dat
maldet(350347): {sigup} downloaded http://www.rfxn.com/downloads/rfxn.ndb
maldet(350347): {sigup} downloaded http://www.rfxn.com/downloads/rfxn.hdb
maldet(350347): {sigup} downloaded http://www.rfxn.com/downloads/maldet-clean.tgz
maldet(350347): {sigup} signature set update completed
maldet(350347): {sigup} 10695 signatures (8827 MD5 / 1868 HEX)


This will remove the existing signatures from the directory /usr/local/maldetect and re-download those. maldet -u will update the signatures.

If this doesn’t work either, you may have to remove and re-install Maldet

Removing Maldet

There is no such script available, just do it manually

Kill the Maldet notify service first :

maldet -k

Remove the Maldet directory :

rm -rf /usr/local/maldetect

Remove the Cron file :


Re-installing Maldet is quite easy, follow the instructions at http://www.rfxn.com/projects/linux-malware-detect/





Post to Twitter Tweet This Post

Continue Reading


TLS Authentication of LDAP sessions:

Till now all the sessions made by the LDAP client to the server is open and not encrypted. Its time to make our LDAP client-server sessions encrypted by some mechanisms. The most common encryption method includes Transport Layer Security (TLS) and/or Secure Sockets Layer (SSL) encryption.

Here, we are using own Certificate Authority (CA) and then create and sign our LDAP server certificate as that CA. The first step in the process is to obtain or create a certificate. Because slapd is compiled using the gnutls library, the certtool utility will be used to create certificates.  Now we install the gnutls-bin package by running the following command as root from the LDAP server:

root@ubuntuserver:]# apt-get install gnutls-bin

(Click To Enlarge Screenshots)

After the package is installed, we create a private key for the Certificate Authority (CA) by the following command:

root@ubuntuserver:]# sh -c “certtool –generate-privkey > /etc/ssl/private/cakey.pem”

The –generate-privkey option generates a private key and it is saved to file /etc/ssl/private/cakey.pem.

Now we create a template file /etc/ssl/ca.info to define the CA with the following entries as shown below:

root@ubuntuserver:]# : vi /etc/ssl/ca.info

cn = Support Sages

Now create the self-signed CA certificate using the following command:

root@ubuntuserver:]# certtool –generate-self-signed –load-privkey /etc/ssl/private/cakey.pem  \
–template /etc/ssl/ca.info –outfile /etc/ssl/certs/cacert.pem

Note that we are using the –template option to pass the template file /etc/ssl/ca.info created before to define the template for our self-signed CA. The –load-privkey loads the CA private key file cakey.pem which we created earlier and the –outfile option creates the required self-signed CA  cert /etc/ssl/certs/cacert.pem

Now make a private key for the LDAP server by:

root@ubuntuserver:]# certtool –generate-privkey –outfile /etc/ssl/private/ldapserver.int.sages.com_slapd_key.pem

Replace ldapserver.int.sages.com in the slapd key filename with your server’s hostname.

To sign the server’s certificate with the CA, create the /etc/ssl/ldapserver.int.sages.com.info info file containing:

root@ubuntuserver:]# : vi  /etc/ssl/ldapserver.int.sages.com.info


organization = Support Sages
cn = ldapserver.int.sages.com
expiration_days = 3650

The expiration_days attribute define the number of days the cert is valid. The above certificate is good for 10 years.(Rough calculation)

Replace canonical name cn ldapserver.int.sages.com with your server’s hostname.

And now we create the server certificate with the following command:

root@ubuntuserver:]# certtool –generate-certificate –load-privkey /etc/ssl/private/ldapserver.int.sages.com_slapd_key.pem \
–load-ca-certificate /etc/ssl/certs/cacert.pem –load-ca-privkey /etc/ssl/private/cakey.pem \
–template /etc/ssl/ldapserver.int.sages.com.info –outfile /etc/ssl/certs/ldapserver.int.sages.com_slapd_cert.pem

In the above command we pass the template file ldapserver.int.sages.com.info using the –template option to define the template for our server cert as we did for creating our self-signed CA. The –load-privkey loads the servers private key file ldapserver.int.sages.com_slapd_key.pem which we created earlier, –load-ca-privkey loads our CA private key , –load-ca-certificate option passes the CA cert cacert.pem and the –outfile option creates the cert /etc/ssl/certs/ldapserver.int.sages.com_slapd_cert.pem.

Now we have a certificate, key, and CA cert installed. Use ldapmodify command to add the new configuration options to slapd tree. As we know that ldapmodify is a command to modify our DIT and we use LDIF file format for this. So we create an LDIF file certinfo.ldif with the following entries:

root@ubuntuserver:]# : vi certinfo.ldif

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldapserver.int.sages.com_slapd_cert.pem
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldapserver.int.sages.com_slapd_key.pem

Note that the certificate file names should be configured correctly in the above file with respect to the certs you created for your hostname.

Now we use the ldapmodify command to add the data to the cn=config DIT and tell slapd that our TLS work via the slapd-config(cn=config) database.

root@ubuntuserver:]# ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f certinfo.ldif

You can see an output as shown below:


modifying entry “cn=config”


Once this is done make usre that the follwing entry is uncomented in /etc/default/slapd file:

SLAPD_SERVICES=”ldap:/// ldapi:///”

Contrary to our popular belief, we do not need ldaps:// in /etc/default/slapd in order to use TLS encryption. You should have just:
SLAPD_SERVICES=”ldap:/// ldapi:///”

LDAP over TLS  works using StartTLS. STARTTLS is an extension to plain text communication protocols, which offers a way to upgrade a plain text connection to an encrypted (TLS or SSL) connection instead of using a separate port for encrypted communication. So here an existing LDAP session (listening on TCP port 389) becoming protected by TLS/SSL. Whereas LDAPS, like HTTPS, is a distinct encrypted-from-the-start protocol that operates over TCP port 636. We are using STARTLS for our encryption.

Now its time to set permissions and ownerships for our certificate files such that the openldap user gets access to these certificates:

root@ubuntuserver:]# adduser openldap ssl-cert

At times you will get an error mesasge as given below while excecuting the adduser command:
adduser: The group `ssl-cert’ does not exist.
To overcome this install the package ssl-cert by:

root@ubuntuserver:]# apt-get install ssl-cert

This installs the ssl-cert package which creates the ssl-cert group automatically. Now excecute the adduser command:

root@ubuntuserver:]# adduser openldap ssl-cert

Run the following commands to change the group and permissions:

root@ubuntuserver:]# chgrp ssl-cert /etc/ssl/private/ldapserver.int.sages.com_slapd_key.pem
root@ubuntuserver:]# chmod g+r /etc/ssl/private/ldapserver.int.sages.com_slapd_key.pem

Now restart slapd by:

root@ubuntuserver:]# /etc/init.d/slapd restart

If slapd restarts fine, then we can make sure that the TLS configurations are fine. Or if you run into troubles with the server not starting, check the /var/log/syslog. If you see errors like main: TLS init def ctx failed: -1, it is likely there is a configuration problem. Check that the certificate is signed by the authority from in the files configured, and that the ssl-cert group has read permissions on the private key.

Now we should configure our LDAP server to use TLS by editing the /etc/ldap/ldap.conf file as shown below:

BASE    dc=int,dc=sages,dc=com
URI     ldap//ldapserver.int.sages.com
SIZELIMIT       12
TIMELIMIT       15
DEREF           never
TLS_REQCERT     allow
TLS_CACERT      /etc/ssl/certs/ca-certificates.crt

Now we should make our client use TLS authentication. This can be done by editing the configuration file /etc/ldap.conf on the LDAP client machine:

[ldapclient@ubuntuserver:]#   vi  /etc/ldap.conf

Make sure the following entries are uncommented :

ssl start_tls
tls_checkpeer no
These two entries in ldap.conf makes the client use TLS certs for encrypted sessions with our LDAP server. Lets check whether the session is using TLS using ldapsearch command.

You can use the ZZ switch to the ldapsearch utility to see if we are using encrypted sessions.

[ldapclient@ubuntuserver:]#  ldapsearch -xZZ -h ldapserver.int.sages.com

(-x disables SASL authentication, -Z tells to start TLS request (-ZZ to require successful response) , -h defines the hostname of our LDAP server)

But this command returns an error as show below:
ldapsearch -xZZ -h ldapserver.sages.com
ldap_start_tls: Connect error (-11)
additional info: (unknown error code)
Note that the ldapsearch is an ldap utility which we got when we installed ldap-utils package. And the ldap-utils uses /etc/ldap/ldap.conf file. So make sure the following entries are there in /etc/ldap/ldap.conf on LDAP client :
BASE    dc=int,dc=sages,dc=com
URI     ldap//ldapserver.int.sages.com
SIZELIMIT       12
TIMELIMIT       15
DEREF           never
TLS_REQCERT     allow
Now run the ldapsearch from the LDAP client as follows:

[ldapclient@ubuntuserver:]#  ldapsearch -xZZ -h ldapserver.int.sages.com

You will see all our LDAP users from our LDAP server. If all the users are listed while using the -ZZ switch with ldapsearch command we can make sure that the session is encrypted for that listed users.

Post to Twitter Tweet This Post

Continue Reading

SSL Installation in a cPanel based server

What is SSL

SSL (Secure Sockets Layer) is a cryptographic protocol which ensure the security of communication over the Internet. SSL encrypt the segments of network connections above the Transport Layer, using symmetric cryptography for privacy and a keyed message authentication code for message reliability.

How SSL works

Web servers and Web browsers rely on the SSL protocol to create a unique encrypted channel for private communications over the Internet. The SSL Certificate consists of a public key and a private key. The public key is used to encrypt information and the private key is used to decrypt it. When a Web browser points to a domain which is secured by SSL, a level of encryption is established based on the type of SSL Certificate as well as the client Web browser, operating system and host server’s capabilities. This is why SSL certificates feature a different range of encryption levels.

Obtaining an SSL Certificate

Domain example.com needs an SSL Certificate. The following steps are involved in it :

a) Example.com generates a CSR (Certificate Signing Request) and during this process, a private key is generated.
b) With this CSR, Example.com goes to a trusted, third party Certificate Authority like Verisign. They take the Certificate Signing Request and validates example.com. The Certificate Authority validates example.com.
c) When the validation process is complete, the third party Certificate Authority gives a new public key (certificate) encrypted with their private key.
d) Example.com installs the new certificate and gets secured.

Installing SSL

(i) Through cPanel/WHM
Its quite easy to install SSL through cPanel/WHM interface.

Generating CSR

Under Security tab, click SSL/TLS Manager.

Generate the Private Keys first by accessing the option Generate, view, upload or delete your private keys

Access the option Generate, view, or delete SSL certificate signing requests. Fill in the forms like Domain Name, E-mail Address, Country etc.

You will obtain the CSR. Contact the Certificate provider with this information. The Certificate Authority will then provide the Certificate (CRT). Finally you will have the following files associated with SSL :

CSR in the format domain.com.csr or domain_com.csr

CA bundle, which have the Public key of the Certificate Authority in the format domain.com.cabundle or domain_com.ca-bundle

CRT, the certificate in the format domain.com.crt or domain_com.crt

Private key in the format domain.com.key or domain_com.key

Method 1 : Installing from cPanel

1. Go to SSL/TLS Manager.
2. Click Generate, view, upload, or delete your private keys.
3. Under the Upload a New Certificate section, click on the Browse button (next to Choose a .crt file option) and find the Domain Certificate file (example.crt) that you obtained from the SSL vendor. Alternatively you can paste the Certificate contents on the section Paste the crt below. Make sure to include the BEGIN and END tags, while copying your certificate. Click the Upload button.
4. Go Back and click Return to SSL Manager at the bottom of the page.
5. Click on Setup a SSL certificate to work with your site. If this option is not available, your web host may have disabled it. You will need to contact them for further support.
6. Now, select the domain you are using from the Domain drop down menu. It will attempt to fetch the SSL Certificate and the private key. If this doesn’t work, you may need to contact your web host.
7. In the box labeled CA Bundle paste the contents of the Intermediate certificate (DigiCertCA.crt).
8. Click Install Certificate. Your SSL certificate should now be installed, and the website configured to accept secure connections. You or your web host may need to restart Apache before it will work.

Method 2 : Installing from WHM

You can install SSL certificate from WHM also. Its quite simple when compared to the installation through cPanel. All you need is the root access to WHM. Once you login to the WHM, search for the option Install a SSL Certificate and Setup the Domain.

You’ll find three boxes. Paste the CRT file contents in the first box. It will automatically fetch the Key and CA Bundle (In most cases, CA bundle needs to be fetched manually). Finally click Submit once all the fields are populated. You’ll see a message that indicates the installation is successful

Method 3 : Manual Installation

You need the Server Root shell access for this. Go to the Apache configuration file in the server, in the cPanel case its /usr/local/apache/conf/httpd.conf. Locate the VirtualHost entry configured for SSL. Configure it like :

<VirtualHost xxx.xxx.x.xx:443>
ServerName example.com
ServerAlias www.example.com
DocumentRoot /home/example/public_html
SSLEngine on
SSLCertificateFile /usr/share/ssl/certs/example.com.crt
SSLCertificateKeyFile /usr/share/ssl/private/example.com.key
SSLCACertificateFile /usr/share/ssl/certs/example.com.cabundle

where SSLCertificateFile is the SSL certificate file path, SSLCertificateKeyFile is the Key file path, SSLCACertificateFile is the path to the Intermediate file. Make sure you’ve the files in the specified path (It may vary on different scenarios). Restart the Web server and you’re done.

Post to Twitter Tweet This Post

Continue Reading

DDoS, prevention, cure! – Part 2

DDoS/DoS Prevention and Cure :

DDoS/DoS cannot be completely prevented by any of the service provides, but certain measures could help us to reduce the impact of attack.

The companies must develop and produce certain strict policies and rules to ensure the best practices are allowed. Strict security policies must be used and should be always updated. Having a AUP is a key tool to remove the abusive user from the network/system.

Having a separate team to handle abusive incidents is a good practice to whom the incidents could be notified and alerted.

Upgrades and Updates : Through testing must be done before a system is introduced to a production environment. Security should be considered from the start of the system design. Things to consider include:

  • Operating system lockdown and removal of any unnecessary processes,services and software. This should be done via scripts or by checklists preferably developed using industry best practices.
  • Review of system protocols to ensure communication paths are properly authenticated and if necessary encrypted.
  • Scanning of the systems to confirm and mitigate, if necessary, any security risks found.
  • If software source code is available, security source code reviews should be performed to eliminate buffer overflows and other vulnerabilities.
  • Apply patches in time

Here are some steps by which we could defend the impact of DDOS to a certain extent.

Setup machine / network keeping security in mind (Implement Good Security policy)

Setup a firewall which does Ingress and Egress Filtering at Gateway

Eg: Steps to Install AFP

[bash]wget http://www.rfxnetworks.com/downloads/apf-current.tar.gz

tar -zxf apf-current.tar.gz

cd apf-<version number>

./install.sh [/bash]

Notes: Go through the Document in the Apf and configure it for your needs. All configuration is set at conf.apf which is normally located at /etc/apf/conf.apf

Enable Anit-DOS mode in Apf (ie in conf.apf) . Also make sure that your root’s cron has an entry like the one below

*/8 * * * * root /etc/apf/ad/antidos -a >> /dev/null 2>&1

Install IDS on your gateway/hosts to alert you when someone tries to sniff In.


[bash]wget ftp://ftp.cs.tut.fi/pub/src/gnu/aide-0.7.tar.gz

tar -zxvf aide-0.7.tar.gz

cd aide-0.7

./configure -with-gnu-regexp [/bash]

Final steps to install make;make install. Now the main step..To configure AIDE.AIDE stores all its rule sets in the file called aide.conf. Lets populate it get more details of how to configure and all from man aide.conf

Here I am taking an example .See below

Here is a sample short aide.conf:

[bash]Rule = p+i+u+g+n+s+md5

/etc p+i+u+g

/sbin Rule

/usr/local/apache/conf Rule

/var Rule


!/var/log/.* [/bash]

In the above configuration listed , a rule called “Rule” is set to check permissions (p), inode (i), user (u), group (g), number of links (n), size (s), and md5 checksum (md5). This rules are applied to all files in /bin, /sbin, /var, and /usr/local/apache/conf because they should rarely if ever change. Files in /etc are checked for changes in only permissions, inode, user, and group because their size may change, but other things shouldn’t. Files and directories in /var/spool and /var/log are not checked because those are folders where maximum updation takes place.

After configuring AIDE should be initiated with all these rules.

For that execute aide -init

Conduct regular Audits on each host on the network to find installation of DDOS tools / Vulnerable applications.

Use tools like RKDET(vancouver-webpages.com/rkdet),RKHUNTER(www.rootkit.nl) and CHKROOTKIT(www.chkrootkit.org) to find if any rootkit has been already installed and to locate the effected binaries in the machine, if any.

Please find a simple Audit check List below to be done on a Hosts

Eg: Audit Check List

A quick checklist:

* Software Vulnerabilities.

* Kernel Upgrades and vulnerabilities.

* Check for any Trojans.

* Run chkrootkit.

* Check ports.

* Check for any hidden processes.

* Use audittools to check system.

* Check logs.

* Check binaries and RPMS.

* Check for open email relays.

* Check for malicious cron entries.

* Check /dev /tmp /var directories.

* Check whether backups are maintained.

* Check for unwanted users, groups, etc. on the system.

* Check for and disable any unneeded services.

* Locate malicious scripts.

* Querylog in DNS.

* Check for the suid scripts and nouser scripts.

* Check valid scripts in /tmp.

* Use intrusion detection tools.

* Check the system performance.

* Check memory performance (run memtest).

Enforce and Implement Security Measures on all hosts in the network.

Machines new or old should only be allowed to run on your network, if your Security Admin or DSE (Dedicated Security Expert) member approves it with status “OK-to go live” after auditing the box. All Host in the network should be checked on a regular basis by your DSE team to make sure that all hosts are uptodate and can fight any attacks.

Audit network on a regular basis to see if your network is vulnerable to attacks

Use Open Source Tools like NESSUS(www.nessus.org) ,NMAP(www.insecure.org/nmap),SAINT( www.saintcorporation.com/products/saint_engine.html),SARA (www-arc.com/sara/sara.html)for auditing a network to find its vulnerabilities.

Create a DSE (Dedicated Security Expert ) Team for your company.

Collect your networks and hosts data . Analysis them and study them to see from where and what kind of attacks are coming into the network. This step will help us to understand what kind of attacks we are facing and will help us to strengthen the preventive measures. Let me tell you this move is worth the money you spend,for sure.

Implement Sysctl protection against DDOS


[bash] vi /etc/sysctl.conf [/bash]

add the below code:

[bash]# Enable IP spoofing protection, turn on Source Address Verification

net.ipv4.conf.all.rp_filter = 1

# Enable TCP SYN Cookie Protection

net.ipv4.tcp_syncookies = 1 [/bash]

Add the below code in /etc/rc.local and restart network

[bash]for f in /proc/sys/net/ipv4/conf/*/rp_filter;

do echo 1 > done

echo 1 > /proc/sys/net/ipv4/tcp_syncookies [/bash]

Install Mod_dosevasive to your apache.

Mod_dosevasive is module for Apache to perform evasive action in the event of an HTTP DDoS attack or brute force attack. Please find the installation step of mod_dosevasive in DSO mode below

Install Mod_dosevasive

[bash]wget http://www.nuclearelephant.com/projects/mod_evasive/mod_evasive_1.10.1.tar.gz

tar -zxvf mod_evasive_1.10.1.tar.gz

cd mod_evasive_1.10.1

$APACHE_ROOT/bin/apxs -iac mod_evasive.c [/bash]

Dont get scared by the variable “$APACHE_ROOT” . Its nothing, but a simple variable which stores the location of the apache installation (eg $APACHE_ROOT =/usr/local/apache)

[bash]vi /usr/loca/apache/conf/httpd.conf [/bash]

After this add the below code in httpd.conf

[bash]<IfModule mod_dosevasive.c>

DOSHashTableSize 3097

DOSPageCount 2

DOSSiteCount 50

DOSPageInterval 1

DOSSiteInterval 1

DOSBlockingPeriod 10

</IfModule> [/bash]

[bash]/usr/loca/apache/bin/apachectl restart [/bash]

Install Mod_security .

Since DDOS normally targets http. Its always good to have a filtering system for apache . So that the request gets analyzed before web server handles it. Please find the installation step of mod_security in DSO mode below

Eg: Installation Steps


tar -zxvf modsecurity-apache-1.9.2.tar.gz

cd modsecurity-apache-1.9.2

/usr/local/apache/bin/apxs -cia mod_security.c [/bash]

Create a file named mod_security.conf under the folder /usr/local/apache/conf

[bash] vi /usr/local/apache/conf/mod_security.conf [/bash]

Create the rule with reference to the link http://www.modsecurity.org/documentation/quick-examples.html

and add it in the mod_security.conf file.

Add the location of mod_security.conf to httpd.conf

[bash] vi /usr/local/apache/conf/httpd.conf [/bash]

Add the string below Include /usr/local/apache/conf/mod_security.conf

[bash] /usr/local/apache/bin/apachectl stop

/usr/local/apache/bin/apachectl start [/bash]

Post to Twitter Tweet This Post

Continue Reading

About this blog

This blog, acts as a knowledge repository for the world and is unofficial! Anything we find interesting in the cyber world will go here. Most cases, this blog will reflect the happiness of our staff in reaching successful solution to an issue (s)he worked on. A reference for other fellow SAGEs who come across similar issues later