Hi alls,
I’m hosted few services behind my Turris, and I’m using Fail2Ban in front of these services.
Is there a simple way to give all the banned @IPs detected to the Turris Firewall without mess up the dynamic updates ?
Regards and Happy new year …
Do you mean sharing the learned rules with the community or are you just seeking a way to create your own iptables rules in a way to not interfere with the dynamic firewall?
1 Like
This is more complex that you might think because there is NAT involved:
Once I was wondering the same
I guess doable by iptables/ipsets. I was trying something similar in the past.
Ipsets are introduced in newer openwrt versions so one more reason to release the kraken TOS7/8
Oh, you mean on a device behind Turris? Then that might be more complicated.
Generally, you can easily install f2b on Turris and its iptables rules do not collide with the dynamic firewall. F2b has a command-line interface via which you can add/remove blacklisted addresses. So you could script something that would read the f2b database on the device behind Turris and relay the blacklisted addresses to Turris using the CLI tools.
Not sure what you mean. The dynamic firewall already uses ipsets on TOS 6.
I meant support in LuCI. So you are right.
Both @peci1, I ll be really happy to share theses annoying @ips with the community and block them at the turris level.
I don’t think that NAT should be a problemFail2Ban read the reverse NGINX proxy log so it have access to the IP source HTTP, but I’m not sure …
I thinking put all theses IP in a list and add a new one to the iptables of the turris but I’ve no idea how to send it to the community for the dynamic firewall …
It is easy, you can do it locally, create your ipsets(can be many with different names). And add iptables rules which will use your ipsets.
To survive boots you should add all your rules/ipsets to the /etc/firewall.user file(you can edit it actually from the Luci as well) or create separate files and call it as a script.
The sharing with community will probably not work. CZ.NIC is quite picky (or, careful) about the rules sent from Sentinel to the cloud. That’s why each Turris has a unique key with which it signs all data sent to the cloud - that way, CZ.NIC can be sure at least about the data origin. And I think it’s good - if somebody found a shady way to sneak something in the cloud rules, he could effectively block a legitimate IP. Also, you can’t block IPs blindly as some act as VPN concentrators and other gateways/NATs, so blocking the gateway would block a too large part of the Internet…
I know there were some plans to offer Sentinel publicly even for non-Turris devices, but I’m not sure what state it is in right now…
There is a nice talk about the complexities of Sentinel if you’re interested: https://www.youtube.com/watch?v=kpNwNsfkTdY .
And the winners are :
94.232.42.99 12 RU Dmitriy Panchenko
172.104.137.47 11 US Akamai Technologies, Inc. (AKAMAI)
5.188.210.227 8 RU Bashilov Jurij Alekseevich
185.91.69.110 4 UK HOSTGNOME LTD
142.93.115.5 3 US DigitalOcean, LLC
146.190.119.189 3 US DigitalOcean, LLC
167.172.89.248 3 NL RIPE Network Coordination Centre
188.166.71.161 3 NL EU-DIGITALOCEAN-NL1
106.75.142.97 2 CN Shanghai UCloud Information Technology Company Limited
106.75.147.6 2 CN Shanghai UCloud Information Technology Company Limited
Yes, this is one of the ways used to avoid easy poisoning of the blocked IPs list.
There are currently some pilots where we are testing this setup.
1 Like