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

[Eric Garver]

On Tue, May 09, 2023 at 12:24:27PM +0000, Will Furnell - STFC UKRI wrote:
> As far as I can see the interface is already assigned to the public zone:
>
> root@ginny /etc/firewalld/zones $ firewall-cmd --zone public --add-interface ens192
> Warning: ZONE_ALREADY_SET: 'ens192' already bound to 'public'
>
> And if I assign the source ipset to the public zone - then won't
> _only_ the IPs in the source ipset be allowed access - like how the
> Icinga zone works currently?
>
> Apologies - I meant to say - is there not an easy way to allow only certain IP addresses to access a port but allow them (and anyone else) unrestricted access to all other ports? Of which there might be quite a few?

Another alternative is a rich rule.

# firewall-cmd --permanent --zone <zone> \
  --add-rich-rule='rule family=ipv4 source address=<addr> service name=<service> accept'
> e.g. allow *anyone* (including 192.168.1.2) to access services http, https (public zone)
> only allow 192.168.1.2 to access service ssh (special zone)

Yeah. Below allows http/https to 192.168.1.0/24. But only allows
192.168.1.2 to access ssh. Only the public zone is used here.

# firewall-cmd --permanent --zone public --add-source 192.168.1.0/24s
# firewall-cmd --permanent --zone public --add-service http
# firewall-cmd --permanent --zone public --add-service https

# firewall-cmd --permanent --zone public \
  --add-rich-rule='rule family=ipv4 source address=192.168.1.2 service name=ssh accept'
> Thanks,
>
> Will.
>
> -----Original Message-----
> From: Eric Garver  
> Sent: 05 May 2023 17:29
> To: Furnell, Will (STFC,RAL,SC) 
> Cc: [e-mail]
> Subject: Re: Evaluating monitoring rules in multiple zones (public and another zone)
>
> On Fri, May 05, 2023 at 03:31:22PM +0000, Will Furnell - STFC UKRI wrote:
> > A source to what, sorry? I can't see that policies can have 
> > sources/interfaces set. (This is v1.1.1 on EL9)
>
> I meant assign the source/interface to the public zone.
> > There's really no easy way to only allow certain IP addresses to 
> > access certain services on a system?
>
> There is. That's what your icinga zone does.
> > Thanks,
> >
> > Will.
> >
> > -----Original Message-----
> > From: Eric Garver 
> > Sent: 05 May 2023 13:51
> > To: Furnell, Will (STFC,RAL,SC) 
> > Cc: [e-mail]
> > Subject: Re: Evaluating monitoring rules in multiple zones (public and 
> > another zone)
> >
> > On Fri, May 05, 2023 at 09:06:59AM +0000, 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. 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,
> >
> > This is a bug with policies. :(
> > Policies were not considering the default zone when classifying traffic.
> >
> > It's fixed on the latest upstream master branch. (next release)
> >
> > As a workaround for older release you'll either need to assign a source/interface.. or duplicate your service to both zones. Sorry.
> > > 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