Collaborative firewall on Turris OS 4.x.x

Hello. I have an Omnia 2019 with Turris OS 4.0.1 hbs. I read on this forum that the data collection and Honeypot is not yet integrated into Foris, but it is still possible to install the corresponding package groups. Is there a guide or could you help me to configure Turris OS 3.x.x-like distributed and collaborative firewall even from the command line? Thanks.

Enabling data collection package list installs dynamic firewall that is automatically enabled.

To participate in data collection you have to install some of the sentinel collectors, such as sentinel-nikola for firewall logs, sentinel-minipots for telnet minipot or turris-survey for router usage statistics. Please note that doing so you agree with our eula.

Thank you so much for your answer. I really appreciate the team’s availability. Could you provide me with a link to more detailed instructions for enabling the firewall and HaaS? On 3.11.8 I had everything enabled and I had accepted your EULA. Can you give me some steps to follow? I’m a dirty noob.

If you are “dirty noob” then just wait for official support. That is going to save you a lot of pain.

In general there are still blocker why we do not do wide deployment. Foris integration is not yet done and internal security audit for some components (like minipots) is not done.

I suggest you to activate data collection package list in Foris (in updater tab). That is going to install dynamic firewall.

For HaaS you can enable it in package list and then you have to configure it. Then navigate to and in your account add new device or display token for original addition. You have to paste this token to /etc/config/haas. The file is documented so you should have no problem with this.

Ok. Thank you so much. I will activate those packages in foris and connect the router to Haas by taking the token from the configuration file. Will Ludus also be brought on OS 4?

Ludus is not directly maintained by us and support for 4.0+ release depends on original authors. I can’t talk for them.

Ok I understand. Thanks.

@cynerd I tried to install these packages on 4.0.3 (hbk) following the official guide. Are these errors normal?

root@turris:~# opkg install sentinel-nikola sentinel-minipot
Installing sentinel-nikola (2.0-3.6-1.20) to root...
Installing libgpg-error (1.12-1.1) to root...
Installing libgcrypt (1.6.6-3.0) to root...
Installing libmicrohttpd (0.9.59-1.1) to root...
Installing liblz4 (v1.7.5-1.1) to root...
Installing czmq (4.2.0-2.0) to root...
Installing libpaho-mqtt-c (1.3.0-1.21) to root...
Installing sentinel-proxy (1.1-6.4) to root...
Configuring libgpg-error.
Configuring libgcrypt.
Configuring libmicrohttpd.
Configuring liblz4.
Configuring czmq.
Configuring libpaho-mqtt-c.
Configuring sentinel-proxy.
Command failed: Not found
Configuring sentinel-nikola.
Reloading syslog-ng
Installing sentinel-minipot (1-7.4) to root...
Downloading      Installing msgpack-c (2.1.5-2.0) to root...
Configuring msgpack-c.
Configuring sentinel-minipot.
Command failed: Not found
Bad argument `'
Try `iptables -h' or 'iptables --help' for more information.
iptables: No chain/target/match by that name.
/tmp/sentinel-remove-iptables: line 2: not found
Bad argument `'
Try `iptables -h' or 'iptables --help' for more information.

To understand something: I’m on Omnia and 5.0-dev. I have successfully installed Data Collection and SSH Honeypot from Foris. Everything works, I did the ritual tests: I checked the blocked ip (currently 566) and tried to access the router from another network via SSH (again, everything as expected). Now I ask myself: do I also have to install setinel-nikola and sentinel-minipot? What exactly do they do? Having SSH Honeypot can I avoid minipot or do its different functions? And turris-survey?

Well normal in sense that we know about it and we have some fixes in 4.0.2 and some more of them in merge request still on review waiting for more testing.

The cause is change in firewall.

All of them serve other purpose.
Nikola is firewall logs collector. All blocked connections are logged and that is collected by Nikola.
Minipots are tiny honeypots. HaaS is for SSH while minipots are for telnet (in future HTTP, FTP,…)
Turris survey is for distribution maintainers. It collects mostly just list of installed packages but might collect more in future. The idea is to see what users are using and that way have concrete data about affects of some problems in distribution.

1 Like

Thank you very much for the detailed answer. A complete guide should be created that would avoid many questions on the forum. However I decided to install everything: nikola, minipot, turris-survey over the dynfw and SSH Honeypot. Are there any special activation procedures for Nikola and the turris survey, or just install them and do they work? How can I view the nikola logs?

Hi there. Turris started with Suricata, and now go to Sentinel. The reason i got a Omnia and a mox classic, is this whole firewall concept.
question, when will this dynamic firewall that is working on my Omnia work in the same way on the MOX classic?

Also, Most modern consumer routers have some sort of IDS/IPS application built in these days.
Is this something that is in the pipeline?

txs, best, Dikke

1 Like

