I am working on a project to make a admin and a data VLAN.
Wrt3200acm and 21.02-rc3.
But when I change in LuCi the Dropbear listening interface from lan to admin then dropbear doesn’t hear the admin interface and lan interface continues to work.
Tried a reboot and no change.
This would have made more sense if both interfaces stopped working for dropbear.
Ok for the admin not working since I am still working on this project but why do the LAN continue to work since I can only choose one interface or all in dropbear settings!?
Do I also need to make a firewall rule for port 22 in the admin interface for dropbear?
Looked at both dropbear and uhttpd and both listen on 0.0.0.0:*
I have set dropbear listening on admin interface. And uhttpd listening on https “admin IP”:443.
In some way it work but not as expected. I can be in any firewall zone that has Input=accept and pretend to be in admin interface just by typing the admin interface IP and the port 22, 80 or 443. And voila we are connected😃.
If i change the admin firewall zone Input=accept then both LAN and Admin interface now works.
So the system connection (port 22, 80 and 443) to the router is only controlled by the firewall and not any uhttpd and dropbear settings at all.
That is not what is written in the user guide for hardening dropbear and router access.
It actually doesn’t mention firewall settings at all for access hardening!?
The "0.0.0.0:*" you see on listening sockets is because they aren't connected to any remote endpoint. They also should have a local IP address, which can be 0.0.0.0, and a port. But the interface setting might not do what you expect anyway. It's used to decide which IP addresses dropbear should listen on. But it doesn't limit from which interfaces access is allowed. This is because of the weak host model which is implemented by OpenWrt and other Linux based operating systems:
If the IP stack is implemented with a weak host model, it accepts any locally destined packet regardless of the network interface on which the packet was received.
It seems that to control who can do the actual system connection it seems most stable to combine the firewall to specify which interface that are able to connect to the router.
And to regulate what IP address the client on that interface actually is allowed to use the dropbear and uHTTPd listening settings work best.
I haven dig down in this that much earlier but OpenWRT use quite different way of management connection than other network devices which often have this as VLAN controlled?
With the dropbear configuration you determine, on which interfaces and ports dropbear is listening. It does not determine, what traffic goes to dropbear. That's regulated by the firewall rules. Both - dropbear configuration and firewall rules - must fit together.
Dropbear doesn't listen on an interface but on IP addresses and ports. It's the OpenWrt init file which generates a list of IP addresses based on the interface that is configured in UCI.
There is a way in linux to bind to a network interface (SO_BINDTODEVICE), but dropbear doesn't support that. Openssh supports SO_BINDTODEVICE which allows you to configure a management VRF and bind the openssh server to that VRF.
Support for VRF in OpenWrt would be nice I guess. There was a feature request in the issue tracking system.
Not according to the user guide for Dropbear and user guide for security hardening and LuCi, they specificly say that Dropbear only listens to specified interfaces!