Use OpenWrt firewall (drop all connections incoming from WAN) or add a fail2ban-like functionality to dropbear and uhttpd

[nicopace]

Many routers are accesible from outside, so they need to be considered as production servers.
Looking at the logs of dropbear of one of our nodes, I saw that a public IP tried to access the router many many times, and the dropbear allowed it to try all the times (none passed).

One thing that can be done is to add fail2ban in order to reduce the chance for bots to access or to do a DOS to the nodes.

fail2ban is implemented in python, so it is a no-go, but on openwrt they are suggesting to use logtrigger:
https://forum.openwrt.org/viewtopic.php?id=27955

[ilario]

+1
More alternatives:
https://github.com/robzr/bearDropper
https://sourceforge.net/projects/mf2b

[nicopace]

I liked the logtrigger idea, because it will allow us not only to react to fail2ban situations, but also others like the ones we are doing workarounds (cause some of them can be detected on logs):

https://github.com/enryIT/logtrigger

[aparcar]

@nicopace have you tried the tool? It looks nice but 6 years without any development?
We could create a PR to add it to the official OpenWrt packages repo?

[nicopace]

We have been working with @gmarcos87 and @nicoechaniz to filter the current logs of the system in order to clear them and be able to capture those valuable.
We haven't published this (yet), but it is based on rsyslogd's liblognorm: http://www.liblognorm.com/
We also implemented openwrt support for the library... it is still pending to use this tool to take actions based on the logs within the router...

Right now it is only being used to collect the output of the local routers within the networks in argentina, and to filter those logs afterwards in a raspberry pi.

Will have more news soon :)

[ilario]

This would be very good to have, is there any update?
The work with liblognorm in LibreMesh can be found here.

[nicopace]

The current implementation of remotefilteredlog sends ubus messages when a message that wanted to be alerted happens.

Also, doing some skim over https://github.com/enryIT/logtrigger looks old but healthy.

[ilario]

This issue is closely related to this one reported in 2016:
https://lists.libremesh.org/pipermail/lime-dev/2016-December/000821.html

Access to web interface is also dangerous because of #640.

We could:

• do as OpenWrt does with the default firewall package, which is to simply reject all the incoming connections on the WAN ports (but we always deselect the firewall package), do you think is a good idea? @G10h4ck @spiccinini @gmarcos87 @nicopace
  https://github.com/openwrt/openwrt/blob/8fb39f168249f15697ab930245ad08ea66a1b926/package/network/config/firewall/files/firewall.config#L16-L20

Or we can just manage ports 22, 80, and 443:

• always drop HTTP and HTTPS connections incoming from WAN

and either:

• drop SSH connections incoming from WAN only if root password is not set and using some of the fail2ban-like scripts

or:

• always drop SSH connections incoming from WAN

[ilario]

@G10h4ck says it would be good to have the SSH port available for connections from WAN.

