miniupnpd: fw3 integration places MINIUPNPD chain at the top

[f00b4r0]

As illustrated below, the miniupnpd firewall3 integration brings the MINIUPNPD chains at the very top of the parent chain (for prerouting, postrouting and forward).

This has the potential of enabling UPnP clients to override locally set port redirections, as illustrated in the following example (for prerouting).

I believe the local port redirections should always have priority and MINIUPNPD chains always be last, as also evidenced by the "iptables_init.sh" script provided by miniupnpd upstream which appends (-A) these chains instead of inserting them at the top (-I 1).

HTH

Chain zone_wan_prerouting (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   14  1386 MINIUPNPD  all  --  any    any     anywhere             anywhere            
   14  1386 prerouting_wan_rule  all  --  any    any     anywhere             anywhere             /* !fw3: user chain for prerouting */
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere             tcp dpt:10100 /* !fw3: HTTP */ to:192.168.0.100:80

[ldir-EDB0]

Did you have any thoughts on how to attack this problem?

[f00b4r0]

@ldir-EDB0 other than fixing the code so that the MINIUPNPD chain ends at the bottom? No 😛

As far as I'm concerned this is a security issue and I'm surprised nobody seems to care...

[ldir-EDB0]

I understand your concern ;-) jow & I are looking at it.

[pprindeville]

So what's the downside of adding the hooks at the end of the chains?

[jow-]

So what's the downside of adding the hooks at the end of the chains?

It complicates the ruleset even further, causes increased cpu usage and this particular issue can be solved without adding extra hooks.

[ldir-EDB0]

"So what's the downside of adding the hooks at the end of the chains?" I take it you mean putting the user pre_routing_wan rule at the end of the chain? Yes if fw3 added a user 'penultimate' before its generate DNAT rule then miniupnpd could live there, but that requires a change to fw3 and all of jow's comments apply.

[ldir-EDB0]

This was addressed by openwrt/packages#6001

[f00b4r0]

Haven't tested the updated package but I'll take your word that it solves this issue 😉