I think I need to add a rich rule for forwarding. Or write a nftable rule to do the same thing.
Is there a reasonable way to get firewalld-0.9 for Fedora 32? I don't wish to compile my own and fight with Fedora's package management. Rawhide has firewalld-filesystem-0.9.0-1.fc34.noarch.rpm Would that install cleanly on Fedora 32?
Alternatively, is it reasonable to run the nftable service as well as firewalld?
Alternatively, is --direct able to add nftable rules? It is documented to run iptables rules and I'd rather not use iptables.
Suggestions?
On 2020-09-25 05:47, D. Hugh Redelmeier wrote:
Is there a reasonable way to get firewalld-0.9 for Fedora 32?
You could download https://kojipkgs.fedoraproject.org//packages/firewalld/0.9.0/1.fc34/src/fire... and run rpmbuild against it.
I've done so and it produces
firewall-applet-0.9.0-1.fc32.noarch.rpm firewall-config-0.9.0-1.fc32.noarch.rpm firewalld-0.9.0-1.fc32.noarch.rpm firewalld-filesystem-0.9.0-1.fc32.noarch.rpm python3-firewall-0.9.0-1.fc32.noarch.rpm
Which I've not yet had the time to test.
On Fri, Sep 25, 2020 at 06:19:40AM +0800, Ed Greshko wrote:
On 2020-09-25 05:47, D. Hugh Redelmeier wrote:
Is there a reasonable way to get firewalld-0.9 for Fedora 32?
You could download https://kojipkgs.fedoraproject.org//packages/firewalld/0.9.0/1.fc34/src/fire... and run rpmbuild against it.
I've done so and it produces
firewall-applet-0.9.0-1.fc32.noarch.rpm firewall-config-0.9.0-1.fc32.noarch.rpm firewalld-0.9.0-1.fc32.noarch.rpm firewalld-filesystem-0.9.0-1.fc32.noarch.rpm python3-firewall-0.9.0-1.fc32.noarch.rpm
Which I've not yet had the time to test.
This works too. It has the added benefit that it includes the Fedora-isms.
Thanks for the input Ed. :)
On Thu, Sep 24, 2020 at 05:47:26PM -0400, D. Hugh Redelmeier wrote:
I think I need to add a rich rule for forwarding. Or write a nftable rule to do the same thing.
Is there a reasonable way to get firewalld-0.9 for Fedora 32? I don't wish to compile my own and fight with Fedora's package management. Rawhide has firewalld-filesystem-0.9.0-1.fc34.noarch.rpm Would that install cleanly on Fedora 32?
The upstream repository and releases have a "test-rpm" make target. This can be used to build RPMs. e.g.
# cd firewalld-0.9.0 # ./configure # make # make test-rpm # dnf install <built rpms>
Alternatively, is it reasonable to run the nftable service as well as firewalld?
The services explicitly Conflict. This is mostly because the nftables service will flush _all_ the rules.
Alternatively, is --direct able to add nftable rules?
No. This is by design. If something you need is not supported by firewalld's rich rules please file an RFE.
Alternatively, you can create your own nftables rules. firewalld only uses/touches/flushes rules/chains in the "firewalld" tables. It will not touch nftables rules created out-of-band of firewalld.
Thanks, Ed and Eric, for your help.
| From: Eric Garver egarver@redhat.com
| On Thu, Sep 24, 2020 at 05:47:26PM -0400, D. Hugh Redelmeier wrote:
| > Is there a reasonable way to get firewalld-0.9 for Fedora 32?
I've decided that it isn't reasonable. Updating my system from F32 to F33 might get messy. F33 appears not to include firewalld-0.9. That seems to be scheduled for F34.
| > I don't wish to compile my own and fight with Fedora's package management.
It's not that I fear building packages. I fear contradicting Fedora's choice of package version.
| > Alternatively, is it reasonable to run the nftable service as well as | > firewalld? | | The services explicitly Conflict. This is mostly because the nftables | service will flush _all_ the rules.
Very useful to know.
| > Alternatively, is --direct able to add nftable rules? | | No. This is by design. If something you need is not supported by | firewalld's rich rules please file an RFE.
Ahh. I asked the wrong question. I could use --direct to add an iptables rule, and that should be good enough.
I just thought iptables was a step backward from nftables (itself a step backwards from firewalld).
I think that the rule will look something like this. The table is "filter", the chain is FORWARD and the priority is 0.
Am I correct in assuming that since the table and chain ought to already exist, all I have to do is add the rule?
The purpose is to drop all packets from the internet that have an explicit destination within MYSUBNET.
sudo firewall-cmd \ --direct --add-rule ipv4 filter FORWARD 0 \ --in-interface=EXTERNAL_INTERFACE \ --source MYSUBNET \ DROP
Questions:
- should I be using chain FORWARD_direct instead of FORWARD? firewall-cmd(1) gives the example of INPUT_direct but does not specify which other chains are automatically created. (That seems like a documentation bug.)
- can I use the long form of the iptables flags or do I have to use the single-letter version? firewall-cmd(1) only uses the single-letter versions. Answer: yes, long forms are accepted.
| Alternatively, you can create your own nftables rules. firewalld only | uses/touches/flushes rules/chains in the "firewalld" tables. It will not | touch nftables rules created out-of-band of firewalld.
This seems too fragile and complex for the tiny hack I need.
On Fri, Sep 25, 2020 at 01:13:51AM -0400, D. Hugh Redelmeier wrote:
Thanks, Ed and Eric, for your help.
| From: Eric Garver egarver@redhat.com
| On Thu, Sep 24, 2020 at 05:47:26PM -0400, D. Hugh Redelmeier wrote:
| > Is there a reasonable way to get firewalld-0.9 for Fedora 32?
I've decided that it isn't reasonable. Updating my system from F32 to F33 might get messy. F33 appears not to include firewalld-0.9. That seems to be scheduled for F34.
| > I don't wish to compile my own and fight with Fedora's package management.
It's not that I fear building packages. I fear contradicting Fedora's choice of package version.
| > Alternatively, is it reasonable to run the nftable service as well as | > firewalld? | | The services explicitly Conflict. This is mostly because the nftables | service will flush _all_ the rules.
Very useful to know.
| > Alternatively, is --direct able to add nftable rules? | | No. This is by design. If something you need is not supported by | firewalld's rich rules please file an RFE.
Ahh. I asked the wrong question. I could use --direct to add an iptables rule, and that should be good enough.
I just thought iptables was a step backward from nftables (itself a step backwards from firewalld).
I think that the rule will look something like this. The table is "filter", the chain is FORWARD and the priority is 0.
Am I correct in assuming that since the table and chain ought to already exist, all I have to do is add the rule?
Yes. It should already exist.
The purpose is to drop all packets from the internet that have an explicit destination within MYSUBNET.
You could just add MYSUBNET to the block zone. This will also block the forwarded traffic.
# firewall-cmd --zone block --add-source 10.254.254.0/24
and the nftables rules generated:
chain filter_FORWARD_IN_ZONES_SOURCE { ip saddr 10.254.254.0/24 goto filter_FWDI_block }
chain filter_FWDI_block { [..] log prefix ""filter_FWDI_block_REJECT: "" reject with icmpx type admin-prohibited }
Note the catch-all reject at the end of filter_FWDI_block.
sudo firewall-cmd \ --direct --add-rule ipv4 filter FORWARD 0 \ --in-interface=EXTERNAL_INTERFACE \ --source MYSUBNET \ DROP
Questions:
- should I be using chain FORWARD_direct instead of FORWARD? firewall-cmd(1) gives the example of INPUT_direct but does not specify which other chains are automatically created. (That seems like a documentation bug.)
If using the nftables backend "FORWARD" will add the direct rules to the iptables chain "FORWARD".
If using the nftables backend "FORWARD" will add the direct rules to the iptables chain "FORWARD_direct".
- can I use the long form of the iptables flags or do I have to use the single-letter version? firewall-cmd(1) only uses the single-letter versions. Answer: yes, long forms are accepted.
Yes. The arguments are passed directly to iptables. Firewalld does not understand them.
| Alternatively, you can create your own nftables rules. firewalld only | uses/touches/flushes rules/chains in the "firewalld" tables. It will not | touch nftables rules created out-of-band of firewalld.
This seems too fragile and complex for the tiny hack I need.
Agreed. Try the `--add-source` setting I mention above.
| From: Eric Garver egarver@redhat.com
Thanks again, Eric. Lot of useful information.
| On Fri, Sep 25, 2020 at 01:13:51AM -0400, D. Hugh Redelmeier wrote:
| > The purpose is to drop all packets from the internet that have an | > explicit destination within MYSUBNET.
Just to be explicit: anything on my LAN from or too MYSUBNET is OK. Normal Masquerading is applied for packets leaving or entering from the internet.
| You could just add MYSUBNET to the block zone. This will also block the | forwarded traffic. | | # firewall-cmd --zone block --add-source 10.254.254.0/24
If this kind of approach could work, it seems much cleaner than a direct rule.
I don't understand this suggestion for a couple of reasons.
- I thought zones were mutually exclusive. So if a packet comes in the external zone and is forwarded to the internal zone, when/how/why does the block zone apply?
- it looks as if IP addresses for zones use "source" and there is no --add-destination (except for ICMP). I need to block MYSUBNET destinations.
- if block zone does work, that may be too general. I only want to block traffic frome the external zone with MYSUBNET destinations. Other traffic with that destination is fine.
In https://firewalld.org/documentation/zone/predefined-zones.html
block
Any incoming network connections are rejected with an icmp-host-prohibited message for IPv4 and icmp6-adm-prohibited for IPv6. Only network connections initiated within this system are possible.
For reference, here again is the direct rule I'm considering:
| > sudo firewall-cmd \ | > --direct --add-rule ipv4 filter FORWARD 0 \ | > --in-interface=EXTERNAL_INTERFACE \ | > --source MYSUBNET \ | > DROP
On Fri, Sep 25, 2020 at 08:17:39AM -0400, D. Hugh Redelmeier wrote:
| From: Eric Garver egarver@redhat.com
Thanks again, Eric. Lot of useful information.
| On Fri, Sep 25, 2020 at 01:13:51AM -0400, D. Hugh Redelmeier wrote:
| > The purpose is to drop all packets from the internet that have an | > explicit destination within MYSUBNET.
Just to be explicit: anything on my LAN from or too MYSUBNET is OK. Normal Masquerading is applied for packets leaving or entering from the internet.
| You could just add MYSUBNET to the block zone. This will also block the | forwarded traffic. | | # firewall-cmd --zone block --add-source 10.254.254.0/24
If this kind of approach could work, it seems much cleaner than a direct rule.
I don't understand this suggestion for a couple of reasons.
- I thought zones were mutually exclusive. So if a packet comes in the external zone and is forwarded to the internal zone, when/how/why does the block zone apply?
They are mutually exclusive at _ingress_, but after ingress packets may be _forwarded_ to other zones (think "egress zones"). When you use `--add-source` you're saying "all traffic with source of <source> is part of this zone". The traffic will not ingress any other zone.
- it looks as if IP addresses for zones use "source" and there is no --add-destination (except for ICMP). I need to block MYSUBNET destinations.
The block will occur in the opposite direction as well:
chain filter_FORWARD_OUT_ZONES_SOURCE { ip daddr 10.254.254.0/24 goto filter_FWDO_block } chain filter_FWDO_block { [..] log prefix ""filter_FWDO_block_REJECT: "" reject with icmpx type admin-prohibited }
- if block zone does work, that may be too general. I only want to block traffic frome the external zone with MYSUBNET destinations. Other traffic with that destination is fine.
Ah. In this case policy objects would be better. But if this is a requirement then for firewalld < v0.9.0 you must use a direct rule. Keep in mind direct rules ignore zones. To scope the direct rule to traffic originating from "external" you'll have to match the ingress interface (-i).
In https://firewalld.org/documentation/zone/predefined-zones.html
block
Any incoming network connections are rejected with an icmp-host-prohibited message for IPv4 and icmp6-adm-prohibited for IPv6. Only network connections initiated within this system are possible.
For reference, here again is the direct rule I'm considering:
| > sudo firewall-cmd \ | > --direct --add-rule ipv4 filter FORWARD 0 \ | > --in-interface=EXTERNAL_INTERFACE \ | > --source MYSUBNET \ | > DROP
Based on what you said above this looks like your best option for firewalld < v0.9.0.
Note: You forgot the "-j". It should be "-j DROP" instead of "DROP".
| From: Eric Garver egarver@redhat.com
| > For reference, here again is the direct rule I'm considering: | > | > | > sudo firewall-cmd \ | > | > --direct --add-rule ipv4 filter FORWARD 0 \ | > | > --in-interface=EXTERNAL_INTERFACE \ | > | > --source MYSUBNET \ | > | > DROP | | Based on what you said above this looks like your best option for | firewalld < v0.9.0. | | Note: You forgot the "-j". It should be "-j DROP" instead of "DROP".
Thanks.
No wonder that I confused you about what I was trying to do. --source should have been --destination.
I don't seem to be cut out for iptables -- I keep making little mistakes. That's why I like firewalld.
With those two changes, the direct rule works.
(The real complexity of iptables is in the sequencing and priorities of rules. The more declarative nature of firewalld is much better.)
On Fri, Sep 25, 2020 at 12:01:36PM -0400, D. Hugh Redelmeier wrote:
| From: Eric Garver egarver@redhat.com
| > For reference, here again is the direct rule I'm considering: | > | > | > sudo firewall-cmd \ | > | > --direct --add-rule ipv4 filter FORWARD 0 \ | > | > --in-interface=EXTERNAL_INTERFACE \ | > | > --source MYSUBNET \ | > | > DROP | | Based on what you said above this looks like your best option for | firewalld < v0.9.0. | | Note: You forgot the "-j". It should be "-j DROP" instead of "DROP".
Thanks.
No wonder that I confused you about what I was trying to do. --source should have been --destination.
I don't seem to be cut out for iptables -- I keep making little mistakes. That's why I like firewalld.
With those two changes, the direct rule works.
(The real complexity of iptables is in the sequencing and priorities of rules. The more declarative nature of firewalld is much better.)
Glad you like it. Hope you get to use policy objects in the near future. :)
firewalld-users@lists.stg.fedorahosted.org