Web Application Firewall (ModSecurity) in action
Attacks to the web application layer are some of the most common and often extremely critical. In this article I want to show how WAF ModSecurity is able to reflect these threats.
ModSecurity was created by Ivan Ristic in 2003 and is a firewall of Web applications that can be used as a module of the Apache web server, or work offline and protect Web applications from both known and unknown attacks. Its use is transparent, both installation and uninstallation do not require changing service settings and network topology. In addition, when a vulnerability is detected, it is no longer necessary to hastily change the source code, making new errors, at first it’s enough to add a new rule prohibiting a harmful combination. Modsecurity can protect several Web servers at the same time, including non-Apache [1].
In addition to regular connections, it can also control secure SSL traffic. Flexible logging rules allow you to record any session data, allowing you to completely parse requests prior to hacking in the future. Understanding the HTTP protocol allows you to perform very fine filtering; it supports both GET and POST methods, and requests for dynamic resources. To deal with various methods of evasion (links to external sites, encoded URLs, the use of several slashes, zero bytes, etc.), the paths and parameters are normalized. In the new version, it is possible to inherit rules, a new audit log format is used, which allows for real-time audit. In addition, this version introduces a new mechanism called guardian, whose task is to control requests made from one address, which allows you to protect yourself from DOS attacks by configuring iptables rules. ClamAV antivirus integration with Open Source makes it possible to scan downloaded files for viruses. The version adds PCRE support, which can now be used instead of the regex library for Apache. The amount of code compared to the previous version increased by 40%. ModSecurity is distributed under a dual license: the GNU GPL, as a free Open Source application, several options for end-user and OEM commercial licenses are also available [1].
There are two typical installation options for ModSecurity [3].
a) Installation directly on the web server.
b) Installation as a reverse proxy server (Reverse Proxy).
I must say that ModSecurity is used only with Apache Web servers, preferably version 2.x. Apache server can run both under Linux / UNIX and under Windows (http://httpd.apache.org). The ModSecurity module was originally created under Linux / UNIX (http://www.modsecurity.org), but thanks to the work of Stefan Land, it was successfully ported to Microsoft Windows (http://www.apachelounge.com). Compare the difference between installing ModSecurity directly on a Web server and installing it as a reverse proxy [3].
In the first case, ModSecurity intercepts all requests to the Web server on which it is installed: the request from the client is first compared with the filter rules of the ModSecurity module, and then it is passed to the Web server for further processing. ModSecurity can also control Web server responses, i.e. after the formation of the page, the response is processed by the module and, in accordance with the rules, blocks or allows the passage of the response of the Web server. The latter option can be used to replace pages with Web application errors that result from Web server processing requests from the client with standard pages (for example, 404 error pages). This will reduce the amount of critical information transmitted to the client about the operation of the application and complicate the task of a potential attacker [3].
This installation option is limited to using Apache as a Web server and cannot be used to protect other Web servers.
Installing Apache with the ModSecurity module as a reverse proxy server allows you to intercept client requests for Web servers deployed on any platform (IIS, Apache, WebSphere, etc.). The principle of the reverse proxy server is that the server redirects all requests from clients to the Web server and redirects it to the client when a response is received. Clients “see” only the external interface of the proxy server and “do not see” the Web servers located behind it. In this case, the disadvantages are the need to purchase additional equipment for the proxy server and the presence of a single point of failure for one or more Web servers. However, the proxy server itself can perform additional useful functions, such as caching static requests and balancing the load on a group of Web servers [3].
Here are some of the key features provided by ModSecurity.
a) Analysis of the request. This is the main function of this module, especially when you deal with POST requests, in which obtaining the request body can be difficult [2].
b) Performing canonization and anti-evasion functions. Perform a series of transformations to convert the input data into a form suitable for analysis. This step is used to combat various dodging techniques.
c) Performing special built-in checks. At this point, more complex validations are performed, such as validating URL encodings and validating Unicode encodings. You can also control some byte values in a request to combat shellcode.
d) Launching input rules. At this point, the rules you created are triggered. They allow you to parse every aspect of the query using regular expressions. Also, several rules can be combined here for a more complex analysis [2].
Then the request reaches the handler. After the request, the following actions are performed.
a) Launching inference rules. Inference rules apply to the response body. They are very useful for preventing information leaks [2].
b) Registration of the request. The final request is made up of the request body and input and output headers. To prevent excessive registration, ModSecurity can register optional requests, for example, requests that have received a response from ModSecurity [2].
The benefits of ModSecurity are as follows.
1) Free.
2) Open source.
3) Filters both outgoing and incoming data.
4) A convenient language for writing filtering rules, based on regular expression checking.
5) Integration with Apache proxy modules, which optimally accelerates the work of the Web server (loadbalancing).
6) A graphical shell for writing safety rules (REMO) [4].
ModSecurity on the Habr:
1) Beta version of modSecurity for Nginx
2) Protection of the Apache web server from a slow read attack, as well as some other targeted attacks
Figure 1.1 shows a diagram of the practical implementation of the attacking effect on a protected ModSecurity server with the Webgoat project (this project is discussed in more detail at the end of the article). An attacker using specialized software (MS Internet Explorer browser, WebScarab proxy server, Acunetix WVS 6 scanner) will attack a Web server with a pre-installed WebGoat project. In the future, the operation scheme will be changed - after the appropriate configuration of the Web server with the installed application level firewall configured as the reverse intermediary server with respect to the server with the WebGoat project, we will attack this server.
Figure 1.1
Install ModSecurity as a reverse proxy server in relation to the server with the WebGoat project, for this:
1. Go to “Start-Control Panel-Network Connections”. On the connection "Local Area Connection", you must right-click, then "Properties". Select “Internet Protocol (TCP / IP)” and set the IP address 192.168.10.2, mask 255.255.255.0.
2. Consider the universal option of using ModSecurity as a reverse proxy server. To use the Apache server as a reverse proxy server, you must enable support for the following modules:
1) mod_unique_id (included with Apache);
2) mod_proxy (included with Apache);
3) mod_proxy_http (part of Apache);
4) mod_proxy_balancer (part of Apache);
5) mod_proxy_html (not included with Apache).
Install Microsoft Visual C ++ 2008 (x86). To do this, run vcredist_x86 (2008) .exe and follow the instructions of the installation wizard. Next, unpack the file httpd-2.2.21-win32-x86-ssl.zip into the folder C: \ Apache2. These distributions can be downloaded from relevant sources [5, 6].
3. Install the Apache server as a service of the operating system. To do this, at the command prompt, type: c: \ Apache2 \ bin \ httpd.exe -k install
4. Run ApacheMonitor (C: \ Apache2 \ bin \ ApacheMonitor.exe).
Unpack the archives with the libxml2.dll library and the mod_proxy_html module into the c: \ Apache2 \ modules \ folder (these archive files can be downloaded from the appropriate sources [6])
5. Configure the Apache Web server to work as a reverse proxy server. To do this, edit the configuration file c: \ Apache2 \ conf \ httpd.conf according to the listing below:
ThreadsPerChild 250
MaxRequestsPerChild 0
ServerRoot "c: / Apache2"
Listen 80
LoadFile C: \ apache2 \ modules \ libxml2.dll
LoadModule proxy_module modules / mod_proxy .so
the LoadModule proxy_balancer_module the modules / mod_proxy_balancer.so
the LoadModule proxy_http_module the modules / mod_proxy_http.so
the LoadModule unique_id_module the modules / mod_unique_id.so
the LoadModule proxy_html_module the modules / mod_proxy_html.so
ProxyRequests Off
the ProxyPass / 192.168.10.1
ProxyPassReverse / 192.168.10.1
ServerName localhost: 80
ErrorLog logs / error_log
LogLevel warn
6. In the configuration file, we are interested in the following parameters:
Listen 80 - the port that the Web service will use to receive HTTP requests from clients;
ProxyRequests Off - disables the normal proxy mode;
ProxyPass and ProxyPassReverse, designed to redirect requests to another Web server.
In general terms, the ProxyPass and ProxyPassReverse directives have the following syntax:
ProxyPass <relative address on the proxy server> <Web server address for redirection>.
7. Let's try to run our proxy server: open ApacheMonitor and click Start.
If the proxy server was launched successfully, then when accessing it via HTTP, the web page of the protected Web server should be displayed.
After setting up and checking the proxy server, we will install ModSecurity directly. First, stop the running Apache service (via ApacheMonitor). From the mod_security-2.6.2-win32.zip archive, unpack the mod_security2.so file in the c: \ Apache2 \ modules \ folder (this archive can be downloaded from the appropriate sources [6]).
8. To work with the ModSecurity module, you need to make some changes to the Apache configuration file, namely add the following line: LoadModule security2_module modules / mod_security2.so
9. Unzip the archive with the latest rules for ModSecurity modsecurity-crs_2.2.2.zip (this archive can be downloaded from the appropriate source [7]) copy the entire rules folder from the archive to c: \ Apache2 \ conf \ rules
10. Add configuration files rules in the httpd.conf configuration file using the following commands:
include c: \ Apache2 \ conf \ rules \ base_rules \ *. conf
include c: \ Apache2 \ conf \ rules \ slr_rules \ *. conf
include c: \ Apache2 \ conf \ rules \ *. conf
11. The folder c: \ Apache2 \ conf \ rules \ contains the configuration file modsecurity_crs_10_config.conf with the basic settings of the ModSecurity module.
Delete the basic settings. Indicate the list of default actions for logging each rule for which compliance is performed, and the request will be interrupted with the 404 status code using the SecDefaultAction command “phase: 2, deny, log, status: 404”
12. Turn on filtering using the SecRuleEngine On
13 command . Enable scanning of the request body and response body using the SecRequestBodyAccess On and SecResponseBodyAccess On
14 commands . Hide the server identifier with the SecServerSignature Apache / 2.2.4 (Fedora) command
15. Specify the folder for downloading tmp files using the SecUploadDir / tmp
16 command . Turn on support cookie version 1 using the command SecCookieFormat 1
17. Specify the parameters for the typical event logging configuration:
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^ (?: 5 | 4 \ d [^ 4])"
SecAuditLogType Concurrent
SecAuditLogParts ABCDEFHZ
SecAuditLogStorageDir logs / data /
SecAudogLogc.Log / SecAudogLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log
| exe bin / mlogc.conf "
18. Add commands to the configuration file modsecurity_crs_10_config.conf so that in the end they correspond to Figure 1.2.
Figure 1.2 - Configuration file modsecurity_crs_10_config.conf
19. Start the Apache server (using ApacheMonitor). As a result, we got a working proxy server that allows you to protect the selected Web server from a number of attacks.
Let's deploy the server with the WebGoat project, for this:
1. Go to the "Start-up-Control Panel-Network Connections". On the connection "Local Area Connection", you must right-click, then "Properties". Select “Internet Protocol (TCP / IP)” and set the IP address 192.168.10.1, mask 255.255.255.0.
2. Install the Java Runtime Environment (JRE) distribution. During installation, leave all the default settings
3. Unzip the WebGoat-OWASP_Standard-5.3_RC1.7z archive into the folder “C: \ WebGoat-5.3_RC1”
4. Open the configuration file located at the address “C: \ WebGoat-5.3_RC1 \ tomcat \ conf \ server_80.xml "and edit the settings for connecting external IP addresses as follows (see Figure 1.3):
Connector address =" 127.0.0.1,192.168.10.1,192.168.10.2, 192.168.10.5 "
5. Open the directory “C: \ WebGoat-5.3_RC1” and run the file “webgoat.bat”
Figure 1.3 - Editing the configuration file server_80.xml
To test the operation of ModSecurity, you can use any of the security scanners that can check web service vulnerabilities. We will use the Acunetix Web Vulnerability Scanner.
Acunetix Web Vulnerability Scanner automates the task of monitoring the security of Web applications and allows you to identify vulnerabilities in the protection of a Web site before it is detected and used by an attacker.
Acunetix Web Vulnerability Scanner (WVS) works as follows:
1) Acunetix WVS examines and forms the site structure, processing all found links and collecting information about all detected files;
2) then the program tests all Web pages with elements for data entry, simulating data entry using all possible combinations and analyzing the results;
3) upon detection of a vulnerability, Acunetix WVS issues an appropriate warning that contains a description of the vulnerability and recommendations for its elimination;
4) the final WVS report can be written to a file for further analysis and comparison with the results of previous checks.
Acunetix Web Vulnerability Scanner automatically detects the following vulnerabilities:
1) Cross site scripting (execution of a malicious script in the user's browser when accessing and in the security context of a trusted site);
2) SQL injection (executing SQL queries from the browser to obtain unauthorized access to data);
3) GHDB database (Google hacking database) - a list of typical queries used by hackers to gain unauthorized access to Web applications and sites.
4) code execution;
5) directory traversal;
6) insertion of files (File inclusion);
7) disclosure of the source text of the script;
8) CRLF injection
9) Cross frame scripting;
10) publicly available backups of files and folders;
11) files and folders containing important information;
12) files that may contain information necessary for conducting attacks (system logs, application tracing logs, etc.);
13) files containing lists of folders;
14) a folder with a low level of protection that allows you to create, modify or delete files.
It also identifies the server technologies involved (WebDAV, FrontPage, etc.) and the permission to use potentially dangerous http-methods (PUT, TRACE, DELETE).
Acunetix Web Vulnerability Scanner is installed on the main machine, which acts as a scanning station. To test the operation of the application-level firewall, first we test for Web vulnerabilities in the Web server with the WebGoat project installed (with the IP address 192.168.10.1), and then scan the server (with the IP address 192.168.10.2), with Apache and ModSecurity installed acting as a reverse proxy server with respect to the WebGoat server.
12) Launch Acunetix Web Vulnerability Scanner. Perform a scan, for this click “File-> New-> Web Site Scan”, in the dialog box that appears, specify “Scan Single Website” and the server address (WebSite URL) “http://192.168.10.1/webgoat/attack”. We leave all the default settings, except for the “Login” item (specify the guest login and password in the “HTTP authentication” parameter). After completing all the settings, the scanner will automatically begin testing the specified node.
13) Similarly, scan a Web server with ModSecurity installed.
Figure 1.4 - Results of scanning a server with an installed WebGoat project
Figure 1.5 - Results of scanning a server with an installed ModSecurity project, working as a reverse proxy server in relation to a server with a WebGoat project.
A project designed to study web vulnerabilities (i.e., typical web vulnerabilities were originally built in it). It is noteworthy that it is developing as part of the OWASP (Open Web Application Security Project) project, under the auspices of which a large number of security utilities are being released. This code is written in Java. For hosting J2EE applications, a standard TomCat server is used - fortunately, it is already included in the WebGoat assembly and configured so that it can be launched as simply as possible.
Assignments are usually tied to a real problem. For example, in one of the quests it is proposed to conduct SQL-injection in order to steal a list of fake credit numbers. Some tasks are accompanied by a training component, showing the user useful hints and vulnerable code.
This project is availableat this address .
1. Yaremchuk S. How to increase the security of web applications // System Administrator. 2006. No2.
2. Ristic I. Securing Web applications using Apache and ModSecurity // www.securitylab.ru/analytics/216322.php .
3. Yudin A. Application protection using ModSecurity // Windows IT Pro. 2007. No 05.
4. Hot ideas: Filtering proxy // jthotblog.blogspot.com/2009/07/blog-post.html .2009.
5. According to the Microsoft website www.microsoft.com
6. According to the website of Stefan Land www.apachelounge.com
7. Based on the materials of the site, The Open Web Application Security Project (OWASP) www.owasp.org
PS: ModSecurity command settings and syntax are described in detail in Magnus Mischel’s book “ModSecurity 2.5. Securing your Apache installation and web applications” (England: Published by Packt Publishing, 2009. 280 c).
1. Modsecurity web application layer firewall
1.1 ModSecurity Project
ModSecurity was created by Ivan Ristic in 2003 and is a firewall of Web applications that can be used as a module of the Apache web server, or work offline and protect Web applications from both known and unknown attacks. Its use is transparent, both installation and uninstallation do not require changing service settings and network topology. In addition, when a vulnerability is detected, it is no longer necessary to hastily change the source code, making new errors, at first it’s enough to add a new rule prohibiting a harmful combination. Modsecurity can protect several Web servers at the same time, including non-Apache [1].
In addition to regular connections, it can also control secure SSL traffic. Flexible logging rules allow you to record any session data, allowing you to completely parse requests prior to hacking in the future. Understanding the HTTP protocol allows you to perform very fine filtering; it supports both GET and POST methods, and requests for dynamic resources. To deal with various methods of evasion (links to external sites, encoded URLs, the use of several slashes, zero bytes, etc.), the paths and parameters are normalized. In the new version, it is possible to inherit rules, a new audit log format is used, which allows for real-time audit. In addition, this version introduces a new mechanism called guardian, whose task is to control requests made from one address, which allows you to protect yourself from DOS attacks by configuring iptables rules. ClamAV antivirus integration with Open Source makes it possible to scan downloaded files for viruses. The version adds PCRE support, which can now be used instead of the regex library for Apache. The amount of code compared to the previous version increased by 40%. ModSecurity is distributed under a dual license: the GNU GPL, as a free Open Source application, several options for end-user and OEM commercial licenses are also available [1].
1.2 ModSecurity Installation Options
a) Installation directly on the web server.
b) Installation as a reverse proxy server (Reverse Proxy).
I must say that ModSecurity is used only with Apache Web servers, preferably version 2.x. Apache server can run both under Linux / UNIX and under Windows (http://httpd.apache.org). The ModSecurity module was originally created under Linux / UNIX (http://www.modsecurity.org), but thanks to the work of Stefan Land, it was successfully ported to Microsoft Windows (http://www.apachelounge.com). Compare the difference between installing ModSecurity directly on a Web server and installing it as a reverse proxy [3].
In the first case, ModSecurity intercepts all requests to the Web server on which it is installed: the request from the client is first compared with the filter rules of the ModSecurity module, and then it is passed to the Web server for further processing. ModSecurity can also control Web server responses, i.e. after the formation of the page, the response is processed by the module and, in accordance with the rules, blocks or allows the passage of the response of the Web server. The latter option can be used to replace pages with Web application errors that result from Web server processing requests from the client with standard pages (for example, 404 error pages). This will reduce the amount of critical information transmitted to the client about the operation of the application and complicate the task of a potential attacker [3].
This installation option is limited to using Apache as a Web server and cannot be used to protect other Web servers.
Installing Apache with the ModSecurity module as a reverse proxy server allows you to intercept client requests for Web servers deployed on any platform (IIS, Apache, WebSphere, etc.). The principle of the reverse proxy server is that the server redirects all requests from clients to the Web server and redirects it to the client when a response is received. Clients “see” only the external interface of the proxy server and “do not see” the Web servers located behind it. In this case, the disadvantages are the need to purchase additional equipment for the proxy server and the presence of a single point of failure for one or more Web servers. However, the proxy server itself can perform additional useful functions, such as caching static requests and balancing the load on a group of Web servers [3].
1.3 Functionality and Benefits of ModSecurity
Here are some of the key features provided by ModSecurity.
a) Analysis of the request. This is the main function of this module, especially when you deal with POST requests, in which obtaining the request body can be difficult [2].
b) Performing canonization and anti-evasion functions. Perform a series of transformations to convert the input data into a form suitable for analysis. This step is used to combat various dodging techniques.
c) Performing special built-in checks. At this point, more complex validations are performed, such as validating URL encodings and validating Unicode encodings. You can also control some byte values in a request to combat shellcode.
d) Launching input rules. At this point, the rules you created are triggered. They allow you to parse every aspect of the query using regular expressions. Also, several rules can be combined here for a more complex analysis [2].
Then the request reaches the handler. After the request, the following actions are performed.
a) Launching inference rules. Inference rules apply to the response body. They are very useful for preventing information leaks [2].
b) Registration of the request. The final request is made up of the request body and input and output headers. To prevent excessive registration, ModSecurity can register optional requests, for example, requests that have received a response from ModSecurity [2].
The benefits of ModSecurity are as follows.
1) Free.
2) Open source.
3) Filters both outgoing and incoming data.
4) A convenient language for writing filtering rules, based on regular expression checking.
5) Integration with Apache proxy modules, which optimally accelerates the work of the Web server (loadbalancing).
6) A graphical shell for writing safety rules (REMO) [4].
ModSecurity on the Habr:
1) Beta version of modSecurity for Nginx
2) Protection of the Apache web server from a slow read attack, as well as some other targeted attacks
2. Server protection using WAF ModSecurity
Figure 1.1 shows a diagram of the practical implementation of the attacking effect on a protected ModSecurity server with the Webgoat project (this project is discussed in more detail at the end of the article). An attacker using specialized software (MS Internet Explorer browser, WebScarab proxy server, Acunetix WVS 6 scanner) will attack a Web server with a pre-installed WebGoat project. In the future, the operation scheme will be changed - after the appropriate configuration of the Web server with the installed application level firewall configured as the reverse intermediary server with respect to the server with the WebGoat project, we will attack this server.
Figure 1.1
2.1 Windows Server 2003 OS Configuration Guide (ModSecurity)
Install ModSecurity as a reverse proxy server in relation to the server with the WebGoat project, for this:
1. Go to “Start-Control Panel-Network Connections”. On the connection "Local Area Connection", you must right-click, then "Properties". Select “Internet Protocol (TCP / IP)” and set the IP address 192.168.10.2, mask 255.255.255.0.
2. Consider the universal option of using ModSecurity as a reverse proxy server. To use the Apache server as a reverse proxy server, you must enable support for the following modules:
1) mod_unique_id (included with Apache);
2) mod_proxy (included with Apache);
3) mod_proxy_http (part of Apache);
4) mod_proxy_balancer (part of Apache);
5) mod_proxy_html (not included with Apache).
Install Microsoft Visual C ++ 2008 (x86). To do this, run vcredist_x86 (2008) .exe and follow the instructions of the installation wizard. Next, unpack the file httpd-2.2.21-win32-x86-ssl.zip into the folder C: \ Apache2. These distributions can be downloaded from relevant sources [5, 6].
3. Install the Apache server as a service of the operating system. To do this, at the command prompt, type: c: \ Apache2 \ bin \ httpd.exe -k install
4. Run ApacheMonitor (C: \ Apache2 \ bin \ ApacheMonitor.exe).
Unpack the archives with the libxml2.dll library and the mod_proxy_html module into the c: \ Apache2 \ modules \ folder (these archive files can be downloaded from the appropriate sources [6])
5. Configure the Apache Web server to work as a reverse proxy server. To do this, edit the configuration file c: \ Apache2 \ conf \ httpd.conf according to the listing below:
ThreadsPerChild 250
MaxRequestsPerChild 0
ServerRoot "c: / Apache2"
Listen 80
LoadFile C: \ apache2 \ modules \ libxml2.dll
LoadModule proxy_module modules / mod_proxy .so
the LoadModule proxy_balancer_module the modules / mod_proxy_balancer.so
the LoadModule proxy_http_module the modules / mod_proxy_http.so
the LoadModule unique_id_module the modules / mod_unique_id.so
the LoadModule proxy_html_module the modules / mod_proxy_html.so
ProxyRequests Off
the ProxyPass / 192.168.10.1
ProxyPassReverse / 192.168.10.1
ServerName localhost: 80
ErrorLog logs / error_log
LogLevel warn
6. In the configuration file, we are interested in the following parameters:
Listen 80 - the port that the Web service will use to receive HTTP requests from clients;
ProxyRequests Off - disables the normal proxy mode;
ProxyPass and ProxyPassReverse, designed to redirect requests to another Web server.
In general terms, the ProxyPass and ProxyPassReverse directives have the following syntax:
ProxyPass <relative address on the proxy server> <Web server address for redirection>.
7. Let's try to run our proxy server: open ApacheMonitor and click Start.
If the proxy server was launched successfully, then when accessing it via HTTP, the web page of the protected Web server should be displayed.
After setting up and checking the proxy server, we will install ModSecurity directly. First, stop the running Apache service (via ApacheMonitor). From the mod_security-2.6.2-win32.zip archive, unpack the mod_security2.so file in the c: \ Apache2 \ modules \ folder (this archive can be downloaded from the appropriate sources [6]).
8. To work with the ModSecurity module, you need to make some changes to the Apache configuration file, namely add the following line: LoadModule security2_module modules / mod_security2.so
9. Unzip the archive with the latest rules for ModSecurity modsecurity-crs_2.2.2.zip (this archive can be downloaded from the appropriate source [7]) copy the entire rules folder from the archive to c: \ Apache2 \ conf \ rules
10. Add configuration files rules in the httpd.conf configuration file using the following commands:
include c: \ Apache2 \ conf \ rules \ base_rules \ *. conf
include c: \ Apache2 \ conf \ rules \ slr_rules \ *. conf
include c: \ Apache2 \ conf \ rules \ *. conf
11. The folder c: \ Apache2 \ conf \ rules \ contains the configuration file modsecurity_crs_10_config.conf with the basic settings of the ModSecurity module.
Delete the basic settings. Indicate the list of default actions for logging each rule for which compliance is performed, and the request will be interrupted with the 404 status code using the SecDefaultAction command “phase: 2, deny, log, status: 404”
12. Turn on filtering using the SecRuleEngine On
13 command . Enable scanning of the request body and response body using the SecRequestBodyAccess On and SecResponseBodyAccess On
14 commands . Hide the server identifier with the SecServerSignature Apache / 2.2.4 (Fedora) command
15. Specify the folder for downloading tmp files using the SecUploadDir / tmp
16 command . Turn on support cookie version 1 using the command SecCookieFormat 1
17. Specify the parameters for the typical event logging configuration:
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^ (?: 5 | 4 \ d [^ 4])"
SecAuditLogType Concurrent
SecAuditLogParts ABCDEFHZ
SecAuditLogStorageDir logs / data /
SecAudogLogc.Log / SecAudogLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log / SecAuditLogc.Log
| exe bin / mlogc.conf "
18. Add commands to the configuration file modsecurity_crs_10_config.conf so that in the end they correspond to Figure 1.2.
Figure 1.2 - Configuration file modsecurity_crs_10_config.conf
19. Start the Apache server (using ApacheMonitor). As a result, we got a working proxy server that allows you to protect the selected Web server from a number of attacks.
2.2 Windows Server 2003 OS Setup Guide (WebGoat)
Let's deploy the server with the WebGoat project, for this:
1. Go to the "Start-up-Control Panel-Network Connections". On the connection "Local Area Connection", you must right-click, then "Properties". Select “Internet Protocol (TCP / IP)” and set the IP address 192.168.10.1, mask 255.255.255.0.
2. Install the Java Runtime Environment (JRE) distribution. During installation, leave all the default settings
3. Unzip the WebGoat-OWASP_Standard-5.3_RC1.7z archive into the folder “C: \ WebGoat-5.3_RC1”
4. Open the configuration file located at the address “C: \ WebGoat-5.3_RC1 \ tomcat \ conf \ server_80.xml "and edit the settings for connecting external IP addresses as follows (see Figure 1.3):
Connector address =" 127.0.0.1,192.168.10.1,192.168.10.2, 192.168.10.5 "
5. Open the directory “C: \ WebGoat-5.3_RC1” and run the file “webgoat.bat”
Figure 1.3 - Editing the configuration file server_80.xml
2.3 Generation of attack
To test the operation of ModSecurity, you can use any of the security scanners that can check web service vulnerabilities. We will use the Acunetix Web Vulnerability Scanner.
Acunetix Web Vulnerability Scanner automates the task of monitoring the security of Web applications and allows you to identify vulnerabilities in the protection of a Web site before it is detected and used by an attacker.
Acunetix Web Vulnerability Scanner (WVS) works as follows:
1) Acunetix WVS examines and forms the site structure, processing all found links and collecting information about all detected files;
2) then the program tests all Web pages with elements for data entry, simulating data entry using all possible combinations and analyzing the results;
3) upon detection of a vulnerability, Acunetix WVS issues an appropriate warning that contains a description of the vulnerability and recommendations for its elimination;
4) the final WVS report can be written to a file for further analysis and comparison with the results of previous checks.
Acunetix Web Vulnerability Scanner automatically detects the following vulnerabilities:
1) Cross site scripting (execution of a malicious script in the user's browser when accessing and in the security context of a trusted site);
2) SQL injection (executing SQL queries from the browser to obtain unauthorized access to data);
3) GHDB database (Google hacking database) - a list of typical queries used by hackers to gain unauthorized access to Web applications and sites.
4) code execution;
5) directory traversal;
6) insertion of files (File inclusion);
7) disclosure of the source text of the script;
8) CRLF injection
9) Cross frame scripting;
10) publicly available backups of files and folders;
11) files and folders containing important information;
12) files that may contain information necessary for conducting attacks (system logs, application tracing logs, etc.);
13) files containing lists of folders;
14) a folder with a low level of protection that allows you to create, modify or delete files.
It also identifies the server technologies involved (WebDAV, FrontPage, etc.) and the permission to use potentially dangerous http-methods (PUT, TRACE, DELETE).
Acunetix Web Vulnerability Scanner is installed on the main machine, which acts as a scanning station. To test the operation of the application-level firewall, first we test for Web vulnerabilities in the Web server with the WebGoat project installed (with the IP address 192.168.10.1), and then scan the server (with the IP address 192.168.10.2), with Apache and ModSecurity installed acting as a reverse proxy server with respect to the WebGoat server.
12) Launch Acunetix Web Vulnerability Scanner. Perform a scan, for this click “File-> New-> Web Site Scan”, in the dialog box that appears, specify “Scan Single Website” and the server address (WebSite URL) “http://192.168.10.1/webgoat/attack”. We leave all the default settings, except for the “Login” item (specify the guest login and password in the “HTTP authentication” parameter). After completing all the settings, the scanner will automatically begin testing the specified node.
13) Similarly, scan a Web server with ModSecurity installed.
Figure 1.4 - Results of scanning a server with an installed WebGoat project
Figure 1.5 - Results of scanning a server with an installed ModSecurity project, working as a reverse proxy server in relation to a server with a WebGoat project.
OWASP WebGoat Project
A project designed to study web vulnerabilities (i.e., typical web vulnerabilities were originally built in it). It is noteworthy that it is developing as part of the OWASP (Open Web Application Security Project) project, under the auspices of which a large number of security utilities are being released. This code is written in Java. For hosting J2EE applications, a standard TomCat server is used - fortunately, it is already included in the WebGoat assembly and configured so that it can be launched as simply as possible.
Assignments are usually tied to a real problem. For example, in one of the quests it is proposed to conduct SQL-injection in order to steal a list of fake credit numbers. Some tasks are accompanied by a training component, showing the user useful hints and vulnerable code.
This project is availableat this address .
List of sources used
1. Yaremchuk S. How to increase the security of web applications // System Administrator. 2006. No2.
2. Ristic I. Securing Web applications using Apache and ModSecurity // www.securitylab.ru/analytics/216322.php .
3. Yudin A. Application protection using ModSecurity // Windows IT Pro. 2007. No 05.
4. Hot ideas: Filtering proxy // jthotblog.blogspot.com/2009/07/blog-post.html .2009.
5. According to the Microsoft website www.microsoft.com
6. According to the website of Stefan Land www.apachelounge.com
7. Based on the materials of the site, The Open Web Application Security Project (OWASP) www.owasp.org
PS: ModSecurity command settings and syntax are described in detail in Magnus Mischel’s book “ModSecurity 2.5. Securing your Apache installation and web applications” (England: Published by Packt Publishing, 2009. 280 c).