Re: Evaluating monitoring rules in multiple zones (public and another zone)

[Andrei Borzenkov]

On 05.05.2023 12:06, Will Furnell - STFC UKRI wrote:
> Thank you very much - unfortunately that has not solved my problem - for example, I have port 22 for SSH open in the public zone, which has no source restrictions:
>
> <zone>
>    <short>Public</short>
>    <description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
>    <service name="ssh"/>
>    <service name="dhcpv6-client"/>
>    <service name="cockpit"/>
>    <forward/>
> </zone>
>
> And the Icinga zone as in previous emails, and the new policy as follows:
>
> <policy target="CONTINUE">
>    <service name="icinga"/>
>    <ingress-zone name="icinga"/>
>    <ingress-zone name="public"/>
>    <egress-zone name="HOST"/>
> </policy>
>
> But it still seems that the servers in the icinga ipset cannot SSH to the server that has this firewall - they _only_ are allowed to access the icinga service.

Of course. Why you expected anything else? SSH port is still allowed 
only by zone "public". Packets entering via zone "icinga" *also* are 
allowed service "icinga" via policy rules, but service "icinga" is 
already allowed by zone "icinga" so you did not add anything new. But 
policy definition does not cause rules for zone "public" to be applied 
to packets entering via zone "icinga". Remember, packet can belong to 
one zone only.

For this to work you need to move ports from zone "public" into this 
policy. Basically, zone "public" will then be used just to tag incoming 
packets and decision will be taken by policy rules. See my other e-mail 
and reply from Eric.

The downside of this approach is that to drop in zone "icinga" you must 
have policy that mentions zone "icinga". While if source zones supported 
target=CONTINUE, such zone definition would be self-contained. To be 
honest, I do not see source zones as security boundary, rather as 
convenient abstraction, so I do not think zone drifting applies here.

Having policy mentioning non-existent zone does not do any harm as is, 
but it looks "untidy". Also if you would ever need to add another source 
zone for different set of source addresses/services you would need to 
modify policy definition on every host.
> Basically I want to restrict who can access the icinga port, but otherwise let any servers, including the icinga servers themselves, access any other services - and do this in a way that allows me, the monitoring admin to only need to drop in XML files or something similar via an RPM,
>
> Thank you,
>
> Will.
>
> -----Original Message-----
> From: Eric Garver 
> Sent: 04 May 2023 20:58
> To: Furnell, Will (STFC,RAL,SC) 
> Cc: [e-mail]
> Subject: Re: Evaluating monitoring rules in multiple zones (public and another zone)
>
> On Thu, May 04, 2023 at 01:18:27PM +0000, Will Furnell - STFC UKRI wrote:
> [..]
> > Is there a way to get firewalld to evaluate rules in multiple zones in
> > a chain like icinga -> public -> DENY?
>
> No. But you can use a policy to common-ize some things. The below policy applies to both zones, icinga and public.
>
> e.g.
>
> # firewall-cmd --permanent --new-policy mypolicy # firewall-cmd --permanent --policy mypolicy --add-ingress-zone icinga # firewall-cmd --permanent --policy mypolicy --add-ingress-zone public # firewall-cmd --permanent --policy mypolicy --add-egress-zone HOST # firewall-cmd --permanent --policy mypolicy --add-service cinga # firewall-cmd --reload
>
> Then you could add your unique services, e.g. https, to the public zone or a separate policy.
>
> Hope that helps.
> Eric.
>
> https://firewalld.org/documentation/concepts.html
> https://firewalld.org/2020/09/policy-objects-introduction
> _______________________________________________
> firewalld-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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.fedorahosted.org/archives/list/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue