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 an currently underdevelopment 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 diagramic 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.
Current Status
Currently, I have completed mid term evaluation successfully and I have developed I/O filters and here is the project Github repository.
…Looking forward your precious feedback…
Tahir Ramzan 