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 <egarver(a)redhat.com>
Sent: 05 May 2023 17:29
To: Furnell, Will (STFC,RAL,SC) <will.furnell(a)stfc.ac.uk>
Cc: firewalld-users(a)lists.fedorahosted.org
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 <egarver(a)redhat.com>
> Sent: 05 May 2023 13:51
> To: Furnell, Will (STFC,RAL,SC) <will.furnell(a)stfc.ac.uk>
> Cc: firewalld-users(a)lists.fedorahosted.org
> 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 <egarver(a)redhat.com>
> > Sent: 04 May 2023 20:58
> > To: Furnell, Will (STFC,RAL,SC) <will.furnell(a)stfc.ac.uk>
> > Cc: firewalld-users(a)lists.fedorahosted.org
> > 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
> >
>