Almost three years ago, NIC.CZ and the AI Center of Czech Technical University got together and started a joint project aiming at improving the security of the Turris routers. Project Ludus, which has been funded by the Technological Agency of the Czech Republic, is an outcome of this initiative and gives every Turris router user the opportunity to secure their device further. The primary tool which we use as a defense mechanism is a Honeypot. We designed a Game Theoretical model which captures the behavior of the attackers in the network and predicts the optimal places to build the defenses.

In this blogpost we introduce our tool which uses honeypots as a defense mechanism based on the game theoretical model of behavior of the attackers. Ludus fully automates honeypot deployment and management and visualize results in the level of individual routers.

What is a honeypot, and how can we use it?

The idea of honeypots for the protection of computer networks is more than 20 years old. The basic principle is simple: an artificial device (either real one or software-simulated) is added in the network which serves as a trap for the attacker. The aim is to lure the attacker to the honeypot, which looks like a promising, weakly secured way of attacking the system. The Honeypot itself is completely separated from the real system, and once the attackers get in, we try to stall them as long as possible while monitoring their actions. Valuable information about the course of attacks can be obtained from honeypots, which further helps to improve the defense mechanisms.

Honeypots at Our Disposal

In recent years, there has been a boom in different honeypot systems, providing users with a wide variety of options to choose from. The primary difference in honeypots is the level of interaction allowed. Low interaction honeypots such as TARPIT are relatively easy to deploy, and they use very little resources, which means that they can be scaled across the network. The downside of low interaction honeypots is the limited information they can collect about the attacker. In contrast, high interaction honeypots, provide detailed information about the attacker and the course of the attack, which is precious data for both researchers and system administrators. This information however, comes with a price. The cost of such solutions lies in the demands on the hosting device - such services have to be sandboxed, run in Virtual Machines or separated from the host machine in order to separate the real computer from the attacker.

How to choose where to place a Honeypot?

Once you selected the honeypot to deploy, the real question that remains is: where should we place the honeypots to trap the most attackers? In Ludus, we solve this issue by modeling the attacker behavior. With our model, we can predict the probability of a port being attacked and distribute the honeypots so that the hit rate is maximized. Again, our goal is to convince the attackers to attack our honeypots and not the real services, and keep them busy for the longest time possible to gather as much information as we can.

Ludus automatically analyzes the usage of your network and finds out which ports are suitable for deploying honeypots. Ports in which a real service is running (Production ports) cannot be used for placing honeypots. In fact, those are the ports which attackers want to target the most and therefore ports which need to be secured. When the state of the device changes, both list of production ports and potential honeypots is updated and real services are never blocked. Since one port cannot be both production port and honeypot, how can we protect the real services? In a single device, one option is to deploy a honeypot which is even more promising for the attacker than a real port. However, that brings an issue of measuring desirability of different services for attackers. Instead of protecting each router individually, we created a strategy for collaborative defense. That way, users can help each other and collectively improve their security.

Collaborative defense

As mentioned before, the biggest issue is protecting a port which runs a real service. Let’s consider the following example:
User A has a router with running web server in port 80. Attackers can scan the network, find out that port 80 is open and exploit it. If we add another user with a router - user B who doesn’t use port 80, we can use B’s router for placing a honeypot in the unused port. Therefore, the attacker sees two routers with open port 80 but cannot distinguish which is the real service and which is the honeypot. In other words, users can use their unused ports to help each other. Our model is precomputed which means that the routers don’t communicate their current setups witch each other. In fact, each of the routers executes the same strategy independently.

Data collection and privacy protection

One of the main principles of Ludus is to protect users while not compromising their privacy. For us, it means working with anonymized data with no way of tracing it back to the real users. Firstly, we never analyze the traffic in your local network. Since Ludus aims at protecting your network from attackers from the internet, there is no need to examine local traffic. Secondly, Ludus never records the content of packets. For analysis and alerting, we use the concept of Netflows. A Netflow groups the individual packets into connections based on the source address, the destination address, port, and protocol. The payload of individual packets is not examined. For generating alerts, we use a well-known, open source intrusion detection system known as Suricata IDS. From all devices, we gather the following data:

Open Honeypots
Open Production ports
Number of bytes and packets transferred in each port
Alerts in each port (the type of alert, class, IP of the attacker)

Data is gathered via Sentinel, which is a tool developed and maintained by CZNIC. It encrypts the communication with the router. The anonymized data is processed by CZ.NIC and stored in their database. Upon starting the tool a random hash is generated and used as a ID for each router, which means there is no connection to the owner or the serial number of the device.

Results and Visualisation

There are two ways of viewing the data. The first is a web app running locally on your device, which shows your local data. It can be found in the same address as a Forris interface and it is protected with Forris password. The dashboard shows how is your device being attacked, types of attacks, and progress over time.

If you are interested in the bigger picture, aggregated data is available in our Kibana dashboard. It contains data from all devices running Ludus and helps us to further improve the strategies and mathematical models.

How to Use It

The Ludus system can be used as part of the Turris OS for routers based on OpenWRT. If you have a Turris router you can just do:

opkg update
opkg install ludus-gui
/etc/init.d/ludus enable
/etc/init.d/ludus start
reboot

The version of Turris OS that supports Ludus is 3.11.6

If you have other OpenWRT router it may be possible that Ludus works, but we didn’t try yet. Just clone it from https://github.com/stratosphereips/Ludus. If you try it in another router, please let us know.

Summary

Ludus system brings new approach for securing Turris routers. It uses Game theoretical models to predict the attacker behaviour and uses the prediction for honeypot placement. Additionally, Ludus introduces collective approach to securing routers. By that, users can help each other protecting their running services. Ludus also provides visualization of both individual and aggregated data for further analysis and improvement of the strategies.

If you have any question or request send us an email to ludus@aic.fel.cvut.cz

Project Ludus - Smart Honeypot Manager for Collaborative Defense