Sentry

Hundreds of security products vie for the favor of users on the Internet, promising the highest levels of protection. Along with the numerous commercial offerings available for a monthly rate are some free open-source products that aim to expand the basic protection that might already be in place.

Maltrail [1] is an open source tool that lays in wait on the network and sounds the alarm if a package appears suspicious. It reports its findings but does not intervene. The way Maltrail works is somewhere between an intrusion detection system and a malware scanner. Maltrail uses public blacklists to examine the packages. In Maltrail jargon, the description of a suspicious IP address, web URL, or domain is known as a trail. Feeds are lists of known trails that the Maltrail community keeps up to date.

Structure

Maltrail consists of two components. The sensor component sniffs the packets, and the server component collects the alarms from the sensor. In a perfect setup, the sensor component resides on a router or firewall, because these devices get to see the data streams of all network participants. In Figure 1, the sensor resides on a firewall and therefore has access to all the packets passing through. The position of the server does not matter much as long as the sensor and the admin can access it.

Figure 1: The Maltrail sensor sits in the data stream and reports to its server.

Installation

The Maltrail program code is written entirely in Python. Maltrail is not picky about the Python version. Basically, all interpreters with a version number of 2.6 or newer will work, and this means that even older Linux servers can be used as sensors. The sensor also needs the Python pcapy package to intercept the IP packets from the network adapter. The software itself is available from Github under a free license.

For the install, use your distribution's package manager and install the required packages (Listing 1, first line). Afterwards, retrieve the program code from Github and store it locally (line 2). By default, the sensor listens on all available network adapters and dumps its warnings into a local file.

01 $ sudo apt install python-pcapy git
02 $ git clone --depth 1 https://github.com/stamparm/maltrail.git
03 cd maltrail
04 $ sudo python sensor.py
05 $ sudo python server.py
06 $ nslookup kshield.net

When first launched (Line 3), the sensor fetches all available blacklists from the net and drops them into the ~/.maltrail/ subfolder. Maltrail then starts its magic. To enable the sensor to report to the server, you need to add its IP address and port to the Maltrail configuration file ~/.maltrail/maltrail.conf (Listing 2, Lines 2 and 3). Then launch the server (Listing 1, Line 5). The sensor sends its results to the DNS name or to the previously resolved IP address of the server (Listing 2, last line).

01 # Address and port of the server
02 UDP_ADDRESS 0.0.0.0
03 UDP_PORT 8337
04 # log server
05 LOG_SERVER server.example.net:8337

It is easy to test whether the communication link between the sensor and the server is open. To test the link, resolve a domain that is blacklisted by Maltrail on the system running the sensor (Listing 1, Line 6). The sensor detects the action and reports the incident to the server.

Evaluation

The server delivers the results on a pretty web page. http://server.example.net:8338 gives you access to graphical processing of the reported alarms, grouped by message type, sensor, and IP address of the originating client. You have to judge for yourself whether the message is actually a real threat. For example, if the Windows computers on the local network use the Remote Management API, Maltrail will report suspicious actions, but this is no reason for you to worry.

Heads up to data protection officers: Maltrail does not comply with rules for protection of personal data. For example, the IP addresses of the clients can be found in the analysis, and user names are also occasionally found in the HTTP access reports. If you don't want to get into trouble, black out the client address in the log file afterwards with the commands from Listing 3.

$ cat $(date +"%Y-%m-%d").log |
  awk '{ $4 = "-"; print }' > temp
$ mv temp $(date +"%Y-%m-%d").log

The server's web interface presents a daily report with all alert messages received (Figure 2). The report summarizes the threats, the events, the most suspicious IP addresses, and the most frequent trails in colorful charts. You can obtain details of the recorded addresses by hovering the mouse over the text.

Figure 2: The Maltrail server informs about all alarms.

Many programs and operating systems phone home in the background, and Maltrail shows in its overview which of the messages seem suspicious. In addition, Maltrail lets you know which machines attempt to communicate with each other on the local network without you knowing about it or wanting it to happen.

The project presents a collection of examples of real-life attacks on its website in the Real-life cases section. If you find similar entries in the reports of your Maltrail server, your network may have been the victim of a mass scan, a port scan, malware, or a data leak. Of course, not every report will automatically trigger a Class 1 alert. Sensible use of Maltrail requires you to adapt the alerting system to your own environment and minimize the false positives by doing so.

Place of Use

If you are not able to install Maltrail on a router, switch, or firewall, you need to run the software in passive mode. To operate Maltrail in passive mode, set up the sensor on any computer and then configure it to receive a copy of each packet via a mirror port on the core switch. In this configuration, the sensor is not sitting in the data path, but it will still get enough information to work effectively.

Small networks with a Fritzbox or Speedport as the central component require more effort. The popular DSL routers only allow insights into the incoming packets via a backdoor. This is where manufacturer support ends and tinkering begins. Fortunately, various scripting geniuses have shared their success in accessing the hidden areas of the Fritzbox [2] web interface and other devices [3]. If your router does provide the packet stream in PCAP format, the Maltrail sensor can read and analyze the resulting file with the -i switch.

If this kind of workaround is too much work for you, the only other option is to use Maltrail as a host IDS. In this case, the sensor runs locally on all the servers you want it to monitor. However, Maltrail will no longer be able to protect the entire network, only selected computers.

Exceptions

Not all trails on your network pose a threat. Maltrail also sees services like DynDNS and various HTTP user agents as potential risks. To prevent harmless messages from filling the entire log, you can exclude groups of trails or even entire feeds from the scan.

If you want individual trails to disappear, make them invisible by right-clicking and selecting Hide Threat. Conversely, Maltrail also accepts custom sources with trails that you specify in the configuration file via the CUSTOM_TRAILS_DIR.

Special Case: Windows

Officially Maltrail only runs on Linux and Unix, but with a few tweaks, you can also use a Windows computer as a sensor. The problem is not with Maltrail itself, but with the Pcapy package, which comes with a mass of dependencies. If you don't mind the work, download the Pcapy, Winpcap, and Python source code, as well as the Microsoft Visual C++ Compiler for Python, and compile the package yourself [4]. Once this step is completed, you can launch the sensor on Windows, where it will run in the usual way (Figure 3).

Figure 3: In a roundabout way, Maltrail also runs under Windows.

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.

Outlook

Maltrail is also at home in virtual environments. For instance, you can analyze the network traffic of guest systems in a VMware infrastructure. The ESXi host has a Python interpreter on board, but Maltrail works better as a standalone virtual machine. The VM needs one network adapter per port group. Because Maltrail accesses the IP packets via PCAP, the port group or virtual switch needs permission to use promiscuous mode. In this setup, Maltrail works only with copies of the packets. This keeps the virtual servers accessible even if the sensor process throws errors or the Maltrail VM is not running.

The Maltrail sensor can, of course, report to its own server, but it can also feed Syslog and Logstash. To do this, it formats its messages as standardized syslogs or as structured JSON. This support for logging means you can integrate Maltrail into a larger log infrastructure or include it as part of a logging-as-a-service strategy.

Conclusions

The lightweight Maltrail network scanner analyzes network traffic for suspicious activity, gleaning information from freely available blacklists and reputation databases. Maltrail also acts like an intrusion detection system: It loads signatures and compares them with the inspected IP packets. If a match occurs, an alert appears on the dashboard to warn the admin. Maltrail is not an all-around no-worries package, but it is a useful building block in a security strategy.