[sle-beta] firewalld with subzones

Vincent Moutoussamy vmoutoussamy at suse.com
Mon Apr 9 07:51:49 MDT 2018


> On 6 Mar 2018, at 00:02, Luiz Angelo Daros de Luca <luizluca at tre-sc.jus.br> wrote:
> Hello,
> While porting exising SuSEFirewall2 confs to firewalld, things started to get complicated.
> With SuSEFirewall2, admin can create a service file opens ports to specific source clients.
> /etc/sysconfig/SuSEFirewall2 is kept simple, only defining interface zones and enabling services for each zone.
> I had to repeat multiple times the same source addresses for different services but, at least, everything was contained inside
> a single service file. I rarely depended on direct iptables calls inside custom script.
> Now arrives firewalld.
> Services in firewalld are much simpler definitions. There is no such thing as source address filtering.
> Source is only filtered by "source zones", "rich rules" or "direct rules". First I though "source zones" was the way to go.
> I could define multiple source_zones like "production", "remote sites", "local site". It would improve the "repeat multiple times
> the same source addresses" that I faced with SuSEFirewall2. Now things gets complicated.
> "Zones" in firewalld cannot overlap (https://github.com/firewalld/firewalld/issues/295, https://github.com/firewalld/firewalld/issues/192, https://github.com/firewalld/firewalld/issues/149).
> If a source zone matches source address, the connection passes through its rules. If nothing matches inside those zone rules, firewalld checks the zone "target", which
> could accept, reject/drop or default. All of them are final but default which will send processing back to INPUT chain. The next thing it will test will be the interface zone or the default zone.
> So, once a connection matches a source zone, no other source zone will be checked.
> I could order source zones in a special sequence. I would need to prefix zone name with number (https://github.com/firewalld/firewalld/issues/224, https://github.com/firewalld/firewalld/issues/166), something like 10_production, 20_servers, 30_localsite, 40_intranet. Anyway, as only the first source zone that matched is processed. If I add a service all my intranet but not to extranet, I would need to add it to all zones (10_production, 20_servers, 30_localsite, 40_intranet). If you add a new subzone, you need to add every single service open in "broader zones" to it. It gets exponentially complex with more services/zones.
> The second option is to avoid "source zones" and use rich rules in the default zone, while "source zones" addresses become ipsets. However, now I get just a bunch of rules, without a contained organization. Rich rules does not even have a name/id that would help with scripts. And rich rules uses always the sequence "deny, allow", there is no other rule sequence. I can still reference services but not much besides that. Direct rules gives me back sequence, but only between direct rules, and it removes the little abstraction that remained. They always goes before "rich rules" and "services". It seems that with firewalld I get a layer of complexity over iptables without abstractions that simplify configurations.
> Firewalld zones seems to be designed with desktop environment in mind. I can open a service when at work, at home, but leave it closed in public. For enterprise, zones did not really help.
> It can do the job for simple "open ports/services for all", but it gets in the way when you need to filter "by source", specially when you have multiple layers.
> The multiple open issues at github related to "source filtering"/"rules/zone order" show that some features are still missing in firewalld and users are trying to (ab)use the existing features the wrong way.

Sorry for the late response, do you still struggle to get things done with
firewalld? I’m not a firewalld expert but please give me your latest feedback
and I will try to help!

Did you take a look at our firewalld documentation?

> I know RHEL aready uses firewalld for some time. However, they kept a iptables-service for when firewalld gets in the way. What can I use with SLE15 besides firewalld? SuSEFirewall2? Can I still depend on SuSEFirewall2 during SLE15 suport (even on ServicePacks)?

Well no SuSEFirewall2 should be removed completely from SLE15.

> Regards,

Vincent Moutoussamy
SUSE Beta Program and SDK Project Manager

> --
> Luiz Angelo Daros de Luca
> _______________________________________________
> sle-beta mailing list
> sle-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sle-beta

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.suse.com/pipermail/sle-beta/attachments/20180409/75d2ff6e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.suse.com/pipermail/sle-beta/attachments/20180409/75d2ff6e/attachment.sig>

More information about the sle-beta mailing list