Unfortunate chain ordering side effect and potential security vulnerability

If I have the following rules defined:

config rule
	option target 'DROP'
	option src 'wan'
        option src_ip '1.2.3.4'  # bad actor on the WAN, no SSH allowed!
	option proto 'tcp'
	option dest_port '22'
	option name 'Block Bad Actor on the WAN to SSH to router'

config rule
	option target 'ACCEPT'
	option src '*'
	option proto 'tcp'
	option dest_port '22'
	option name 'SSH to router'

Those will not do what I want and I expect them to and creates a security vulnerability.

Rather the above two rules (even in the order they are in the file!) results in a rule in the input chain allowing SSH to the router from everyone on the WAN (and every other zone, which is the desired behaviour) that gets put in the chain ahead of the rules which dispatch flow to the per-zone input chains. It is in the per-zone input chain for the WAN (wan_input) where the first rule gets installed, but since it comes after the rule in the input chain (that the second rule above installed), it is never given a chance to be evaluated and effected.

The result is that even despite the ordering of the rules in the config file even, the router is open to SSH from the Bad Actor at 1.2.3.4. Not good.

Further, to mitigate the above one has to proliferate the ACCEPT rule into different rule for every single zone one has and one has to keep adding a new rule every time one adds a new zone (think VPN zone growth, where new users get a zone for the VPN connection to the router -- so something that can be quite dynamic). You end up with a huge list of rules such as:

config rule
	option target 'ACCEPT'
	option src 'lan'
	option proto 'tcp'
	option dest_port '22'
	option name 'SSH to router'

config rule
	option target 'DROP'
	option src 'wan'
        option src_ip '1.2.3.4'  # bad actor on the WAN, no SSH allowed!
	option proto 'tcp'
	option dest_port '22'
	option name 'Block Bad Actor on the WAN to SSH to router'

config rule
	option target 'ACCEPT'
	option src 'wan'
	option proto 'tcp'
	option dest_port '22'
	option name 'SSH to router'

config rule
	option target 'ACCEPT'
	option src 'guest'
	option proto 'tcp'
	option dest_port '22'
	option name 'SSH to router'

config rule
	option target 'ACCEPT'
	option src 'vpn_user_1'
	option proto 'tcp'
	option dest_port '22'
	option name 'SSH to router'

config rule
	option target 'ACCEPT'
	option src 'vpn_user_2'
	option proto 'tcp'
	option dest_port '22'
	option name 'SSH to router'

…

You can see how this can get quite out of hand quite quickly compared to the single rule that should be able to cover all zones but also allow exceptions (i.e. the Bad Actor at 1.2.3.4).

Start with the UCI rule examples and reproduce the observed ordering between the input and wan_input chains. Then inspect how rules are emitted into those chains; done means a specific DROP rule can take effect before a broad ACCEPT rule without requiring duplicate ACCEPT rules for every zone.