SSL
Having SSL is additional layer of security you are adding into Wb Application. However, Default SSL configuration leads to certain valunerabilities and you should consider tweaking those configurations. we require some tool to verify SSL settings. There are many available however,I would use SSL-Scan free tool. You can download from
http://sourceforge.net/projects/sslscan/
Download & Installation
Following prerequisites must be installed on server where you wish to use Mod Security with Apache. If any one of these doesn't exist then Mod Security compilation will fail. You may use yum install on Linux flavors to install these packages.
--> apache 2.X or higher version
--> libapr and libapr-util package
--> libcurl package
--> libpcre package
--> libxml2 package
--> liblua package
--> mod_unique_id module bundled with Apache web server
Now ,let's download the latest stable version of Mod Security 2.9.0 from
http://www.modsecurity.org/download/
Transfer downloaded file to /opt/apache
[/opt/apache]# ls -lrt modsecurity-apache_2.9.0.tar.gz
Now Extract modsecurity-apache _2.9.0.tar.gz
# gunzip -c modsecurity-apache_2.9.0.tar.gz
# tar -xvf modsecurity-apche_2.9.0.tar
Now Move to Extracted folder modsecurity-apache_2.9.0
# cd modsecurity-apache_2.9.0
Run the configuration script including apxs path to existing Apache
#./configure -with-apxs=/opt/apache/bin/apxs
Now Compile and install with make Script
# make
# make install
Once installation is done ,we can find mod_security2.so in modules folder under /opt/apache
Now We have installed Mod Security module in existing Apache web server
Configuration
In order to use Mod security feature with Apche, we have to load mod security module in httpd.conf mod_unique_id module is pre requisite for Mod Security. This module provides an environment variable with a unique identifier for each request, which is tracked and used by Mod Security.
-->Add following line to load module for Mod Security in httpd.conf and save the configuration file
LoadModule unique_id_module modules/mod_unique_id.so
LoadModule security2_module modules/mod_security2.so
--> Restart Apache web server
Mod Security is now installed ,Now we need to install Mod Security core rule to take a full advantage of its features. Latest Core Rule can be downloaded from following link,which is free
https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master
--> copy downloaded core rule zip to /opt/apche/conf folder
--> Unzip core rule file, you should see the extracted folder as SpiderLabs-owasp- modsecurity-crs-0f07cbb
--> lets make folder name simple .rename the SpiderLabs-owasp-modsecurity-crs- 0f07cbb to crs
[/opt/apache/conf]# mv SpiderLabs-owasp-modsecurity-crs-0f07cbb/ crs
--> now Go to crs folderand rename modsecurity_crs_10_setup.conf.example to modsecurity_crs_10_setup.conf
[/opt/apache/conf/crs]# mv modsecurity_crs_10_setup.conf.exaple modsecurity_crs_10_setup.conf
--> Now ,Let's enable these rules to get it working with Apache web server.
Add the following lines in httpd.conf
<IfModule security2_module>
Include conf/crs/modsecurity_crs_10_setup.conf
Include conf/crs/base_rules/*.conf
</IfModule>
In the above Configuration, we are loading Mod Security main configurationfile modsecurity_crs_10_setup.conf and base rules base_rules/*.conf provided by
Mod Security Core Rules to protect web applications
--> Restart apache webserver
Now we successfully configured Mod Security with Apache. Our Apache Web server is protected with Mod Security web application firewall.
Get Started
Lets get it started with some of the important configuration in Mod Security to harden &secure web applications. In this section , we will do all configuration modification in /opt/apache/conf/crs/modsecurity_crs_10_setup.conf
we will refer /opt/apache/conf/crs/modsecurity_crs_10_setup.conf as setup.conf in this section for example purpose. It's important to understand what are the OWASP rules are provided in free.
Types of rules provided by OWASP are.
Base Rules-these rules are heavily tested and probably false alarm ratio is less.
Experimental Rules-these rules are for experimental purpose and you may have high false alarm. It's important to configure , test and implement in UAT before using these in production environment.
Optional Rules- these optional rules may not be suitable for the entire environment. Based on your requirement you may use them. If you are looking for CSRF, User Trackin, Session hijacking, etc. protection then you may consider using optional rules. we have base, optional and experimental rules after extracting downloaded crs zip file from OWASP download page. These rules configuration file is available in crs/base, crs/optional_rules ans crs/experimental_rules folder.
Some of the Base rules are
modsecurity_crs_20_protocal_violations.conf:This rule is protecting from protocal vulnerabilities like response splitting , request smuggling, using non-allowed protocal(HTTP 1.0).
modsecurity_crs_21_protocal_anamalies.conf:This is to protect from request, which is missing with Host, Accept, User-Agent in header.
modsecurity_crs_23_protocal_request_limit.conf:This rule has dependency on application specific like request size , upload size, length of parameter, etc.
modsecurity_crs_30_http_policy.conf:This is to configure and protect allowed or disallowed method like CONNECT , TRACE,PUT, DLETE, etc.
modsecurity_crs_35_bad_robots.conf: Detect malicious robots.
modsecurity_crs_40_generic_attacks.conf:This is to protect from OS command injection, remote file inclusion, etc.
modsecurity_crs_41_sql_injection_attacks.conf: This rule is to protect SQL and blindSQL inject request.
modsecurity_crs_41_xss_attacks.conf: Protect from cross site scripting request
modsecurity_crs_42_tight_security.conf: Directory traversal detection and request.
modsecurity_crs_45_trojans.conf:Tthis rule is to detect generic file management output , uploading of http backdoor page, known signature.
modsecurity_crs_47_common_exceptions.conf:This is used as an exception mechanism to remove common false positives that may be encountered suck as Apache internal dummy connection, SSL pinger, etc.
Logging
Logging is one of the first things to configure so you can have logs created for what Mod Security is doing. there are two types of logging available , Debug &Audit log.
Debug Log : This is to Duplicate the Apache error , warning and notice message from the error log.
Audit Log : This is to write the transaction logs that are marked by Mod Security rule, Mod Security gives you flexibility to configure Audit , Debug or both logging. By Default configuration will write both logs. However , you can change based on your requirement. Log is controlled in SecDefultAction directive. Let's look at default logging configuration in setup.conf
secDefaultAction "phase:1,deny,log"
To log Debug ,Audit log - use "log" .
To log only audit log - use "nolog,auditlog"
To log only debug log - use "log,noauditlog"
You can specify the Audit Log location to be stored which is controlled by SecAuditLog directive. Let's write audit log into /opt/apache/logs/modsec_audit.log by adding as shown below.
Implementation
Add SecAuditLog directive in setup.conf and restart apache web server
SecAuditLog /opt/apache/logs/modsec_audit.log
After restart , you should see modsec_audit.log getting generated in /opt/apache/logs
Enable Rule Engine
By default Engine Rule is Off that means if you don't enable RuleEngine you are not utilizing all the advantage of Mod Security. Rule Engine enabling or disabling is controlled by SecRuleEngine directive
Implementation
Add SecRuleEngin directive in setup.conf and restart apache web Server
SecRuleEngine On
There are three values for SecRuleEngine:
On- to enable Rule Engine
Off- to disable Rule Engine
DetectOnly - enable Rule Engine but never executes any actions like block,deny,drop,allow,proxy or redirect.
Once Rule Engine is on -Mod Security is ready to protect with some of the common attack types.
Disable SSL v2
SSL v2 has many security flaws and if you are working towards penetration test or PCI compliance then you are expected to close security finding SSL v2. Any SSL v2 communication may be vulnerable to Man-in Middile attack that could allow data tempering or disclosure. let's implement apache web server to accept only latest SSL v3 and reject SSL v2 connection request.
Implementation:
Go to $Web_Server/conf/extra folder
Modify SSL Protocol directive in httpd-ssl.conf as below to accept only SSL v3 and TLS v1
SSLProtocal -ALL +SSLv3 +TLSv1
verification
Let's use sslscan utility to validate as below command .change localhost to your actual domain name
[/opt/apache/conf/extra] # sslscan --no-failed localhost
In output you could see only SSLv3 and TLSv1 ,Which is Safe from SSLv2 vulnerabilities
Having SSL is additional layer of security you are adding into Wb Application. However, Default SSL configuration leads to certain valunerabilities and you should consider tweaking those configurations. we require some tool to verify SSL settings. There are many available however,I would use SSL-Scan free tool. You can download from
http://sourceforge.net/projects/sslscan/
Download & Installation
Following prerequisites must be installed on server where you wish to use Mod Security with Apache. If any one of these doesn't exist then Mod Security compilation will fail. You may use yum install on Linux flavors to install these packages.
--> apache 2.X or higher version
--> libapr and libapr-util package
--> libcurl package
--> libpcre package
--> libxml2 package
--> liblua package
--> mod_unique_id module bundled with Apache web server
Now ,let's download the latest stable version of Mod Security 2.9.0 from
http://www.modsecurity.org/download/
Transfer downloaded file to /opt/apache
[/opt/apache]# ls -lrt modsecurity-apache_2.9.0.tar.gz
Now Extract modsecurity-apache _2.9.0.tar.gz
# gunzip -c modsecurity-apache_2.9.0.tar.gz
# tar -xvf modsecurity-apche_2.9.0.tar
Now Move to Extracted folder modsecurity-apache_2.9.0
# cd modsecurity-apache_2.9.0
Run the configuration script including apxs path to existing Apache
#./configure -with-apxs=/opt/apache/bin/apxs
Now Compile and install with make Script
# make
# make install
Once installation is done ,we can find mod_security2.so in modules folder under /opt/apache
Now We have installed Mod Security module in existing Apache web server
Configuration
In order to use Mod security feature with Apche, we have to load mod security module in httpd.conf mod_unique_id module is pre requisite for Mod Security. This module provides an environment variable with a unique identifier for each request, which is tracked and used by Mod Security.
-->Add following line to load module for Mod Security in httpd.conf and save the configuration file
LoadModule unique_id_module modules/mod_unique_id.so
LoadModule security2_module modules/mod_security2.so
--> Restart Apache web server
Mod Security is now installed ,Now we need to install Mod Security core rule to take a full advantage of its features. Latest Core Rule can be downloaded from following link,which is free
https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master
--> copy downloaded core rule zip to /opt/apche/conf folder
--> Unzip core rule file, you should see the extracted folder as SpiderLabs-owasp- modsecurity-crs-0f07cbb
--> lets make folder name simple .rename the SpiderLabs-owasp-modsecurity-crs- 0f07cbb to crs
[/opt/apache/conf]# mv SpiderLabs-owasp-modsecurity-crs-0f07cbb/ crs
--> now Go to crs folderand rename modsecurity_crs_10_setup.conf.example to modsecurity_crs_10_setup.conf
[/opt/apache/conf/crs]# mv modsecurity_crs_10_setup.conf.exaple modsecurity_crs_10_setup.conf
--> Now ,Let's enable these rules to get it working with Apache web server.
Add the following lines in httpd.conf
<IfModule security2_module>
Include conf/crs/modsecurity_crs_10_setup.conf
Include conf/crs/base_rules/*.conf
</IfModule>
In the above Configuration, we are loading Mod Security main configurationfile modsecurity_crs_10_setup.conf and base rules base_rules/*.conf provided by
Mod Security Core Rules to protect web applications
--> Restart apache webserver
Now we successfully configured Mod Security with Apache. Our Apache Web server is protected with Mod Security web application firewall.
Get Started
Lets get it started with some of the important configuration in Mod Security to harden &secure web applications. In this section , we will do all configuration modification in /opt/apache/conf/crs/modsecurity_crs_10_setup.conf
we will refer /opt/apache/conf/crs/modsecurity_crs_10_setup.conf as setup.conf in this section for example purpose. It's important to understand what are the OWASP rules are provided in free.
Types of rules provided by OWASP are.
Base Rules-these rules are heavily tested and probably false alarm ratio is less.
Experimental Rules-these rules are for experimental purpose and you may have high false alarm. It's important to configure , test and implement in UAT before using these in production environment.
Optional Rules- these optional rules may not be suitable for the entire environment. Based on your requirement you may use them. If you are looking for CSRF, User Trackin, Session hijacking, etc. protection then you may consider using optional rules. we have base, optional and experimental rules after extracting downloaded crs zip file from OWASP download page. These rules configuration file is available in crs/base, crs/optional_rules ans crs/experimental_rules folder.
Some of the Base rules are
modsecurity_crs_20_protocal_violations.conf:This rule is protecting from protocal vulnerabilities like response splitting , request smuggling, using non-allowed protocal(HTTP 1.0).
modsecurity_crs_21_protocal_anamalies.conf:This is to protect from request, which is missing with Host, Accept, User-Agent in header.
modsecurity_crs_23_protocal_request_limit.conf:This rule has dependency on application specific like request size , upload size, length of parameter, etc.
modsecurity_crs_30_http_policy.conf:This is to configure and protect allowed or disallowed method like CONNECT , TRACE,PUT, DLETE, etc.
modsecurity_crs_35_bad_robots.conf: Detect malicious robots.
modsecurity_crs_40_generic_attacks.conf:This is to protect from OS command injection, remote file inclusion, etc.
modsecurity_crs_41_sql_injection_attacks.conf: This rule is to protect SQL and blindSQL inject request.
modsecurity_crs_41_xss_attacks.conf: Protect from cross site scripting request
modsecurity_crs_42_tight_security.conf: Directory traversal detection and request.
modsecurity_crs_45_trojans.conf:Tthis rule is to detect generic file management output , uploading of http backdoor page, known signature.
modsecurity_crs_47_common_exceptions.conf:This is used as an exception mechanism to remove common false positives that may be encountered suck as Apache internal dummy connection, SSL pinger, etc.
Logging
Logging is one of the first things to configure so you can have logs created for what Mod Security is doing. there are two types of logging available , Debug &Audit log.
Debug Log : This is to Duplicate the Apache error , warning and notice message from the error log.
Audit Log : This is to write the transaction logs that are marked by Mod Security rule, Mod Security gives you flexibility to configure Audit , Debug or both logging. By Default configuration will write both logs. However , you can change based on your requirement. Log is controlled in SecDefultAction directive. Let's look at default logging configuration in setup.conf
secDefaultAction "phase:1,deny,log"
To log Debug ,Audit log - use "log" .
To log only audit log - use "nolog,auditlog"
To log only debug log - use "log,noauditlog"
You can specify the Audit Log location to be stored which is controlled by SecAuditLog directive. Let's write audit log into /opt/apache/logs/modsec_audit.log by adding as shown below.
Implementation
Add SecAuditLog directive in setup.conf and restart apache web server
SecAuditLog /opt/apache/logs/modsec_audit.log
After restart , you should see modsec_audit.log getting generated in /opt/apache/logs
Enable Rule Engine
By default Engine Rule is Off that means if you don't enable RuleEngine you are not utilizing all the advantage of Mod Security. Rule Engine enabling or disabling is controlled by SecRuleEngine directive
Implementation
Add SecRuleEngin directive in setup.conf and restart apache web Server
SecRuleEngine On
There are three values for SecRuleEngine:
On- to enable Rule Engine
Off- to disable Rule Engine
DetectOnly - enable Rule Engine but never executes any actions like block,deny,drop,allow,proxy or redirect.
Once Rule Engine is on -Mod Security is ready to protect with some of the common attack types.
Disable SSL v2
SSL v2 has many security flaws and if you are working towards penetration test or PCI compliance then you are expected to close security finding SSL v2. Any SSL v2 communication may be vulnerable to Man-in Middile attack that could allow data tempering or disclosure. let's implement apache web server to accept only latest SSL v3 and reject SSL v2 connection request.
Implementation:
Go to $Web_Server/conf/extra folder
Modify SSL Protocol directive in httpd-ssl.conf as below to accept only SSL v3 and TLS v1
SSLProtocal -ALL +SSLv3 +TLSv1
verification
Let's use sslscan utility to validate as below command .change localhost to your actual domain name
[/opt/apache/conf/extra] # sslscan --no-failed localhost
In output you could see only SSLv3 and TLSv1 ,Which is Safe from SSLv2 vulnerabilities
No comments:
Post a Comment