Le 2019-09-03 18:52, Kyle Marek a écrit :
Additionally, binding to a specific address does not handle dynamic
networks very well.
Simplify that to binding to a specific address does not handle network
very well, since everything is dynamic nowadays, on desktops, phones or
servers (servers via vlans, binding, teaming, etc).
Having every single networked app handle dynamic network changes on its
own does not scale.
There are not so many ways to handle this:
1. have every app bind to null, and hope the firewall filters out
dangerous accesses. You'll get a *lot* of app collisions, because every
app will fight for 443 ownership. And as soon as the firewall is down,
the king has no clothes.
2. have every app bind to a private exotic or dynamic port, and map
those to public well-known ports on the correct address and network at
the firewall level. That's the usual strategy for containers set up by
people with no network understanding, because they can not imagine more
than one address per container. They forget that this will break all
network management/inspection tools, because no network port will make
any sense to tools anymore, and unless they go to full dynamic, their
exotic ports will collide too because their choices are obvious and dumb
(80xxx usually). And it requires some out of band data telling the
firewall what the well-known port for each private port should be
(complex mapping). Again, as soon as the firewall is down, the king has
no clothes.
3. only bind to null apps actually intended to be exposed everywhere
(sshd). Have every other app (containerized or not) use standard fixed
well-known ports, but give each one a loopback address, and map public
addresses+well-known port to the correct loopback address+same
well-known port at the firewall level. It is safe (if the firewall goes
down, the mappings go down with it, nothing is exposed). It is
manageable (network flows use standard ports tools know about; the
firewall does not need to learn complex port mapping, just what private
ip owns the public port associate to a specific public networks; and the
usual collision of 443 requests can be easily handled at layer set by
deploying apache+mod-proxy on one of the private addresses).
Using 3., there is not need to ask users to answer complex questions
about network ports (because all the network ports are standard,
well-known port, preset by upstream/the packager). The user only needs
to decide if an app should be exposed to a particular network (or zone)
and then the firewall can just map the ports used by this app on its
loopback address on the same ports on the public addresses used by the
system in this zone.
Making 3. work for the workstation case just needs some way to tell an
app what system-specific loopback it should use, and some way for the
app to declare to the firewall the well-known ports it wants, which is
the kind and level of complexity systemd already manages.
Regards,
--
Nicolas Mailhot
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
