Reporting is a vital part of Mentat system. Currently there are following two types of reporting implemented:
- Event reporting
Periodical reports generated for each abuse group and severity.
- Statistical reporting
Periodical informational reports about overall performance of Mentat system.
Event reporting feature is implemented within the mentat-reporter.py module. This module is intended to enable distribution of events in the form of periodical reports to appropriate users. These users are mostly administrators within networks for which the Mentat system has relevant data.
Currently Mentat system supports following types of event reports:
This type of report contains all relevant data for particular network formated neatly into one email.
This type of report contains all relevant data for particular network formated neatly into one email, but regarding only single IP address. This type can be prefered in case respondents are using some kind of ticket system and want to resolve the issues separately for each host. This means, that when there are 10 events regarding 10 different hosts, this will produce 10 separate email reports.
All report emails sent by Mentat mentat-reporter.py have following common features:
Report message in human readable format.
Various custom email headers to enable automated processing and filtering.
Attachment files containing raw data of all reported events, possibly in various formats.
Metadata summary in report footer.
The human readable message organizes reported events into sections containing events grouped according some internal classification. For example each detector may describe SSH bruteforce attack with different IDEA message. Mentat attempts to classify these messages into the same class and display them in the same section. The report message however attempts to keep things as simple as possible and be as brief as possible, so only source address, event time window and event count are displayed in the table in each section. For more information about the possible problem you have to look into the attached file containing raw data (or download it from the server).
Report emails contain following usefull headers, that can be used for automated report processing and filtering:
Please note the deprecation of some of the email headers from previous version of Mentat mentat-reporter.py and their new names.
Class of the current report. For periodical event reports this header has fixed value
Unique report identifier.
In previous version of Mentat mentat-reporter.py this header was called X-Cesnet-Report-Id. This should now be considered deprecated and you should not use it anymore, support for old header will be removed in one of the future versions.
Unique identifier of parent summary report for
Type of the current event report. It can contain one of the following values:
In previous version of Mentat mentat-reporter.py this header was called X-Cesnet-Report-Type. This should now be considered deprecated and you should not use it anymore, support for old header will be removed in one of the future versions.
Severity of the current report. It can contain one of the following values:
In previous version of Mentat mentat-reporter.py this header was called X-Cesnet-Report-Severity. This should now be considered deprecated and you should not use it anymore, support for old header will be removed in one of the future versions.
This header contains IP adress appropriate for
In previous version of Mentat mentat-reporter.py this header was called X-Cesnet-Report-Srcip. This should now be considered deprecated and you should not use it anymore, support for old header will be removed in one of the future versions.
Total number of events reported in current..ehm…report.
Time window for current report as two timestamps in ISO 8601 format (YYYY-MM-DDTHH:MM:SS) concatenated by
Flag indicating whether this report contains test or experimental data. It can contain one of the following values:
Report always contains either only experimental, or only production data, there can never be a mix of any kind. When this value is set to
True, you may safely ignore current report in production environment.
Report emails may contain multiple attachments containing raw event data. Currently JSON and CSV attachments are supported. We strongly recommend users to use only JSON attachments, because they contain complete event data. CSV is a flat format with many limitations and events exported into this format are shortened and do not contain all available data. This feature should be considered as deprecated, it is kept only for compatibility purposes and it will be removed in one of the future versions. Please use only JSON attachments.
Report detail in web interface¶
All generated reports are stored on the server and accessible for the registered users. Accessing the reports via web interface provides users with additional options and features.
Work in progress.
Reporting customization for users¶
Work in progress.
Reporting configuration for administrators¶
By default the reporter is configured to prevent from unwanted spamming of target abuse contacts. This is great for initial deployment I you have to make extra effort to really start sending emails. Please continue reading for more details.
Most important configuration files related to reporting:
Common application configurations. Pay attention to
mail_settings, because they can override the reporting settings for abuse groups set in database. This approach is designed to prevent a recently installed Mentat system from spamming real world abuse contacts. So by default all reports are redirected to local
To enable reporting in production environments it is necessary to disable the
mail_tosetting in this file and to enforce
mail_to: nullin the main
Main configuration file of reporting component. Tweak this configuration file to customize the bahaviour of the reporting module itself. The most interesting options are customizations of various report email headers and report template customizations. Currently used convention uses names like following for classess:
Important: to enable reporting in production environment it is necesssary to set
mail_to: nullin this file and to disable its default value (
/etc/mentat/core/common.json.confconfiguration file (see above). Otherwise each report will be forcefully redirected to local
rootto prevent Mentat system from spamming abuse contacts.
Main configuration file for classifying instance of mentat-inspector.py module (in default installation). Rules contained in this file attempt to perform advanced event classification based on the event attributes. This classification can be then used for queries in web user interface and to organize events in generated reports to logically similar classes.
Jinja2 template defining content of summary event reports. This template is used when rendering summary event reports. It is completely localized, so it can be easily translated to additional languages. It is prepared for minor tweaks. For bigger content adjustments you have to create your own template and select it with
Jinja2 template defining content of extra event reports. This template is used when rendering summary event reports. It is completely localized, so it can be easily translated to additional languages. It is prepared for minor tweaks. For bigger content adjustments you have to create your own template and select it with
Report labels for event classess. The default reporting mechanism uses the classifying instance of mentat-inspector.py module to tag events with custom classess. This configuration file contains dictionary of human readable labels that is used to translate class label, for example
attempt-login-sshto string label like
Attacker attempted to login to SSH service by bruteforce password guessing method..
Report references for event classess. This configuration file is very similar to the
/etc/mentat/templates/reporter/_report.labels.txt.j2described above. Instead of translating class labels to human readable report labels, this configuration file contains external reference (URL) for each event class.
When you want to define your custom event class for reporting proceed according to following steps:
Tag event with new class using the mentat-inspector.py module. This means, that in default installation you have to edit configuration file
/etc/mentat/mentat-inspector.py.confand append new rule into the list of existing
Add new event class label into
Add new event class reference into
/etc/mentat/templates/reporter/_report.references.txt.j2configuration file. Make sure the URL is valid and contains relevant content.
If you are using internationalization, execute locally on the server babel command line utility to scan for new messages, provide translations and compile message catalogs.
TODO: This step requires implementation of locally available makefile, coming soon.