On Wed, Sep 4, 2019 at 5:46 AM Nicolas Mailhot via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > 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 You're trying to outsmart what other people want with a technological procedure. Since sshd is a lethally dangerous protocol to expose by default in the world of rootkitted hosts and stolen passwords, and is one of the ports which should *most* be cut off from exposure to the world at large, well, the premise of exposing it by default fails immediately. Yes, it's pretty much the only place to start with cloud based machines, but one of the first security steps there is to activate some kind of firewally to restrict access to your internal network only. > 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. Please, stop trying to treat the workstation as a fundamentally different case. It's not. Let's leave the firewall on by default, to encourage our users to actually learn about their systems and to leave them in a considerably safer state at system installation. _______________________________________________ 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