Sentinel is already working and works the same way on Omnia and MOX. There is still a phase of improvement, I do not know if the code has been audited and there is no eula that is among the things to do on GitLab. I installed the real components and everyone (or almost) managed to verify its functioning. As for IDS / IPS, if you look for the definition on Wikipedia and compare it with Sentinel’s in the official Turris documentation, you will see that they are the same for what is essential. So do not believe a function is implemented that would be redundant because it is already present.


there is experimental feature called PaKon (like parental control), which used Surricata in the backend. It is intended to monitor traffic inside your network (LAN→WAN, etc.) and all collected data never leaves your router.

Sentinel, on the other hand, is a tool that collects meta data (mainly from WAN interface) and send them to our server for analysis. Based on these data, we (e.g.) calculate and publish evil IP addresses. From this list, a dynamic firewall component (Sentinel:DynFW) can update firewall rules in your device (regardless Turris router or not) and protect yourself in advance.

Components of Sentinel service are currently minipot (a dummy honeypots collecting users and passwords from attackers) and firewall logs (collects remote addresses from rejected connections). Survey (collects list of installed packages and lists) and other components are in development at the moment.

DynFW is also a Sentinel component but it just passively recieves data (list of IPs) and does not collect nor send anything to servers.


PS: we are moving from uCollect to Sentinel. uCollect does something similar to Sentinel but it’s our former system, currently in EOL.

PS2: software for MOX and Omnia is the same (and Turris 1.x as well).

1 Like

A real cool!

Really fascinating. I knew the story in a general way in a piecemeal way, but here is a very good summary.
I just want to point out for those who intend to use minipot on hbd, that currently installing the package you get a wrong configuration, which does not point to any port. By manually editing the file in /etc/init.d/sentinel-minipot (file that starts the service), you can get a working configuration. In this regard I opened an issue on GitLab

Thank you for the answer.

“‘From this list, a dynamic firewall component (Sentinel:DynFW) can update firewall rules in your device (regardless Turris router or not) and protect yourself in advance.’”
AFAIK, this is current active in Omnia, but not on a MOX, correct?

Dec 20 12:15:03 turrisMOX nikola: recognized WAN interfaces: pppoe-wan
Dec 20 12:15:05 turrisMOX nikola: Establishing connection took 0.000046 seconds
Dec 20 12:15:05 turrisMOX nikola: Logrotate took 0.024820 seconds
Dec 20 12:15:05 turrisMOX nikola: Syslog parsing took 0.000911 seconds
Dec 20 12:15:05 turrisMOX nikola: Records parsed: 0
Dec 20 12:15:05 turrisMOX nikola: Records after filtering: 0
Dec 20 12:15:05 turrisMOX nikola: Records filtering took 0.003968 seconds
Dec 20 12:15:05 turrisMOX nikola: Sending records took 0.003239 seconds
Dec 20 12:15:05 turrisMOX nikola: turris firewall rules might not be active

It is not correct in the sense that in both of them it must be activated manually, both on 3.x and on 4.x and later. You must follow the guide on the page already mentioned above. The guide does not distinguish between Omnia or MOX. I don’t have a MOX so I can’t tell you for sure, but if you install the various components I think it all works the same way. After all, the operating system is the same.

I just want to point out for those who intend to use minipot on hbd, that currently installing the package you get a wrong configuration, which does not point to any port. By manually editing the file in /etc/init.d/sentinel-minipot (file that starts the service), you can get a working configuration. In this regard I opened an issue on GitLab

I would like to just point out that HBD :dragon: is really not recommended for regular users. It’s under heavy development and it’s really far away from “stable” HBS :snail: release.

If you like to have new stuff as soon as possible but you do not want to encounter and solve both OpenWRT and Turris OS “development” issues, use HBK :cat2: .

If you just want to test a release candidate, HBT :turtle: is suitable for you.

1 Like

No. I tried to explain it in the reply.

Firewall logs (Sentinel:FWLogs, collected by tool named nikola at the time of writing) are part of collecting and sending data to our servers.

Dynamic firewall (Sentinel:DynFW) just monitors and fetches list of published evil IP addresses and blocks them in the router firewall.

Both of this tool can run independently and does not effect each other directly on the device.

If you refer to following log line

 Dec 20 12:15:05 turrisMOX nikola: turris firewall rules might not be active

the issue might be in TurrisOS version (nikola version respectively), not in type of a device. As I wrote above:

Sorry, dikke is what you call a ‘’ dirty nOOb"’ so forgive my trouble understanding some things here…
What i have is a omnia running 3.X and a Mox Running 4 x.
on both i have both Data collection and ssh honeypot running as in activated in Forris.
In HAAS the omnia shows up, feeding the yanks and the chinese :slight_smile:
Also put the ( different ) haas token in the MOX etc/config/haas.
Is this correct?