Web Application Firewall (ModSecurity) in action
Attacks on the level of web applications are one of the most common and often extremely critical. In this article I want to show how capable WAF ModSecurity is to repel these threats.
ModSecurity was created by Ivan Ristic (Ivan Ristic) in 2003 and is a Web application firewall that can be used as an Apache web server module, or work offline and allows you to protect Web applications from both known and unknown attacks. Its use is transparent, both installation and removal does not require changing the settings of services and network topology. In addition, when a vulnerability is detected, it is no longer necessary to change the source code in a hurry, making new mistakes; it is enough to add a new rule at first, prohibiting a harmful combination. Modsecurity can simultaneously protect multiple Web servers, including non-Apache [1].
In addition to normal connections, you can control SSL-protected traffic. The gibkozadavayemy journaling rules allow you to record any session data, allowing in the future to fully parse the requests prior to hacking. Understanding the HTTP protocol allows for very fine filtering, it supports both GET and POST methods, requests for dynamic resources. To combat various avoidance methods (links to external sites, URLs encoded, using multiple slashes, zero bytes, etc.), paths and parameters are normalized. In the new version, the rules may be inherited, a new audit trail format is used, which allows for auditing in real time. In addition, this version introduces a new mechanism called the guardian, whose task is to control requests made from a single address, which helps protect against DOS attacks by setting up iptables rules. Integration with the Open Source antivirus ClamAV allows you to scan downloaded files for viruses. The version adds support for PCRE, which can now be used instead of the Apache regex library. 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 end-user and OEM commercial licenses are also available [1].
')
There are two typical options for installing ModSecurity [3].
a) Install directly on a web server.
b) Installation as a reverse proxy server (Reverse Proxy).
I must say that ModSecurity is used only with Apache Web servers, preferably versions 2.x. Apache server can work 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, he was successfully ported to Microsoft Windows (http://www.apachelounge.com). Let's compare how the installation of ModSecurity directly on the Web server differs from the installation 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 filtering rules of the ModSecurity module, and then passed to the Web server for further processing. ModSecurity can also monitor Web server responses, i.e. After the page is formed, the response is processed by the module and, in accordance with the rules, blocks or allows the Web server to respond. The latter option can be used to replace pages with Web application errors resulting from the Web server processing requests from the client to standard pages (for example, pages with error 404). This will reduce the amount of critical information transmitted to the client about the operation of the application and will 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 to Web servers deployed on any platform (IIS, Apache, WebSphere, etc.). The principle of operation of the reverse proxy server is that the server forwards all requests from clients to the Web server and, when receiving a response, forwards it to the client. 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 a proxy server and the presence of a single point of failure for one or several Web servers. However, the proxy server itself can perform additional useful functions, such as caching static requests and load balancing on a group of Web servers [3].
Here are a few of the main features provided by the ModSecurity module.
a) Analysis of the request. This is the main function of this module, especially when you are dealing with POST requests, in which the retrieval of the request body can be difficult [2].
b) Performing canonization and anti-inclination function. Perform a series of transformations to convert the input data into a form suitable for analysis. This step is used to combat various evasion methods.
c) Performing special built-in checks. At this point, more sophisticated validation checks are performed, such as URL encoding validation and Unicode encoding validation. You can also control some of the byte values ​​in the request to deal with shellcode.
d) Run input rules. This is where the rules you create are run. They allow you to analyze every aspect of a query using regular expressions. Also here can be combined several rules for more complex analysis [2].
The request then reaches the handler. After the request, downstream actions are performed.
a) Run inference rules. Inference rules apply to the response body. They are very useful in preventing information leaks [2].
b) Registration request. The final request is logged, consisting of the request body and the input and output headers. In order to prevent excessive registration, ModSecurity can register requests of choice, for example, requests that received a response from ModSecurity [2].
The advantages of ModSecurity are as follows.
1) Free.
2) Open source codes.
3) Filters both outgoing and incoming data.
4) Convenient language for writing filtering rules based on regular expression checking.
5) Integration with Apache proxy modules, which allows you to optimally speed up the Web-server (loadbalancing).
6) A graphical shell for writing security rules (REMO) [4].
ModSecurity on Habré:
1) Beta version of modSecurity for Nginx
2) Protecting the Apache web server from a slow-reading attack, as well as some other directed attacks
Figure 1.1 shows a diagram of the practical implementation of an attacking impact on a protected ModSecurity server with a Webgoat project (this project is discussed in more detail at the end of the article). Attacking with the help of specialized software (MS Internet Explorer browser, WebScarab proxy server, Acunetix WVS 6 scanner) will attack a Web server with a pre-installed WebGoat project. Subsequently, the operation scheme will be changed - after the corresponding configuration of the Web server with the installed application-level firewall configured as a reverse proxy server in relation to the server with the WebGoat project, we will attack this server.
Figure 1.1
Install ModSecurity as a reverse proxy server with respect to the server with the WebGoat project, for this:
1. Go to the "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 use of ModSecurity as a reverse proxy server (Reverse Proxy). For the Apache server to function as a reverse proxy server, you must enable support for the following modules:
1) mod_unique_id (included in Apache);
2) mod_proxy (included in Apache);
3) mod_proxy_http (included in Apache);
4) mod_proxy_balancer (included in Apache);
5) mod_proxy_html (not included in 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 in the C: \ Apache2 folder. These distributions can be downloaded from relevant sources [5, 6].
3. Install the Apache server as an operating system service. To do this, type the following in the command line: c: \ Apache2 \ bin \ httpd.exe -k install
4. Run ApacheMonitor (C: \ Apache2 \ bin \ ApacheMonitor.exe).
Unpack the archives with the library libxml2.dll and the mod_proxy_html module in the c: \ Apache2 \ modules \ folder (these archive files can be downloaded from the corresponding 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 in accordance with 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
LoadModule proxy_balancer_module modules / mod_proxy_balancer.so
LoadModule proxy_http_module modules / mod_proxy_http.so
LoadModule unique_id_module modules / mod_unique_id.so
LoadModule proxy_html_module modules / mod_proxy_html.so
ProxyRequests Off
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 is the port that the Web service will use to receive HTTP requests from clients;
ProxyRequests Off - disable proxy mode;
ProxyPass and ProxyPassReverse, designed to redirect requests to another Web-server.
In general, the ProxyPass and ProxyPassReverse directives have the following syntax:
ProxyPass <relative proxy server address> <web server address for redirection>.
7. Let's try to start 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 performance of 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, we unpack the mod_security2.so file into the c: \ Apache2 \ modules \ folder (this archive can be downloaded from relevant 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 version of the rules for ModSecurity modsecurity-crs_2.2.2.zip (you can download this archive from the appropriate source [7]) overwrite the entire rules folder from the archive into the c: \ Apache2 \ conf \ rules folder
10. Add configuration rule files to 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. In the c: \ Apache2 \ conf \ rules \ folder there is a modsecurity_crs_10_config.conf configuration file with the basic settings of the ModSecurity module.
Delete the basic settings. Specify a list of default actions for which every rule that is matched is recorded in the audit logs, and the request will be terminated with a 404 status code using the SecDefaultAction command “phase: 2, deny, log, status: 404”
12. Enable filtering with the SecRuleEngine On command.
13. Enable scanning of the request body and response body using the SecRequestBodyAccess On and SecResponseBodyAccess On commands.
14. Hide the server ID with the SecServerSignature "Apache / 2.2.4 (Fedora)" command.
15. Specify the folder for downloading tmp files using the SecUploadDir / tmp command.
16. Enable support for cookie version 1 using the SecCookieFormat 1 command.
17. Specify the parameters for a typical event logging configuration:
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^ (?: 5 | 4 \ d [^ 4])"
SecAuditLogType Concurrent
SecAuditLogParts ABCDEFHZ
SecAuditLogStorageDir logs / data /
SecAuditLog bin / mlogc.exe
SecAuditLog "| bin / mlogc.exe bin / mlogc.conf"
18. Add commands to the modsecurity_crs_10_config.conf configuration file so that they end up with 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, allowing to protect the selected Web-server from a series of attacks.
Let's deploy the server with the WebGoat project, for this:
1. Go to the Start-Panel Controls-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. In the installation process, leave all the default settings
3. Unzip the archive WebGoat-OWASP_Standard-5.3_RC1.7z in the folder "C: \ WebGoat-5.3_RC1"
4. Open the configuration file located at the address “: \ 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 server_80.xml configuration file
To test the operation of ModSecurity, you can use any of the security scanners that can check the vulnerabilities of web services. We use 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 they are detected and used by an attacker.
Acunetix Web Vulnerability Scanner (WVS) works as follows:
1) Acunetix WVS examines and forms the structure of the site, processing all found links and collecting information about all detected files;
2) the program then tests all Web pages with data entry elements, simulating data entry using all possible combinations and analyzing the results obtained;
3) detecting a vulnerability, Acunetix WVS issues a corresponding warning, which 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 (execution of SQL queries from the browser to obtain unauthorized access to data);
3) GHDB database (Google hacking database) - a list of typical requests used by hackers to gain unauthorized access to a Web application and sites.
4) code execution;
5) directory traversal;
6) file insertion (File inclusion);
7) disclosure of the source text of the script;
8) CRLF injection
9) Cross frame scripting;
10) publicly available backup copies of files and folders;
11) files and folders containing important information;
12) files that may contain information necessary for carrying out attacks (system logs, application trace logs, etc.);
13) files containing lists of folders;
14) a folder with a low level of protection, allowing 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 acting as a scanning station. To test the application-level firewall, we first test for the presence of Web vulnerabilities a Web server with an installed WebGoat project (with an IP address of 192.168.10.1), and then scan the server (with an IP address of 192.168.10.2), with Apache and ModSecurity installed acting as a reverse proxy server with respect to the WebGoat server.
12) Run Acunetix Web Vulnerability Scanner. Perform a scan, to do this, click "File-> New-> Web Site Scan", in the dialog box that appears, select "Scan Single Website" and the server address (WebSite URL) "http://192.168.10.1/webgoat/attack". We leave all the default settings, except the “Login” item (specify the guest login and password in the “HTTP authentication” parameter) After all the settings are completed, the scanner will automatically start testing the specified node.
13) Similarly, scan the Web server with ModSecurity installed.
Figure 1.4 - Server scan results with the installed WebGoat project
Figure 1.5 - Server scan results with the installed ModSecurity project, working as a reverse proxy server with respect to the server with the WebGoat project.
The project is designed to study web-vulnerabilities (ie, it initially laid the typical web-vulnerabilities). It is remarkable that it develops within the framework of the OWASP project (Open Web Application Security Project), under the auspices of which a large number of security utilities are released. This code is written in Java. A standard TomCat server is used to host J2EE applications — fortunately, it is already included in the WebGoat assembly and configured so that it can be started as easily as possible.
Tasks 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 the list of fake credit numbers. Some tasks are accompanied by a training component that shows useful tips and vulnerable code to the user.
This project is available at this address .
1. Yaremchuk S. How to improve the security of web applications // System administrator. 2006. â„–2.
2. Ristik I. Protecting Web Applications with Apache and ModSecurity // www.securitylab.ru/analytics/216322.php .
3. Yudin A. Protection of applications using ModSecurity // Windows IT Pro. 2007. â„– 05.
4. Hot ideas: Filtering proxies // jthotblog.blogspot.com/2009/07/blog-post.html .2009.
5. According to the Microsoft website www.microsoft.com
6. According to the website of Stephen Land www.apachelounge.com
7. Based on materials from the site organization The Open Web Application Security Project (OWASP) www.owasp.org
PS: The settings and syntax of the ModSecurity commands are described in detail in the Magnus Mischel book “ModSecurity 2.5.Securing your Apache installation and web applications” (England: Published by Packt Publishing, 2009. 280 c).
1. Firewall-level web applications Modsecurity
1.1 Project ModSecurity
ModSecurity was created by Ivan Ristic (Ivan Ristic) in 2003 and is a Web application firewall that can be used as an Apache web server module, or work offline and allows you to protect Web applications from both known and unknown attacks. Its use is transparent, both installation and removal does not require changing the settings of services and network topology. In addition, when a vulnerability is detected, it is no longer necessary to change the source code in a hurry, making new mistakes; it is enough to add a new rule at first, prohibiting a harmful combination. Modsecurity can simultaneously protect multiple Web servers, including non-Apache [1].
In addition to normal connections, you can control SSL-protected traffic. The gibkozadavayemy journaling rules allow you to record any session data, allowing in the future to fully parse the requests prior to hacking. Understanding the HTTP protocol allows for very fine filtering, it supports both GET and POST methods, requests for dynamic resources. To combat various avoidance methods (links to external sites, URLs encoded, using multiple slashes, zero bytes, etc.), paths and parameters are normalized. In the new version, the rules may be inherited, a new audit trail format is used, which allows for auditing in real time. In addition, this version introduces a new mechanism called the guardian, whose task is to control requests made from a single address, which helps protect against DOS attacks by setting up iptables rules. Integration with the Open Source antivirus ClamAV allows you to scan downloaded files for viruses. The version adds support for PCRE, which can now be used instead of the Apache regex library. 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 end-user and OEM commercial licenses are also available [1].
')
1.2 Installation Options ModSecurity
a) Install directly on a web server.
b) Installation as a reverse proxy server (Reverse Proxy).
I must say that ModSecurity is used only with Apache Web servers, preferably versions 2.x. Apache server can work 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, he was successfully ported to Microsoft Windows (http://www.apachelounge.com). Let's compare how the installation of ModSecurity directly on the Web server differs from the installation 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 filtering rules of the ModSecurity module, and then passed to the Web server for further processing. ModSecurity can also monitor Web server responses, i.e. After the page is formed, the response is processed by the module and, in accordance with the rules, blocks or allows the Web server to respond. The latter option can be used to replace pages with Web application errors resulting from the Web server processing requests from the client to standard pages (for example, pages with error 404). This will reduce the amount of critical information transmitted to the client about the operation of the application and will 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 to Web servers deployed on any platform (IIS, Apache, WebSphere, etc.). The principle of operation of the reverse proxy server is that the server forwards all requests from clients to the Web server and, when receiving a response, forwards it to the client. 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 a proxy server and the presence of a single point of failure for one or several Web servers. However, the proxy server itself can perform additional useful functions, such as caching static requests and load balancing on a group of Web servers [3].
1.3 Functionality and advantages of ModSecurity
Here are a few of the main features provided by the ModSecurity module.
a) Analysis of the request. This is the main function of this module, especially when you are dealing with POST requests, in which the retrieval of the request body can be difficult [2].
b) Performing canonization and anti-inclination function. Perform a series of transformations to convert the input data into a form suitable for analysis. This step is used to combat various evasion methods.
c) Performing special built-in checks. At this point, more sophisticated validation checks are performed, such as URL encoding validation and Unicode encoding validation. You can also control some of the byte values ​​in the request to deal with shellcode.
d) Run input rules. This is where the rules you create are run. They allow you to analyze every aspect of a query using regular expressions. Also here can be combined several rules for more complex analysis [2].
The request then reaches the handler. After the request, downstream actions are performed.
a) Run inference rules. Inference rules apply to the response body. They are very useful in preventing information leaks [2].
b) Registration request. The final request is logged, consisting of the request body and the input and output headers. In order to prevent excessive registration, ModSecurity can register requests of choice, for example, requests that received a response from ModSecurity [2].
The advantages of ModSecurity are as follows.
1) Free.
2) Open source codes.
3) Filters both outgoing and incoming data.
4) Convenient language for writing filtering rules based on regular expression checking.
5) Integration with Apache proxy modules, which allows you to optimally speed up the Web-server (loadbalancing).
6) A graphical shell for writing security rules (REMO) [4].
ModSecurity on Habré:
1) Beta version of modSecurity for Nginx
2) Protecting the Apache web server from a slow-reading attack, as well as some other directed attacks
2. Server protection with WAF ModSecurity
Figure 1.1 shows a diagram of the practical implementation of an attacking impact on a protected ModSecurity server with a Webgoat project (this project is discussed in more detail at the end of the article). Attacking with the help of specialized software (MS Internet Explorer browser, WebScarab proxy server, Acunetix WVS 6 scanner) will attack a Web server with a pre-installed WebGoat project. Subsequently, the operation scheme will be changed - after the corresponding configuration of the Web server with the installed application-level firewall configured as a reverse proxy server in relation 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 with respect to the server with the WebGoat project, for this:
1. Go to the "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 use of ModSecurity as a reverse proxy server (Reverse Proxy). For the Apache server to function as a reverse proxy server, you must enable support for the following modules:
1) mod_unique_id (included in Apache);
2) mod_proxy (included in Apache);
3) mod_proxy_http (included in Apache);
4) mod_proxy_balancer (included in Apache);
5) mod_proxy_html (not included in 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 in the C: \ Apache2 folder. These distributions can be downloaded from relevant sources [5, 6].
3. Install the Apache server as an operating system service. To do this, type the following in the command line: c: \ Apache2 \ bin \ httpd.exe -k install
4. Run ApacheMonitor (C: \ Apache2 \ bin \ ApacheMonitor.exe).
Unpack the archives with the library libxml2.dll and the mod_proxy_html module in the c: \ Apache2 \ modules \ folder (these archive files can be downloaded from the corresponding 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 in accordance with 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
LoadModule proxy_balancer_module modules / mod_proxy_balancer.so
LoadModule proxy_http_module modules / mod_proxy_http.so
LoadModule unique_id_module modules / mod_unique_id.so
LoadModule proxy_html_module modules / mod_proxy_html.so
ProxyRequests Off
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 is the port that the Web service will use to receive HTTP requests from clients;
ProxyRequests Off - disable proxy mode;
ProxyPass and ProxyPassReverse, designed to redirect requests to another Web-server.
In general, the ProxyPass and ProxyPassReverse directives have the following syntax:
ProxyPass <relative proxy server address> <web server address for redirection>.
7. Let's try to start 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 performance of 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, we unpack the mod_security2.so file into the c: \ Apache2 \ modules \ folder (this archive can be downloaded from relevant 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 version of the rules for ModSecurity modsecurity-crs_2.2.2.zip (you can download this archive from the appropriate source [7]) overwrite the entire rules folder from the archive into the c: \ Apache2 \ conf \ rules folder
10. Add configuration rule files to 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. In the c: \ Apache2 \ conf \ rules \ folder there is a modsecurity_crs_10_config.conf configuration file with the basic settings of the ModSecurity module.
Delete the basic settings. Specify a list of default actions for which every rule that is matched is recorded in the audit logs, and the request will be terminated with a 404 status code using the SecDefaultAction command “phase: 2, deny, log, status: 404”
12. Enable filtering with the SecRuleEngine On command.
13. Enable scanning of the request body and response body using the SecRequestBodyAccess On and SecResponseBodyAccess On commands.
14. Hide the server ID with the SecServerSignature "Apache / 2.2.4 (Fedora)" command.
15. Specify the folder for downloading tmp files using the SecUploadDir / tmp command.
16. Enable support for cookie version 1 using the SecCookieFormat 1 command.
17. Specify the parameters for a typical event logging configuration:
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^ (?: 5 | 4 \ d [^ 4])"
SecAuditLogType Concurrent
SecAuditLogParts ABCDEFHZ
SecAuditLogStorageDir logs / data /
SecAuditLog bin / mlogc.exe
SecAuditLog "| bin / mlogc.exe bin / mlogc.conf"
18. Add commands to the modsecurity_crs_10_config.conf configuration file so that they end up with 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, allowing to protect the selected Web-server from a series of attacks.
2.2 Windows Server 2003 OS Configuration Guide (WebGoat)
Let's deploy the server with the WebGoat project, for this:
1. Go to the Start-Panel Controls-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. In the installation process, leave all the default settings
3. Unzip the archive WebGoat-OWASP_Standard-5.3_RC1.7z in the folder "C: \ WebGoat-5.3_RC1"
4. Open the configuration file located at the address “: \ 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 server_80.xml configuration file
2.3 Generating Attacking Impact
To test the operation of ModSecurity, you can use any of the security scanners that can check the vulnerabilities of web services. We use 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 they are detected and used by an attacker.
Acunetix Web Vulnerability Scanner (WVS) works as follows:
1) Acunetix WVS examines and forms the structure of the site, processing all found links and collecting information about all detected files;
2) the program then tests all Web pages with data entry elements, simulating data entry using all possible combinations and analyzing the results obtained;
3) detecting a vulnerability, Acunetix WVS issues a corresponding warning, which 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 (execution of SQL queries from the browser to obtain unauthorized access to data);
3) GHDB database (Google hacking database) - a list of typical requests used by hackers to gain unauthorized access to a Web application and sites.
4) code execution;
5) directory traversal;
6) file insertion (File inclusion);
7) disclosure of the source text of the script;
8) CRLF injection
9) Cross frame scripting;
10) publicly available backup copies of files and folders;
11) files and folders containing important information;
12) files that may contain information necessary for carrying out attacks (system logs, application trace logs, etc.);
13) files containing lists of folders;
14) a folder with a low level of protection, allowing 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 acting as a scanning station. To test the application-level firewall, we first test for the presence of Web vulnerabilities a Web server with an installed WebGoat project (with an IP address of 192.168.10.1), and then scan the server (with an IP address of 192.168.10.2), with Apache and ModSecurity installed acting as a reverse proxy server with respect to the WebGoat server.
12) Run Acunetix Web Vulnerability Scanner. Perform a scan, to do this, click "File-> New-> Web Site Scan", in the dialog box that appears, select "Scan Single Website" and the server address (WebSite URL) "http://192.168.10.1/webgoat/attack". We leave all the default settings, except the “Login” item (specify the guest login and password in the “HTTP authentication” parameter) After all the settings are completed, the scanner will automatically start testing the specified node.
13) Similarly, scan the Web server with ModSecurity installed.
Figure 1.4 - Server scan results with the installed WebGoat project
Figure 1.5 - Server scan results with the installed ModSecurity project, working as a reverse proxy server with respect to the server with the WebGoat project.
OWASP WebGoat Project
The project is designed to study web-vulnerabilities (ie, it initially laid the typical web-vulnerabilities). It is remarkable that it develops within the framework of the OWASP project (Open Web Application Security Project), under the auspices of which a large number of security utilities are released. This code is written in Java. A standard TomCat server is used to host J2EE applications — fortunately, it is already included in the WebGoat assembly and configured so that it can be started as easily as possible.
Tasks 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 the list of fake credit numbers. Some tasks are accompanied by a training component that shows useful tips and vulnerable code to the user.
This project is available at this address .
List of used sources
1. Yaremchuk S. How to improve the security of web applications // System administrator. 2006. â„–2.
2. Ristik I. Protecting Web Applications with Apache and ModSecurity // www.securitylab.ru/analytics/216322.php .
3. Yudin A. Protection of applications using ModSecurity // Windows IT Pro. 2007. â„– 05.
4. Hot ideas: Filtering proxies // jthotblog.blogspot.com/2009/07/blog-post.html .2009.
5. According to the Microsoft website www.microsoft.com
6. According to the website of Stephen Land www.apachelounge.com
7. Based on materials from the site organization The Open Web Application Security Project (OWASP) www.owasp.org
PS: The settings and syntax of the ModSecurity commands are described in detail in the Magnus Mischel book “ModSecurity 2.5.Securing your Apache installation and web applications” (England: Published by Packt Publishing, 2009. 280 c).
Source: https://habr.com/ru/post/228103/
All Articles