Watch and Guess

If the investigated data stream does not match any blocking list, Maltrail has to dig deeper into its bag of tricks and use heuristics. Maltrail looks for hints of malicious behavior, such as unusual user agents in the web requests, port scans, long domain names, and web access with code injection.

The results of these checks are not always precise and can lead to false positives. Whether or not a message made it into the web page due to the heuristics is shown in the reference column. If you see an accumulation of the heuristic label, you can use the USE_HEURISTICS configuration statement to disable this method.

Initiating Countermeasures

Maltrail can report, but it can't fight back. To block IP packets, Linux has iptables/nftables, FreeBSD has Pf, and Windows relies on the Microsoft Defender firewall. At least the Maltrail server provides its findings as a list of suspicious IP addresses via HTTP. The project page describes how to feed this information to the local iptables policy with a script. Basically, the IP list can be used to extend any firewall accessible via API or scripting, for example OPNsense and even the Windows firewall.

Limitations

Maltrail is not a full-fledged IDS but merely a packet scanner that makes use of public blacklists. Maltrail cannot detect complex, application-level attacks, which means it won't come close to the detection rate of a real IDS.

Another shortcoming is the communication between the sensor and server, which relies on the unencrypted UDP protocol. A man-in-the-middle attack could sniff, manipulate, or delete alerts to hide malicious activity. For undisturbed transport over the Internet, the admin needs to harden the alert packets with IPsec or SSH. Access to the Maltrail server's web interface uses TLS and a server certificate, which provides sufficient security.