firewalld-users May 2023

firewalld-users@lists.fedorahosted.org

5 participants
9 discussions

Question re: Nat & Port Forwarding: Use Policy Objects, or Attach to Zones?
by Joshua Kramer 30 May '23

30 May '23

Hello, It looks like there are a couple of ways to do port forwarding in NAT situations: either put the rules in the Zone itself, or use a Policy Object and put the port forwarding rules in the Policy Object. Which is the "right" way to do it for this situation? I have an appliance I'm building a firewall out of. There are several Ethernet interfaces. For this particular issue, two are important: eth0 is the interface that is connected to the Internet, and eth1 is connected to a VPN server. eth1's network addr is 192.168.9.1 and the VPN server is 192.168.9.2. When a UDP connection arrives on port 1195 on eth0, I want it to be forwarded to 1194 on eth1 to 192.168.9.2. The Zone I have for eth0 is 'external' and the Zone I have for eth1 is 'vpnbox'. The 'external' Zone is set to masquerade. If I put the rule in the 'external' Zone, nothing happens- the connection is not forwarded. This is true even if I open firewall holes in that Zone. If I put the rule in a policy object with 'external' Zone as ingress and 'vpnbox' Zone as egress, I can't reload firewalld after creating the policy. It comes back with an error, "INVALID_ZONE: Policy 'worldToVpnBox': 'forward-port' cannot be used because egress zone 'vpnbox' has assigned interfaces". I did see this link, but it doesn't seem right that the rule should apply to ANY zone. Isn't that a security risk or a potential for a misconfiguration? https://firewalld.org/2020/09/policy-objects-filtering-container-and-vm-tra… I am new to firewalld Policy objects and would greatly appreciate if someone could refer me to resources that would answer this question. Thanks! -JK

3 2

Re: Evaluating monitoring rules in multiple zones (public and another zone)
by Eric Garver 09 May '23

09 May '23

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 > > > > > >

1 0

Re: Evaluating monitoring rules in multiple zones (public and another zone)
by Eric Garver 09 May '23

09 May '23

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 > > >

2 1

Re: Evaluating monitoring rules in multiple zones (public and another zone)
by Andrei Borzenkov 05 May '23

05 May '23

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 <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 > _______________________________________________ > firewalld-users mailing list -- firewalld-users(a)lists.fedorahosted.org > To unsubscribe send an email to firewalld-users-leave(a)lists.fedorahosted.org > 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/firewalld-users@lists.fedoraho… > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

1 0

Re: Evaluating monitoring rules in multiple zones (public and another zone)
by Eric Garver 05 May '23

05 May '23

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 >

2 1

Re: Evaluating monitoring rules in multiple zones (public and another zone)
by Eric Garver 05 May '23

05 May '23

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

3 3

Re: Evaluating monitoring rules in multiple zones (public and another zone)
by Andrei Borzenkov 04 May '23

04 May '23

On 04.05.2023 16:18, 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, that's not possible. Each packet is associated with one rule only (technically rules are applied sequentially and the first matching rule wins) and each zone is terminal - it gives final verdict.

1 0

Evaluating monitoring rules in multiple zones (public and another zone)
by Will Furnell - STFC UKRI 04 May '23

04 May '23

Hello, We use a monitoring service (Icinga) that listens on port 5665. We would like to restrict this access to this port to two servers, and I have achieved this with an ipset and a zone (anmed icinga) as follows: <ipset type="hash:ip"> <entry>192.168.1.1</entry> <entry>192.168.1.2</entry> </ipset> <service> <port port="5665" protocol="tcp"/> </service> <zone> <service name="icinga"/> <source ipset="icinga"/> </zone> However, we also use a public zone that has ports such as http and https open. I would like the monitoring servers to be able to _also_ access the web pages on the server, but I don't want to do this by adding these rules to the icinga zone - as then I'm going to end up with duplication and may end up with inadvertently leaving firewall holes open by having the rules in two zones. What would the best way to achieve this please? By doing the monitoring bits as separate services and zones it allows these xml files to be dropped onto many servers without needing to edit the main public zone - and as far as I can see to restrict based on source IP I need to do that in a separate zone? Is there a way to get firewalld to evaluate rules in multiple zones in a chain like icinga -> public -> DENY? Thanks, Will.

1 0

How to get snmpget responses over IPv6 with active firewall
by Thomas Zimmermann 02 May '23

02 May '23

Hi, I'm trying to get snmp v3 request working over IPv6 with active firewall on Rocky Linux 8. Get request over IPv4 are working fine over 161/udp with active firewall (on the client side). But when I do a request to the same host over IPv6 no answer is received. After shutting down the firewall, on the client side, also request over IPv6 are working fine. For testing purposes I've added a source port rule to my clients firewall: firewall-cmd --add-source-port=161/udp After adding this rule, the answers are received. But I don't want to allow every 161/udp source port and can not add a rule for every host. Do you know why UDP responses over IPv4 are received, but not over IPv6? Kind regards, Thomas

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

firewalld-users May 2023