We can have the SSH port available from WAN only if we manage to verify that a password is set before allowing the connection.
Does anyone have an idea on how to do this?
I checked out some documentation and is clear that using Dropbox (OpenWrt's SSH server) there's no way to do this.
In my opinion we should just drop everything from WAN by default, and document how to add an exception for SSH in case anyone wants to open it.

@altergui opinions?

[pedro-nonfree]

another approach would be to reject all input that comes from WAN (openwrt vanilla rule), move the ssh port to another place in WAN or avoid exposing dropbear and use wireguard in a random port to access the network from the outside (which is really cool)

And why this is a release-blocker?

[ilario]

I set it as release blocker because I consider it to be a vulnerability, now I saw that @G10h4ck removed it. Actually, it is a vulnerability only in case your WAN has a public IP (e.g. plugging directly the WAN to a modem, like I do at my hometown).

The idea of blocking also uhttpd comes from the hypothesis that FirstBootWizard were to be included in the next release. If so, even if you set an ssh password but you forget to manually disable FBW (setting

lime-packages/packages/lime-docs/files/lime-example

Line 24 in 57565ec

option firstbootwizard_configured false

to true), anyone with access on http port from WAN can wipe your router configuration using FBW (see #640).

Regarding the solutions you propose:

reject all input that comes from WAN (openwrt vanilla rule)

in my opinion this is the best option (and I proposed it in a comment above)
I just noticed that Dropbear has an option which could help with this, without needing the firewall rules, the "Interface" option could be set to br-lan (I did not test, do you think it would be enough?):

https://openwrt.org/docs/guide-user/base-system/dropbear#dropbear

move the ssh port to another place in WAN

Do you mean changing the default ssh port? Nope nope nope no like.

avoid exposing dropbear and use wireguard in a random port to access the network from the outside

Never tried anything like that, but sounds too complex to use for the end user.

[pedro-nonfree]

reject all input that comes from WAN (openwrt vanilla rule)

in my opinion this is the best option (and I proposed it in a comment above)

maybe wan is accepting connections to facilitate meshing and connecting from all interfaces (please, confirm)

but by default openwrt is configured to reject connections from outside to inside (except ping/icmp stuff which is inoffensive), so applying a profile or template or specific role for devices that connect wan to internet would be enough (?). And then, for people that want to connect from outside, that's in general more complex and a howto-script-thing can solve that case in the next round

[dangowrt]

Isn't that just a matter of the firewall zone the interface is living in?

[ilario]

Isn't that just a matter of the firewall zone the interface is living in?

For some reason we never include OpenWrt firewall in LibreMesh builds and build instructions, so the filter on incoming connections from WAN (default in OpenWrt) is not active on LibreMesh.

The firewall rules in OpenWrt seem pretty inoffensive, no idea why we never include it (@G10h4ck ?):

https://github.com/openwrt/openwrt/blob/master/package/network/config/firewall/files/firewall.config

[dangowrt]

The absence of OpenWrt firewall had historic (pre-15.05) reasons from what I understood. Now all lime-system and lime-proto-* also ship with rules and scripts which do make use of the OpenWrt firewall. I have always been using LiMe with fw3, never had any trouble.

[ilario]

Now all lime-system and lime-proto-* also ship with rules and scripts which do make use of the OpenWrt firewall. I have always been using LiMe with fw3, never had any trouble.

I never understood why devs says that we have to deselect the firewall package. @G10h4ck

I would simply filter all the incoming connections from WAN either using the default firewall package of adding the rules in lime-proto-wan and making this configurable in /etc/config/lime-* configuration files.

@spiccinini says that there are setups in the real life in which connections LiMeWAN--LiMeWAN and LiMeWAN--LiMeLAN are used (and they should not!!!!) maybe as an old workaround for #56 (which has finally been fixed in #726).

[ilario]

@nicopace says that WAN-WAN is used for connecting bolsa and quintana networks in order to have layer 3 meshing but not layer 2 meshing (while this is exactly the scope of having the Batman-adv VLAN ID depend upon ap_name and is the reason why #581 cannot be completely solved with the current network design). And on ethernet this will stop working with 0ef3a26

[ilario]

If we really really really don't want to completely block incoming connections from the WAN port (because plenty of users are misusing the WAN port), would it be ok to include the firewall package and add a couple of lines in /etc/config/lime-defaults allowing everything BUT the risky connections (ssh, http, https which are the ones that allow you to change configuration and bruteforce passwords)?
This also means that it gets super easy to configure for the users, as it is manageable in lime-* files.

Something like:

1. include firewall package in suggested packages list;
2. include the following lines in /etc/config/lime-defaults from lime-system package (assuming that zone 1 is always WAN):

config generic_uci_config firewall_wan              
        list uci_set 'firewall.@zone[1].input=ACCPET'
        other_stuff_for_creating_the_filters_for_port_22_80_443_which_I_have_no_idea_how_to_achieve

@spiccinini do you know how we can create a whole new rule with the generic_uci_config system?

[spiccinini]

config generic_uci_config firewall_wan
list uci_set 'firewall.@zone[1].input=ACCPET'
other_stuff_for_creating_the_filters_for_port_22_80_443_which_I_have_no_idea_how_to_achieve

@spiccinini do you know how we can create a whole new rule with the generic_uci_config system?

Yes, using the same uci CLI commands to do that (creating first the config with the type of the config, check https://libremesh.org/docs/es_config.html#generic-configs)
What can't be achieved with generic_uci_config is to create a whole new file in /etc/config/

I like the idea of using a generic config if it can be easily overridable, I also don't know exactly how to create the firewall rules

[ilario]

I think we would need something like this:

https://github.com/openwrt/openwrt/blob/master/package/network/config/firewall/files/firewall.config#L124-L130

https://openwrt.org/docs/guide-user/firewall/firewall_configuration#rules

I did not test:

config rule
	option name		'Reject-wan-ssh'
	option src		'wan'
	option dest_port	'22'
	option target		'REJECT'

config rule
	option name		'Reject-wan-http'
	option src		'wan'
	option dest_port	'80'
	option target		'REJECT'

config rule
	option name		'Reject-wan-https'
	option src		'wan'
	option dest_port	'443'
	option target		'REJECT'

[ilario]

Also consider that plenty of communities have the firewall package anyway, as this is a dependency of LuCI (ref: https://lists.libremesh.org/pipermail/lime-users/2021-June/002003.html ) and LuCI is quite popular between LibreMesh users, seems: https://github.com/libremesh/network-profiles/search?q=luci

[nicopace]

Thanks for bringing that up @ilario !

---

Just as a side comment, as the use of first-boot-wizard is broadening, less people are creating custom network-profiles (so what is reflected in that repo might not be representative now or in the future for references of use of a certain feature).

[ilario]

Let's take a decision on this libremesh/libremesh.github.io#139