On 23/02/2019 18:18, Tom Eastep wrote:
There is also an historical element. Prior to the introduction of the EXPAND_POLICIES option, all->z, z->all and all->all policies were enforced in chains all-z, z-all and all-all respectively. This is still the case when EXPAND_POLICIES=No. The code takes the same path when EXPAND_POLICIES=Yes, then "expands" the policy into the effected Zi-Zj chains, while leaving the original policy chain in the configuration (to be optimized out later). That is done exactly to catch multiple policies with the same SOURCE and DESTINATION columns. I didn't change that when I introduced zone exclusion and it isn't clear that I want to.
Ok it's clearer to me now. I always used EXPAND_POLICIES=Yes because it helps tremendously with debugging any situation.
Well, I can live with the current situation without trouble. I asked the zones exclusions feature as a comfort thing, nothing more. Every time I have to add a new zone, I would just declare it in the "zones" file instead of having to also remember to add/declare it to the "policy" files. It would become fully dynamic, humans tend to err a lot, computers don't :-)
In case some day you have some time to lose and working on Shorewall itches you again, I wouldn't mind a patch to accommodate with the EXPAND_POLICIES=Yes. But, I repeat, I can live with the current status, I just have to pay a little bit more attention when adding a new zone.
This issue could be revisited, but certainly not in a patch release as the change would need wider testing than I myself can provide. I will go ahead and release the patch that I sent you, as that is an obvious bug.
I can do all the needed testing if you wish. I manage quite a bunch of different servers and several of them have more than 5 zones. 11 zones is for now the maximum I've reached and I'm still amazed how, with all that, Shorewall's working absolutely smoothly while maintaining a very readable configuration!
My own feeling is that an intra-zone policy other than ACCEPT is a rare requirement (and such cases can be handled with explicit policies). The most common case would be net->net, especially where there are multiple uplinks . Otherwise, if hosts in the same zone aren't supposed to communicate, then why are they in the same zone in the first place. I believe that inter-zone traffic can be handled in the way that you want, without any further change.
I use zones in a very different way. I'm a big fan of strict compartmentalization and Shorewall is helping in a way I couldn't live without :-)
Each of my servers is heavily firewalled where only the strictly needed traffic is allowed. I use an LXC container for every single service and thanks to its lightness, the density per server is quite high. Every different project and/or domain name comes with its set of containers. Each set gets a separate zone.
So, inter-zone traffic is not possible as there's hardly any reason for host1@z1 needs to talk to host1@z2 except for very specific cases.
On top of that, intra-zone is very strictly controlled too. Let's say project A, using zone 1, needs "php", "mysql", "anonftp", "smtp" and "imap" services. Only "php/smtp/imap" can talk to "mysql" and only on relevant ports. "anonftp" have no business talking to any of its siblings. "smtp" only talks to "imap" via LTMP (24/tcp) for delivery, etc, etc. The host can SSH to any container but no container can SSH any other container nor the host.
This of course an over simplified example. In reality, my setups are way more complex than this but Shorewall's doing a hell of a good job managing all this complexity in apparent simplicity. Adding a new service is a matter of at most 2~3 new lines on Shorewall's configuration depending on the needs. Amazes me every time!
Some of these containers provide services accessible from the wild Internet. In case a container gets compromised, thanks to Shorewall (and AppArmor and other measures), the intruder would be trapped there without being able to reach anything else, local or remote.
That's why I need both inter and intra zones strict control and Shorewall manages that more than brilliantly!
So yes, "all!${FW},net" would be a neat feature to totally mimic "z1,z2,..,zN" in "policy" but I can live happily without it. Shorewall currently works like a charm.
To quote Arthur C Clarke : Any sufficiently advanced technology is indistinguishable from magic. It fits to what Shorewall is doing from my point of view :-) -- ObNox _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
