ModSecurity 2 Data Formats | Search for a title, author or keyword | ||||||||
ModSecurity 2 Data Formats ModSecurity 2 Data Formats. The purpose of this document is to describe the formats of the ModSecurity alert messages, transaction logs and communication protocols, which would not only allow for a better understanding what ModSecurity does but also for an easy integration with third-party tools and products. ModSecurity™is an open source, free web application firewall ( WAF ) Apache module. With over 70% of all attacks now carried out over the web application level, organizations need all the help they can get in making their systems secure. WAFs are deployed to establish an external security layer that increases security, detects and prevents attacks before they reach web applications. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure. Web servers are typically well-equipped to log traffic in a form useful for marketing analyses, but fall short logging traffic to web applications. In particular, most are not capable of logging the request bodies. Your adversaries know this, and that is why most attacks are now carried out via POST requests, rendering your systems blind. ModSecurity makes full HTTP transaction logging possible, allowing complete requests and responses to be logged. In addition to providing logging facilities, ModSecurity can monitor the HTTP traffic in real time in order to detect attacks. In this case, ModSecurity operates as a web intrusion detection tool, allowing you to react to suspicious events that take place at your web systems. As part of its operations ModSecurity will emit alerts, which are either warnings ( non-fatal ) or errors ( fatal, usually leading to the interception of the transaction in question ). Example: Access denied with code 505 (phase 1). Match of "rx ^HTTP/(0\\\\.9|1\\\\.[01])$" against "REQUEST_PROTOCOL" required. [id "960034"] [msg "HTTP protocol version is not allowed by policy"] [severity "CRITICAL"] [uri "/"] [unique_id "PQaTTVBEUOkAAFwKXrYAAAAM"]. If the alert is only a warning, the first sentence will simply say Warning. If the transaction was intercepted, the first sentence will begin with "Access denied". The second part of the engine message explains why the alert was generated. Since it is automatically generated from the rules it will be very technical in nature, talking about operators and their parameters and give you insight into what the rule looked like. But this message cannot give you insight into the reasoning behind the rule. A well-written rule will always specify a human-readable message ( using the msg action ) to provide further information ( "HTTP protocol version is not allowed by policy" in our example ). The metadata fields ( offset, id, rev, msg, severity, unique_id, uri, logdata ) are always placed at the end of the alert entry. Each metadata field is a text fragment that consists of an open bracket followed by the metadata field name, followed by the value and the closing bracket. Every ModSecurity alert appears in the Apache error log. ModSecurity records one transaction in a single audit log file.
|
|||||||||
ModSecurity 2 Data Formats | Disclaimer: this link points to content provided by other sites. |