As digitalization makes further headway into business processes, the vulnerability of IT infrastructures increases. Just one undetected vulnerability could open the door to potential attackers. Even if 100 percent protection remains an illusion, organizations need to be proactive in the face of an increasingly stressful security landscape. Maltrail is a free tool that can be a useful addition in your search for would-be attackers on your network.

Detection

Managing legacy intrusion detection and intrusion prevention systems involves a great deal of effort, partly because hybrid approaches consisting of intrusion detection (IDS), host-based intrusion detection (HIDS), and network-based intrusion detection (NIDS) systems are required. However, managing Maltrail is child's play.

To identify malicious traffic on your network, Maltrail uses publicly available lists that point out critical or suspicious traces. On the GitHub project site [1], the developers reveal the lists and malicious entities on which they draw. Maltrail pays particular attention to statistics, antivirus (AV) reports, domain names, and IP addresses. HTTP user agent header values – such as those generated by sqlmap [2], used for automatic SQL injection and database hijacking – are also considered. You can also opt to deploy heuristic mechanisms, which can be useful in detecting previously unknown threats. The various suspicious sources are jointly referred to as "trails."

Basic Structure

Maltrail's strengths lie in its ability to detect suspicious web access and name resolution events. The functionality is largely limited to analysis and report output. The environment features a sensor and a server component. The server is used to store events and provide web-based access, whereas the sensor scrutinizes data traffic. The server in the Python-based environment is implemented in the server.py file and the sensor, unsurprisingly, in the sensor.py file.

In the default configuration, the server and sensor run on the same system. The developers claim that a virtually arbitrary number of events can be analyzed and processed thanks to the use of compression techniques. In principle, you can also use the sensor as a standalone environment. In this case, all the events are stored in the local logging directory, and the log entries can be evaluated manually or with the help of a third-party application that offers a CSV import function.

If the sensor registers a positive match, it sends the detailed information to the Maltrail server, where it is stored in the log directory. In a default configuration, in which both Maltrail components run on the same computer, the tool writes the logs to the local log directory, as mentioned previously. If you prefer to run the two components separately, you need to edit the LOG_SERVER configuration. In this case, the sensor sends messages by the User Datagram Protocol (UDP) to the remote server. For an initial impression of Maltrail, the developers offer an online demo [3].

Maltrail is not particularly demanding in terms of resource requirements. In addition to a Python interpreter (version 2.6 or greater), you need to install the pcapy-ng package. If you use Python 3.x, this will be pcapy instead. You need to allow at least 1GB of RAM in single-process mode for the sensor component, which also requires root privileges. The server component has no specific requirements, and the install process is simple. If you are working with Ubuntu or Debian, just run the following commands:

sudo apt-get install git python3 python3-dev python3-pip python-is-python3 libpcap-dev build-essential procps schedtool
sudo pip3 install pcapy-ng
git clone --depth 1 https://github.com/stamparm/maltrail.git
cd maltrail
sudo python3 sensor.py

Alternatively, you can use a Docker container. To start the server on the same system, open a new terminal window and type the commands:

[[-d maltrail]] || git clone --depth 1 https://github.com/stamparm/maltrail.git
cd maltrail
python server.py

When the sensor is started for the first time, it downloads the available block and reputation lists to the local system, which you can monitor easily in a terminal window. After launching the server, you can access Maltrail in the web interface, which for a local installation is http://127.0.0.1:8338 with default access credentials admin: changeme!

Initial Configuration Steps

The Maltrail environment is configured in the maltrail.conf file, which has [Server] and [Sensor] sections to let you configure both components. Specify the server address and port in HTTP_ADDRESS and HTTP_ PORT. If you want secure access by SSL or TLS, set the USE_SSL option to true. For secure access to work, the SSL_PEM option must refer to the certificate container.

Once you have had an initial look around, you will want to change the admin user. If needed, you can create more users. The settings for this can be found in the USERS subsection. Each user entry consists of the following data:

Username:sha256(Password):UID:filter_netmask

The UID value assigns a unique ID to the user. It is advisable to assign values 1000 or below to administrative accounts; for example:

admin:g6j0pelqmhg2n72zx947lf72rxf4iqzzml9zzrcnfzgreguqx69nopme6ctq8r8s:1000:192.168.0.0/16

The UDP_ADDRESS and UDP_PORT options specify the server that receives the messages. No changes are required for a default configuration.

When the server is started for the first time with

python server.py

the enabled USE_SERVER_UPDATE_TRAILS option makes sure the trails are updated from the trail definitions to guarantee that log entries end up in the logging directory and the reporting interface is available.

The sensor also offers various configuration options. If you are monitoring larger environments, you will want to give Maltrail additional resources. The easiest way to do this is to set the USE_MULTIPROCESSING option to true, which means that Maltrail will use all the CPU cores, with one core for the environment and all the others for packet processing. If you do not use this option, all tasks are handled by a single core.

The value of the information returned by Maltrail largely depends on the trails that the environment picks up from various sources. The UPDATE_PERIOD option determines the update interval in seconds. The default value of 86,400 ensures a daily update. Besides trail-based analysis, Maltrail uses heuristics for risk assessment, which is enabled by default with USE_HEURISTICS. The check examines the traffic specifically for suspiciously long domain names or attempts to download EXE files. The disadvantage here is that heuristics can lead to a noticeable increase in false positives.

You can use the SYSLOG_SERVER option to forward the events to an external environment. The event data is sent to your choice of UDP service in the common event format (CEF), which includes Syslog, for example. If you prefer JSON as the format on the receiving end, use the LOGSTASH_SERVER option instead. Again, UDP is the communication protocol.

Finally, Maltrail has cross-component settings in the [All] section, which you use to decide whether debug messages are output globally in the environment or whether you want to use a proxy server. You can also change the default storage location for the trails here.