Creating a Report Receiver API for the ModSecurity Rule Reports

1. An API (Application Programming Interface) is provided by cPanel & WHM for transmitting ModSecurity rule hits to a URL that is customizable. The report function lets, rule distributors receive feedback about issues that are encountered by users when it comes to their ModSecurity rules. In this context, let us touch upon cPanel & WHM. It is a suite of tools that enables web hosting tasks’ automation with the aid of a simple graphical user interface It is meant for Linux OS. It servers the purpose of rendering server management as well as website management easier. Every website that we visit is made accessible through the service of web hosting, which is provided by various web hosting companies, such as HTS Hosting. In web hosting, server space is provided along with the necessary services and technologies to host and deliver the files of websites to the devices on which the sites get browsed. It is meant to ensure that the web content is available over the Internet without any interruption. The most efficient web hosting service providers are usually referred to as the “Best Website Hosting Company”, the “Best Cloud Hosting Company”, the “Best Windows Hosting Company”, etc. Now let us describe how a report receiver API for the ModSecurity rule reports can be created. Setting the Report Receiver Endpoint URL

2. A metadata file is required by each vendor. The information, that is used by the WHM API for identifying the rules and for knowing where to report URL and download the rules, is provided by this file. Implementing a Report Receiver API Endpoint The requested data is provided by the report sender API. Let us describe the HTTP details- Path to API endpoint – The endpoint URL can be customized in order to meet individual requirements. Methods Accepted- POST Request body Content-Type – Application/json Now let us describe the following body details: meta_id – It is an integer. The unique ID number, as ModSecurity rule’s id action, specifies it. ID – It is an integer. The line number from the modsec database. IP – It is string. It refers to the source IP address of the client. http_version – It is string. The HTTP (Hypertext Transfer Protocol) version number. meta_line – It is an integer. The line number of the rule by which the hit was generated within the ModSecurity configuration file. Timestamp – It is a string. It refers to the time of the hit. The server’s configured time zone is used by this parameter. meta_uri –It is string and refers to the URL requested by the client. This data isn’t available at all times. http_method – It is string. It is the HTTP method which was used by the client to generate the hit. http_status- It is an integer. It is the HTTP status code that the web server returns. timezone- It is an integer. The configured time zone of the server as a number of minutes offset from GMT (Greenwich Mean Time). meta_file – It is string. The file which has the ModSecurity rule that generated the hit. Action-desc – It is string. The text posted to the client by the web server. meta_logdata – It is string. The transaction data fragment from the logdata action of the rule of ModSecurity. path – It is string. It is the relative path to the document root of the virtual host. host – It is string. The domain name of the virtual host. handler – It is string. Only null is returned by this parameter. meta_offset – It is an integer. It refers to the byte offset where a match takes place, within the target data. This data isn’t always available. meta_rev – It is an integer. It is the revision number from the rev action of the rules of ModSecurity. justification – It is string. It refers to the specific criteria from the ModSecurity rule which generated the hit.

3. meta_severity – It is string. It is the hit severity level from the severity action of the rule of ModSecurity. meta_msg – It is string. It is the human-readable message from the msg action of the rule of ModSecurity. file_exists – It is Boolean. When the value is 1, the file listed by the meta_file parameter exists. When the value is 0, then the file doesn’t exist. email- It is string. It is the email address provided by the submitter for contact in the future with the maintainers of the rule. type – It is string. It shows the type of report. There is no specified format for this field. This field can be treated as freeform text. message – It is string. It is a submitter’s short message regarding the rule’s issue. rule_text – It is string. It refers to the rule’s exact text, at the time of submission. It needs to be mentioned here that if a submission occurred post an update to the rule, submissions of a report from an old hit might be encountered. The meta_rev field needs to be used in this situation for tracking the rule revision that caused the issue. Response The response data is provided by the report receiver API. Let us describe the HTTP details- Status – 200 must always be used by the status, on success. For any failure that still generates a JSON response, it is recommend to use a 200 status as well as the body to communicate that error. The report sender API is instructed by this status to try to parse the response. When there is total failure to use a relevant JSON response, 4xx or 5xx error codes are used. Response body Content-Type – application/json Let us describe the following body details: status – It is Boolean. When its value is 1, the receiver had accepted the report. When the value is 0, an error was encountered by the receiver. error (optional) – It is string. It is a short message about the error. Its an optional value unless an error occurs. Source:https://www.htshosting.org/knowledge-base/website-security/221/creating-a- report-receiver-api-for-the-modsecurity-rule-reports