Alerts in ntopng are the result of traffic analysis based on checks. Checks detect that specific indicators on traffic require attention: for instance a host whose behavioural score has exceeded a given threshold or a flow that is exfiltrating data. Checks process traffic information with respect to a specific Network element, and for this reason they are divided into families (e.g. host, interface, flow, …). Regardless of the family, they can cover a security aspect, or they can monitor the network performance, for this reason they belong to different categories (e.g. Network, Cybersecurity, Active Monitoring, …).
Checks can be enabled, disabled, configured (e.g. to set thresholds) through the Settings -> Checks page in ntopng (left menubar) where they are divided into multiple pages based on the family, and they are marked based on the category.
As a consequence of traffic processing, when something requires attention, checks trigger alerts. Alerts are stored by ntopng into an internal database (SQLite by default, or ClickHouse when enabled) and can be notified in multiple ways, including messaging systems (e.g. Telegram, Slack, Discord, Teams), logging systems (syslog, Elastic), callbacks (web hooks, shell scripts), email.
Alerts from the internal database can be inspected using the Alerts explorer (left sidebar, Alerts icon), which allows you to go back in time, and analyse them by means of a set of features including filtering on all alert fields. By default, alerts are stored in SQLite that is suitable for small/mid sites, whereas for large sites or for keeping alerts with long retention we advise to enable ClickHouse.
Triggered alerts are always stored in the alert database. Instead, in order to deliver alert notifications to a remote recipient, a specific configuration is required. This process has been dramatically simplified in the latest ntopng (dev) version, to avoid the headaches related to the Pools and Recipients configuration as it used to be.
As first step, an endpoint should be configured. This identifies a target able to receive notifications. For instance, in case of Discord, this is represented by the WebHook URL which is an identifier used to deliver messages to a Discord channel.
As second step, for each endpoint, at least a recipient should be configured (one or more recipients can be configured for the same endpoint). A recipient represents a destination for the notification.
The recipient configuration includes a filter to decide what kind of alerts should be delivered to that specific destination. For instance, it is possible to specify the Minimum Severity for alerts to be delivered to the recipient and one or more Check Categories.
In addition to this, more control on alert filtering is often required, especially when it comes to deliver alerts for Flows and Host where the cardinality can be high and we are interested in receiving alert notification for a subset of (interesting) hosts out of many alerts related to many hosts. In order to allow this, a set (one or more) of Host Pools can also be configured.
The Host Pools to be selected in the recipient configuration can be defined as usual in ntopng through the Pools menu, by specifying IPs, subnets, MAC addresses.
This is the current state of the art. In the coming weeks we will further improve alerting by adding new features such as:
- ability to silence noise alerts (e.g. do not send me a new alert if a similar one has been delivered in the recent past).
- further alert filters (e.g. send to recipient X alerts that contain a specific value).
In essence we want to reduce alert noise, by delivering to specific recipients alerts they care about, and avoid sending specific alerts too often in case a problem is periodically repeating.
Enjoy !