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.