Informative Reporting

After logging in to the web interface (Figure 1), Maltrail comes up with a summary and a table of the logged events. The summary lists the number of threats, events, sources, and trails used. The environment also provides threat severity assessments. Clicking the Events button opens the events logged in the selected time period; the environment generates a diagram of the event history for the past few hours. The blue line shows DNS-based events, the yellow graph URL-specific events, and the red graph IP-specific events.

Figure 1: The Maltrail web GUI is fairly plain. The filter feature lets you restrict the view to events in which you are interested.

If you want to find out which sources are primarily responsible for the events, follow the Sources link. A stacked bar chart visualizes the major sources. Mousing over a column shows the event distribution by protocol. The Trails overview visualizes the share of critical trails as a pie chart. You can also call up details here by mousing over the views.

The tabular event overview has a wealth of detailed information on the various incidents, with color highlighting in the severity column helping to distinguish critical from less critical incidents. For each entry, you can call up the source IP address, the port, the protocol type, the associated trail, and the event type. The sort function is useful, for example, to find critical entries first.

The table view is again interactive. If you mouse over the scr_ip column, Maltrail displays the event details, and you can use the search function to narrow down the event list. Typing high restricts the view to events with that severity level.

In practice, the question arises as to how to identify specific processes. The Tor browser is popular with hackers, so if Maltrail detects an incident in which Tor was used, the program notes this in the info column and flags it as tor . You can restrict the table view to the events in which you are interested by typing an appropriate entry. Malware can also be identified in this way.

Limitations

Maltrail focuses on identifying and evaluating malicious data traffic, as shown; however, Maltrail does have some limitations. For a complete overview of relevant events, integration with an environment such as the Malware Information Sharing Platform (MISP) [4] might be a good idea, but it has no smart solution as yet.

The integration of various sensors into the web GUI has also proved difficult to date. Unfortunately, Maltrail does not offer any meaningful support for dealing with false positives, so admin experience is required. Criticism on some forums also claim that Maltrail quickly collects many gigabytes of data, depending on the size of the network.

One criticism – that Maltrail only plays a passive role on various occasions – is not fair, because interaction with more active tools is easy to implement. The Maltrail server configuration contains a FAIL2BAN_REGEX option, which allows sensor data to be transmitted to ipset or iptables. More specifically, this option enables the use of IP-based blocking mechanisms by regularly retrieving the relevant data. For example, you can integrate Maltrail into your security architecture with a small script that runs once a minute as a root cron job:

#!/bin/bash
ipset -q flush maltrail
ipset -q create maltrail hash:net
for ip in $(curl http://127.0.0.1:8338/fail2ban 2>/dev/null | grep -P '^[0-9.]+$'); do ipset add maltrail $ip; done
iptables -I INPUT -m set --match-set maltrail src -j DROP

Maltrail is currently at version 0.68, but it has no roadmap. When I asked what features admins can expect in the future, I did not receive an answer.

Conclusions

"Small but powerful" is an apt description of Maltrail. The analysis software promises security-specific added value through traffic analysis with the use of established sources.