Introduction
Before the start of GSoC 2016; I was not considerably aware about the web application firewalls, especially about their internals and working mechanism. As information security and digital forensics are my core research areas of interest so I have dug up all related organizations in the list and I found ModSecurity most sparking for me. The next phase was to submit a proposal, but before that I was needed to choose a project; I have selected “Apache Connector for libModSecurity” because Apache httpd is the most popular, open source web server, and it is used by more than 50% of internet.
ModSecurity is a web application layer level firewall and libModSecurity is a major rewrite of ModSecurity because ModSecurity version 2.9.0 is available on different platforms, including Apache, IIS and NGINX but it really favors an Apache Deployment. ModSecurity standalone is basically a wrapper that packs requests from different formats into an Apache format, to later be processed by ModSecurity in the same way that it works on an Apache web server. That was certainly the fastest way to have ModSecurity running on different platforms, but at the cost of performance and high amount of dependencies. After splitting the ModSecurity between “connectors” and “core”; the core has been naturally become a library and the connectors become consumers of the library. Hence, ModSecurity core becomes completely independent of the underlying web server and the source code that is required to interact with a given web server is called “connector”. The libModSecurity isn’t feature complete and stable yet and I think that is an edge for student developers like me :)
_Point to Ponder: _As defined above that ModSecurity is most favorable for Apache so the question is why connector for Apache, then? It’s simple because version 3 means more advance and modern than earlier versions in terms of performance and features, ModSecurity will be modular architecture. “Core” and “Connectors” is the future of ModSecurity.
Apache Connector for libModSecurity is a currently under-development Apache module in C programming using:
- libModSecurity
- Apache HTTP Server API
- Apache Portable Runtime Library
- Apache Portable Runtime Utility Library
This module will be basically based on input and output filters, those enables it to process incoming and outgoing data in a highly flexible and configurable manner; pre-processing of incoming data and post-processing of outgoing data at different phases and parts including:
- Request headers
- Request body
- Response headers
- Response body
- Logging
Here are the diagramed representations of input filter/request processing in Figure 1 and output filter/response processing in Figure 2.
Figure 1
Figure 2
Functional Requirements:
Request Processing There are two parts of request processing:
Request Headers Processing Acquire the request headers before any other module access it and hold it until processing completes by libModSecurity. This section of processing can pass same request headers or modified request headers to other modules for further processing or decline the request for any further processing and call the logging function to log the transaction.
Request Body Processing Acquire the request body before any other module access it and hold it until processing completes by libModSecurity. This section of processing can pass same request body or modified request body to other modules for further processing or decline the request for any further processing and call the logging function to log the transaction.
Response Processing There are two parts of response processing:
Response Headers Processing Acquire the response headers after all other modules’ processing and hold it until processing completes by libModSecurity. This section of processing can pass same response headers or modified response headers to the Apache httpd for serving to the client and call the logging function to log the transaction.
Response Body Processing Acquire the response body after all other modules’ processing and hold it until processing completes by libModSecurity. This section of processing can pass same response body or modified response body to the Apache httpd for serving to the client and call the logging function to log the transaction.
Logging Logging of each transaction is also a functional requirement of this project; logging will be done for each successful transaction completion and for each unsuccessful transaction finish.
Nonfunctional Requirements:
Here are the some nonfunctional requirements of this project:
- Open source
- Documentation
- Efficiency & Effectiveness
- Performance & Stability
- Testability & Usability
User Interfaces:
Not Applicable for this project.
Databases Design and Schema:
As for now; according to my understanding, there will not be any need of databases in this project, but if there will be needed for anything related to the database then the Apache database framework will be used. The apr_dbd API provides database operations functionality and ap_dbd API provides database connection management functionality very efficiently and easily.
Source Code Repository:
Installation Guide, Compilation Recipes and Source Code Repository
Current Status
Currently, I have completed body extraction and handling through input and output filters, where I have copied request and response bodies with bucket and bucket brigades for passing them to libModSec for further processing. The source code of request headers and response headers is quite buggy and not working as required.
Considerations, Concerns and Confusions
For headers extraction there are too many options; but we can get those on both input filter and output filter as part of request_rec struct (headers_in and headers_out), I found several functions but no one is looking appropriate to me for libModSec as required by analyzing existing modules.
For process connection there are also too many possibilities; IP address vs host address (client and server) which is also confusing that at which point what thing is needed, IP address or Host address or need to process both with two times use of process connection function.
For configuration, I am also puzzled that what is appropriate or , I think connector should work on whole server that whatever come in and go out needs to process with libModSec.
Acknowledgement
I would like to thanks and best regards to my mentors Chaim Sanders, Felipe Zimmerle, and Robert Paprocki for their concrete support, quick response, patience and trust on me. I also want to thank my fellow mates Akhil Koul and Manish Malik.
Thanks to Google and ModSecurity for providing such a great learning and networking experience.