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
