Detect attacks on your network with Maltrail
Sentry

© Photo by Lance Anderson on Unsplash
Maltrail is a lightweight analysis tool that examines network traffic and raises the alarm if it detects suspicious access or dubious name resolution.
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.
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.
Listing 1
Set up Maltrail
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).
Listing 2
maltrail.conf
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.
Listing 3
Anonymization
$ 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.
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.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
Arch Linux 2023.12.01 Released with a Much-Improved Installer
If you've ever wanted to install Arch Linux, now is your time. With the latest release, the archinstall script vastly simplifies the process.
-
Zorin OS 17 Beta Available for Testing
The upcoming version of Zorin OS includes plenty of improvements to take your PC to a whole new level of user-friendliness.
-
Red Hat Migrates RHEL from Xorg to Wayland
If you've been wondering when Xorg will finally be a thing of the past, wonder no more, as Red Hat has made it clear.
-
PipeWire 1.0 Officially Released
PipeWire was created to take the place of the oft-troubled PulseAudio and has finally reached the 1.0 status as a major update with plenty of improvements and the usual bug fixes.
-
Rocky Linux 9.3 Available for Download
The latest version of the RHEL alternative is now available and brings back cloud and container images for ppc64le along with plenty of new features and fixes.
-
Ubuntu Budgie Shifts How to Tackle Wayland
Ubuntu Budgie has yet to make the switch to Wayland but with a change in approaches, they're finally on track to making it happen.
-
TUXEDO's New Ultraportable Linux Workstation Released
The TUXEDO Pulse 14 blends portability with power, thanks to the AMD Ryzen 7 7840HS CPU.
-
AlmaLinux Will No Longer Be "Just Another RHEL Clone"
With the release of AlmaLinux 9.3, the distribution will be built entirely from upstream sources.
-
elementary OS 8 Has a Big Surprise in Store
When elementary OS 8 finally arrives, it will not only be based on Ubuntu 24.04 but it will also default to Wayland for better performance and security.
-
OpenELA Releases Enterprise Linux Source Code
With Red Hat restricting the source for RHEL, it was only a matter of time before those who depended on that source struck out on their own.