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