1

I've come up with a role based design for provisioning my firewalld zones with Saltstack.

Practically speaking I'm using zones more as logical groups. For instance, all servers in a certain group are allowed to access the Grafana/Influx server (for streaming their data to it).

So I have a firewalld zone called influx_group to which all sources are added automatically based on their role.

One of those servers is an openvpn server, which should also be added to the group internal for SSH access. And then there's the firewall-cmd command giving me an error.

firewall-cmd --add-source=1.1.1.1 --zone=internal
Error: ZONE_CONFLICT: '1.1.1.1' already bound to a zone

Could this be solved with rich rules maybe?

Update 1

The problem in it's simplest form can be resolved by adding a rich rule to the default zone:

firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="1.1.1.1" port port="22" protocol="tcp" accept'

However, that would not solve the design concept of the client/server vs server/client relations and/or groups. Since there's no generic way of deciding when certain sources in defined groups would conflict. And simply conditionally dropping rules in the default zone based on conflict, completely kills the fine granular control of grouping based on service relations.

TL;DR

I choose for this group based setup to be able to do full dynamic provision. It's based on client/server or server/client relations throughout the infrastructure. So the conflict is present for a lot of other service combinations as well.

Combining/grouping sources into higher level zones defeats my aim of this level of granularity. Thus combining more ports into the same zones, risking access to ports that should not be.

Anybody got any insight on this?

Thanks!

GerardJP
  • 985
  • 2
  • 9
  • 20

1 Answers1

0

Interfaces (network interface cards) and sources (your machines with dedicated ip addresses) can only be bound to one zone. That's it. It is meaningful, because same set of sources can not be found in different level of hostile environment. Besides this setup helps leveled or leveled defence. You should carefully read Understanting Linux Firewall in multizone konfigurations

Give the interface to more strict zone which may be public. Then add resources to the level of trust to the corresponding zones. Check the services and ports that must be available in the zones for these specific sources.

They will be all active. Source zones will have precedence. If sources are not matched interfaces rules will be applied. If interface zone does not handle the traffic based on the default target of the zone, it will be drop, rejected etc. Make sure you read the link.

benibilme
  • 77
  • 1
  • 6