Re: [iptables PATCH 9/9] extensions: DNAT: Support service names in all spots

[Phil Sutter <phil@nwl.cc>]

On Thu, Mar 31, 2022 at 02:19:51AM +0200, Jan Engelhardt wrote:
> On Wednesday 2022-03-30 22:57, Phil Sutter wrote:
> >> >+-p tcp -j DNAT --to-destination 1.1.1.1:echo-ftp-data/ssh;-p tcp -j DNAT --to-destination 1.1.1.1:7-20/22;OK
> >> 
> >> This looks dangerous. It is why I originally never allowed service names in
> >> port ranges that use dash as the range character.
> >
> >Guess if someone is able to manipulate /etc/services, any service names
> >are problematic, not just in ranges.
> 
> Well, pretty much anyone has a shot at manipulating this file. File a
> port registration with IANA, and when your distro updates the file,
> eventually there is a chance of messing up firewall configs,
> worldwide.
> 
> Other than that, thanks to nsswitch, the service list can also be in
> LDAP or so, and then all that's needed is a disgruntled LDAP admin
> who dislikes the firewall admin.
> 
> >Another potential problem I didn't have in mind though is that 'a-b'
> >could mean [a; b] or [a-b] assuming that all three exist. But I haven't
> >found a valid example in my /etc/services, yet. :)
> 
> I found 25 at once!
> 
> 914c :: 914c-g :: g-talk
> ads :: ads-s :: s-openmail
> bctp :: bctp-server :: server-find
> cis :: cis-secure :: secure-mqtt
> connect :: connect-server :: server-find
> docker :: docker-s :: s-openmail
> documentum :: documentum-s :: s-openmail
> domain :: domain-s :: s-openmail
> dtp :: dtp-net :: net-device
> genie :: genie-lm :: lm-mon
> linktest :: linktest-s :: s-openmail
> mailbox :: mailbox-lm :: lm-mon
> mbap :: mbap-s :: s-openmail
> ns :: ns-server :: server-find
> plato :: plato-lm :: lm-mon
> rmonitor :: rmonitor-secure :: secure-mqtt
> sentinel :: sentinel-lm :: lm-mon
> sitewatch :: sitewatch-s :: s-openmail
> spss :: spss-lm :: lm-mon
> sql :: sql-net :: net-device
> tacacs :: tacacs-ds :: ds-slp
> tl1 :: tl1-lv :: lv-auth
> trim :: trim-ice :: ice-router
> wnn6 :: wnn6-ds :: ds-slp
> wsdapi :: wsdapi-s :: s-openmail

Your /etc/services seems to be much larger than mine, many of those
don't exist in my case.

> To be read as: "wsdapi-s-openmail" is ambiguous, because
> it allows for two interpretations (and all four port names are in
> /etc/services):
> 
> 	[wsdapi]-[s-openmail]
> 	[wsdapi-s]-[openmail]

OK. My code preferred the latter, checking if the former is possible is
a poor workaround. The only difference it makes is rules get rejected
instead of changing behaviour silently.

> >> The "solution" would be to use : as the range character, but that would require
> >> a new --dport option for reasons of command-line compatibility.
> >
> >Well, we could allow both (a-b with numeric a and b only) and use it in
> >output only if non-numeric was requested.
> 
> Given I'm seeing "914c" in the IANA list (leading digits always stand
> out from the crowd, e.g. you don't normally see them in UNIX
> usernames either), I won't hold my breath that no one would try to
> register "914-915".

That's an interesting point: "914c" is not usable in iptables. The code
tries strtoul which succeeds for "914", "c" is then rejected as illegal
remainder. To fix that, we had to consult getservbyname() first which is
a performance hit. Guess the whole "support users with bad number
memory" game is best effort, only.

I'll submit a v2 without the experimental "names in ranges" patch in a
minute.

Thanks, Phil