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 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] >> 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".
