Say I want to drop/reject outgoing connections to a particular destination address (for parental control). How would I do this with firewalld?
I tried
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' protocol value="tcp" destination address='aa.bb.0.0/16' reject"
firewall-cmd --reload
Then,
firewall-cmd --zone=FedoraWorkstation --list-all FedoraWorkstation (active) target: default icmp-block-inversion: no interfaces: enp8s0 sources: services: dhcpv6-client ftp mdns mountd nfs rpc-bind samba-client ssh ports: 1025-65535/udp 1025-65535/tcp protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv4" destination address="aa.bb.0.0/16" protocol value="tcp" reject
does show that the rule was added. However, I was still able to connect to the destination with no issues.
In the past I did that with iptables and I can probably still do that now, but I think nowadays we're supposed to use firewalld, via firewall-cmd or firewall-config.
The problem with firewalld is that it has zones, which are defined based either on network interfaces or on IP sources (or ranges), but not on the destination IP. See e.g. https://www.linuxjournal.com/content/ understanding-firewalld-multi-zone-configurations . What I need is to filter based on the destination address.
I found this post saying that it's actually not easy to filter based on destination address with firewalld, and that we'd have to use firewall-cmd --direct to inject the filter rule directly into iptables:
https://serverfault.com/questions/918754/firewalld-stop-outgoing-traffic- to-a-particular-ip-address
But then, the documentation for firewalld.direct says this is deprecated.
What I think needs to happen is this: 1. duplicate the default zone (Fedora Workstation) to, say, Parental Control 2. In the Parental Control zone add the drop rule to the specific destinations 3. switch between Fedora Workstation and Parental Control as needed.
How can this be done?
On Sun, Jun 18, 2023 at 2:15 PM Amadeus WM via users users@lists.fedoraproject.org wrote:
Say I want to drop/reject outgoing connections to a particular destination address (for parental control). How would I do this with firewalld?
I can't address using firewalld, but I think you could get basically the same result by adding route entries; i.e. route the destination address/network to 127.0.0.2 or similar. I did this many years ago under Solaris.
On 6/18/23 11:15, Amadeus WM via users wrote:
Say I want to drop/reject outgoing connections to a particular destination address (for parental control). How would I do this with firewalld?
How about bypassing firewalld and using iptables directly to add a rule to the kernel?
iptables -A OUTPUT -d address-to-ignore/xx -j DROP
On 18 Jun 2023, at 23:26, Mike Wright nobody@nospam.hostisimo.com wrote:
How about bypassing firewalld and using iptables directly to add a rule to the kernel?
Does firewalld not remove that rule or otherwise make this unreliable?
Sure, like I said, it can be done with iptables. But:
1. Why do we have firewalld then? It seems to me that such a trivial thing should be configurable with firewalld.
2. The command that I tried
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' protocol value="tcp" destination address='aa.bb.0.0/16' reject"
didn't put anything in iptables, i.e. iptables --list shows no rules. On the other hand, I do have this reject rule in /etc/firewalld/zones/ FedoraWorkstation.xml.
Under the hood, by default, firewalld uses the newer nftables instead of iptables. I don't know how these two interact, if anything maybe we should do this in nftables.
On Sun, 18 Jun 2023 15:26:16 -0700, Mike Wright wrote:
On 6/18/23 11:15, Amadeus WM via users wrote:
Say I want to drop/reject outgoing connections to a particular destination address (for parental control). How would I do this with firewalld?
How about bypassing firewalld and using iptables directly to add a rule to the kernel?
iptables -A OUTPUT -d address-to-ignore/xx -j DROP
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.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.fedoraproject.org/archives/list/
users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 19 Jun 2023, at 13:27, Amadeus WM via users users@lists.fedoraproject.org wrote:
Under the hood, by default, firewalld uses the newer nftables instead of iptables. I don't know how these two interact, if anything maybe we should do this in nftables.
That is configurable. It defaults to the nftables backend on new installs. I force it to iptables because i force in an iptables rule in my setup.
In the kernel iptables is implemented by a compatibility layer by nftables i think.
On Jun 19, 2023, at 12:20, Barry barry@barrys-emacs.org wrote:
That is configurable. It defaults to the nftables backend on new installs. I force it to iptables because i force in an iptables rule in my setup.
In the kernel iptables is implemented by a compatibility layer by nftables i think.
Regardless of which iptables you use, you aren’t going to see firewalld (using the nft backend) or nft rules in the output of iptables commands.
-- Jonathan Billings
Once upon a time, Amadeus WM amadeus84@verizon.net said:
- The command that I tried
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' protocol value="tcp" destination address='aa.bb.0.0/16' reject"
One quirk of fireall-cmd is that there are two distinct modes - one that operates on the stored configuration (with --permanent) and one that operates on the running config (without --permanent). When you make a change with --permanent, it is stored, and will take effect on future boots, but it is not applied to the current config. You need to run the same command without the --permanent to apply to the current running config.
Alternately, you can make all your changes to the running config (no --permanent), and then store them all at once with firewall-cmd --runtime-to-permanent (but if you have something making dynamic changes, like fail2ban for example, that would get stored as well). Or you can make all your changes to the permanent config and then load them to running all at once with firewall-cmd --reload.
didn't put anything in iptables, i.e. iptables --list shows no rules. On the other hand, I do have this reject rule in /etc/firewalld/zones/ FedoraWorkstation.xml.
iptables only exists as a compat layer on top of nftables, and not everything in nftables will be reflected in the output of iptables. To see the full nftables running config use "nft list ruleset".
If you are going to use firewalld, you need to either _only_ use firewalld, or use nft with separate rulesets along side the firewalld managed rulesets. Trying to mix in iptables rules is unlikely to work how you'd like.
On 6/19/23 11:07, Chris Adams wrote:
Once upon a time, Amadeus WM amadeus84@verizon.net said:
- The command that I tried
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' protocol value="tcp" destination address='aa.bb.0.0/16' reject"
One quirk of fireall-cmd is that there are two distinct modes - one that operates on the stored configuration (with --permanent) and one that operates on the running config (without --permanent). When you make a change with --permanent, it is stored, and will take effect on future boots, but it is not applied to the current config. You need to run the same command without the --permanent to apply to the current running config.
Alternately, you can make all your changes to the running config (no --permanent), and then store them all at once with firewall-cmd --runtime-to-permanent (but if you have something making dynamic changes, like fail2ban for example, that would get stored as well). Or you can make all your changes to the permanent config and then load them to running all at once with firewall-cmd --reload.
didn't put anything in iptables, i.e. iptables --list shows no rules. On the other hand, I do have this reject rule in /etc/firewalld/zones/ FedoraWorkstation.xml.
iptables only exists as a compat layer on top of nftables, and not everything in nftables will be reflected in the output of iptables. To see the full nftables running config use "nft list ruleset".
If you are going to use firewalld, you need to either _only_ use firewalld, or use nft with separate rulesets along side the firewalld managed rulesets. Trying to mix in iptables rules is unlikely to work how you'd like.
Hi Chris,
All of firewalld's rules are contained in custom chains. iptables is just a frontend to nftables so using iptables rather than nftables to enter rules shouldn't really matter.
I tested this:
iptables -t filter -A OUTPUT -d 192.168.1.1/32 -j DROP
and it was translated to this nft rule:
table ip filter { chain OUTPUT { type filter hook output priority filter; policy accept; ip daddr 192.168.1.1 counter packets 0 bytes 0 drop } }
The filter:OUTPUT chain is predefined and is unused by firewalld so I can't see how using iptables and its predefined chains to get rules into nftables would make any difference whatsoever. Now, if I were to try mucking around with any of firewalld's custom chains without knowing what I was doing I could definitely envision being bitten by the laws of unintended consequences which, as we all know, have very sharp teeth.
Thanks for your post. It got me digging around in all sorts of unfamiliar territory :m
Mike Wright
On Mon, 2023-06-19 at 13:07 -0500, Chris Adams wrote:
One quirk of fireall-cmd is that there are two distinct modes - one that operates on the stored configuration (with --permanent) and one that operates on the running config (without --permanent).
While the logic of the above makes sense, the below bit is somewhat surprising since it's not quite what we expect. You expect stored settings to be stored AND applied. There doesn't appear to be a one- step process to do that, either in command line or using the GUI.
When you make a change with --permanent, it is stored, and will take effect on future boots, but it is not applied to the current config. You need to run the same command without the --permanent to apply to the current running config.
Adding to the confusion, if you're using the GUI, is that you see messages at the bottom of the screen after making any changes:
Connection to firewalld established. Changes applied.
You expect that to mean something more than it says.
However, like with the command line, there is a reload firewalld option in the GUI menu which will make your permanently settings apply now. So you don't have to make the same changes in both modes. And there is the opposite, to store your temporary runtime changes into the permanent settings. So the same kind of thing you mentioned (about storing and reloading commands) can be done in GUI operations and command line modes.
We're more used to controls doing something immediately. This is more akin to editing a configuration file, then restarting the service.
Once upon a time, Tim ignored_mailbox@yahoo.com.au said:
We're more used to controls doing something immediately. This is more akin to editing a configuration file, then restarting the service.
When you think about changing firewall rules, especially on a remote system, it makes sense - you may need to batch up changes and apply them all at once to avoid locking yourself out for example.
Tim:
We're more used to controls doing something immediately. This is more akin to editing a configuration file, then restarting the service.
Chris Adams:
When you think about changing firewall rules, especially on a remote system, it makes sense - you may need to batch up changes and apply them all at once to avoid locking yourself out for example.
And still find that you've locked yourself out *after* they're all been processed. ;-)
Waiting... waiting... Is this ever coming back up... wondering if my last command was stupidly shutdown rather than reboot...?
I tried to add the rule in the running firewalld, i.e. without the -- permanent option and I can still connect to the darn thing. I wonder if it has something to do with the order in which the rules or the tables are being processed.
firewall-cmd --add-rich-rule="rule family='ipv4' protocol value="tcp" destination address='a.b.0.0/16' reject"
Also,
nft list ruleset
shows
chain filter_IN_FedoraWorkstation_deny { ip daddr a.b.0.0/16 meta l4proto tcp reject with icmp port-unreachable }
Nothing gets put in iptables (with -L -n).
One thing I noticed, the rule I added on the command line with firewall- cmd is visible in the GUI (firewall-config). However, if I try to add the same rule in the GUI, it won't let me, the OK button is grayed out. I tried different combinations of Family / Priority / Element / Action and OK is still grayed out, so I can't enter this rule from the GUI.
On Mon, 19 Jun 2023 13:07:11 -0500, Chris Adams wrote:
Once upon a time, Amadeus WM amadeus84@verizon.net said:
- The command that I tried
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' protocol value="tcp" destination address='aa.bb.0.0/16' reject"
One quirk of fireall-cmd is that there are two distinct modes - one that operates on the stored configuration (with --permanent) and one that operates on the running config (without --permanent). When you make a change with --permanent, it is stored, and will take effect on future boots, but it is not applied to the current config. You need to run the same command without the --permanent to apply to the current running config.
Alternately, you can make all your changes to the running config (no --permanent), and then store them all at once with firewall-cmd --runtime-to-permanent (but if you have something making dynamic changes, like fail2ban for example, that would get stored as well). Or you can make all your changes to the permanent config and then load them to running all at once with firewall-cmd --reload.
didn't put anything in iptables, i.e. iptables --list shows no rules. On the other hand, I do have this reject rule in /etc/firewalld/zones/ FedoraWorkstation.xml.
iptables only exists as a compat layer on top of nftables, and not everything in nftables will be reflected in the output of iptables. To see the full nftables running config use "nft list ruleset".
If you are going to use firewalld, you need to either _only_ use firewalld, or use nft with separate rulesets along side the firewalld managed rulesets. Trying to mix in iptables rules is unlikely to work how you'd like.
On Wed, 2023-06-21 at 16:26 +0000, Amadeus WM via users wrote:
I tried to add the rule in the running firewalld, i.e. without the -- permanent option and I can still connect to the darn thing. I wonder if it has something to do with the order in which the rules or the tables are being processed.
firewall-cmd --add-rich-rule="rule family='ipv4' protocol value="tcp" destination address='a.b.0.0/16' reject"
I would imagine rule order would be important, it always used to be with iptables, unless firewalld has some in-built prioritising. But for your above example, can double-quotes around tcp be inside double quotes for the whole thing?
It's many years since I did personal firewall rules. Back then it was iptables, I'd made a script with all the rules I wanted. Going from memory, it started off with an isolation command (didn't want things sneaking it while it's pants were down), cleared all the existing rules, put in my rules, and then the network was allowed to pass traffic.
When needed, I did any needed changes in my script, and ran it. It was the best way I could think of to always get consistent results.
Same here, I didn't monkey with the firewall since the days of iptables, where I had my rules in a file that I'd load up in iptables. I would drop everything by default and only poke holes for things that I needed. Now we have zones and policies and stuff and I have to read an entire treatise on firewall just to add a simple drop rule. In fact I did add the rule, it just doesn't do anything.
I'm intrigued by the fact that the GUI won't let me add the rule (but the command line does). Maybe there's something wrong with my rule and the GUI detects that, but then I would expect the command line to error out too.
On Thu, 22 Jun 2023 02:23:18 +0930, Tim via users wrote:
On Wed, 2023-06-21 at 16:26 +0000, Amadeus WM via users wrote:
I tried to add the rule in the running firewalld, i.e. without the -- permanent option and I can still connect to the darn thing. I wonder if it has something to do with the order in which the rules or the tables are being processed.
firewall-cmd --add-rich-rule="rule family='ipv4' protocol value="tcp" destination address='a.b.0.0/16' reject"
I would imagine rule order would be important, it always used to be with iptables, unless firewalld has some in-built prioritising. But for your above example, can double-quotes around tcp be inside double quotes for the whole thing?
It's many years since I did personal firewall rules. Back then it was iptables, I'd made a script with all the rules I wanted. Going from memory, it started off with an isolation command (didn't want things sneaking it while it's pants were down), cleared all the existing rules, put in my rules, and then the network was allowed to pass traffic.
When needed, I did any needed changes in my script, and ran it. It was the best way I could think of to always get consistent results.
So after digging a bit more into this,
firewall-cmd --get-active-zone FedoraWorkstation interfaces: enp8s0 docker interfaces: docker0
firewall-cmd --get-default-zone FedoraWorkstation
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' protocol value="tcp" destination address='aa.bb.0.0/16' reject"
This shows in
firewall-cmd --list-all # FedoraWorkstation (active)
as well as in nft:
nft list ruleset
chain filter_IN_FedoraWorkstation_deny { ip daddr a.b.0.0/16 meta l4proto tcp reject with icmp port-unreachable }
but it doesn't show in iptables at all.
So I suppose the rule got inserted properly, but why does it not do anything?
On Sun, 18 Jun 2023 18:15:13 -0000 (UTC), Amadeus WM via users wrote:
Say I want to drop/reject outgoing connections to a particular destination address (for parental control). How would I do this with firewalld?
I tried
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' protocol value="tcp" destination address='aa.bb.0.0/16' reject"
firewall-cmd --reload
Then,
firewall-cmd --zone=FedoraWorkstation --list-all FedoraWorkstation (active) target: default icmp-block-inversion: no interfaces: enp8s0 sources: services: dhcpv6-client ftp mdns mountd nfs rpc-bind samba-client ssh ports: 1025-65535/udp 1025-65535/tcp protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv4" destination address="aa.bb.0.0/16" protocol value="tcp" reject
does show that the rule was added. However, I was still able to connect to the destination with no issues.
In the past I did that with iptables and I can probably still do that now, but I think nowadays we're supposed to use firewalld, via firewall-cmd or firewall-config.
The problem with firewalld is that it has zones, which are defined based either on network interfaces or on IP sources (or ranges), but not on the destination IP. See e.g. https://www.linuxjournal.com/content/ understanding-firewalld-multi-zone-configurations . What I need is to filter based on the destination address.
I found this post saying that it's actually not easy to filter based on destination address with firewalld, and that we'd have to use firewall-cmd --direct to inject the filter rule directly into iptables:
https://serverfault.com/questions/918754/firewalld-stop-outgoing-
traffic-
to-a-particular-ip-address
But then, the documentation for firewalld.direct says this is deprecated.
What I think needs to happen is this:
- duplicate the default zone (Fedora Workstation) to, say, Parental
Control 2. In the Parental Control zone add the drop rule to the specific destinations 3. switch between Fedora Workstation and Parental Control as needed.
How can this be done? _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.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.fedoraproject.org/archives/list/
users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Jun 19, 2023, at 09:08, Amadeus WM via users users@lists.fedoraproject.org wrote:
So after digging a bit more into this,
firewall-cmd --get-active-zone FedoraWorkstation interfaces: enp8s0 docker interfaces: docker0
firewall-cmd --get-default-zone FedoraWorkstation
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' protocol value="tcp" destination address='aa.bb.0.0/16' reject"
This shows in
firewall-cmd --list-all # FedoraWorkstation (active)
as well as in nft:
nft list ruleset
chain filter_IN_FedoraWorkstation_deny { ip daddr a.b.0.0/16 meta l4proto tcp reject with icmp port-unreachable }
but it doesn't show in iptables at all.
So I suppose the rule got inserted properly, but why does it not do anything?
If you are basing your conclusion from the output of iptables, you should know that iptables in Fedora is just another front end to nft, and it doesn’t show all the nft rulesets. It’s just there for backwards comparability.
-- Jonathan Billings
Oh, I see, that's very useful to know.
But if I do add a rule to iptables, then that should get translated into an nft rule? And should be honored? Because the rule I put in firewalld does show up as an nft rule, but doesn't block anything.
On Mon, 19 Jun 2023 10:20:02 -0400, Jonathan Billings wrote:
On Jun 19, 2023, at 09:08, Amadeus WM via users users@lists.fedoraproject.org wrote:
So after digging a bit more into this,
firewall-cmd --get-active-zone FedoraWorkstation interfaces: enp8s0 docker interfaces: docker0
firewall-cmd --get-default-zone FedoraWorkstation
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' protocol value="tcp" destination address='aa.bb.0.0/16' reject"
This shows in
firewall-cmd --list-all # FedoraWorkstation (active)
as well as in nft:
nft list ruleset
chain filter_IN_FedoraWorkstation_deny { ip daddr a.b.0.0/16 meta l4proto tcp reject with icmp port-unreachable }
but it doesn't show in iptables at all.
So I suppose the rule got inserted properly, but why does it not do anything?
If you are basing your conclusion from the output of iptables, you should know that iptables in Fedora is just another front end to nft, and it doesn’t show all the nft rulesets. It’s just there for backwards comparability.
-- Jonathan Billings _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.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.fedoraproject.org/archives/list/
users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue