firewalld-users July 2020

firewalld-users@lists.fedorahosted.org

6 participants
5 discussions

Re rich rules
by D. Hugh Redelmeier 03 Aug '20

03 Aug '20

[Please excuse the lack of threading. I just switched on email subscription and that prevents "reply" from working in the web interface and it won't work with a non-GUI MUA] Thanks Eric. Eric asked: | On Fri, Jul 31, 2020 at 04:11:51PM -0000, D. Hugh Redelmeier wrote: | | > I had tried a couple of different rich rules with negative priority, | > hoping that they would apply before masquerading, but they didn't seem | > to. I might have made some mistakes in formulating the rule. | > | > From output of sudo firewall-cmd --info-zone=external | > services: ... ssh | > masquerade: yes | > rule priority="-10" family="ipv4" destination address="my.net.ip.addr/24" drop | > | > Even with this rule, I could ssh directly into my LAN from outside. | > Should that not have been blocked by my rich rule? | | No - the above will _not_ block SSH outside --> LAN. I suspect it's only | being allowed due to the issue I linked in my last email [1]. What is | your LAN zone? trusted? internal? My LAN is in zone "internal". The issue you linked (a possibly bogus free pass) applies only to "trusted" as far as I can tell from a quick read. | I think misunderstood what you wanted from your original email. More than likely I have a bogus model and thus speak in confusing ways. ================ In a very abstract level, I like firewalld because the configuration is specified in a declarative way. Up to, but not including, rich rules. This should make configuring firewalls simpler, clearer, and less error prone. That puts a responsibility on the firewalld crew. It should not be assumed that users are as sophisticated as iptables users. I think that the clearest idea of masquerading is or should be: - there is a pool of non-routable addresses used on the local system - there is one routable address used to talk to the wide internet - the masquerade multiplexes/demultiplexes traffic from/to a local address to/from the routable address. Almost all naive users would assume that if one of the non-routable addresses were on a packet on the global side, it should be dropped or rejected. My experiments seem to show that this is not happening. From outside my LAN, I could SSH into the LAN (not just the gateway). I tried (unsuccessfully) to implement this policy with a rich rule. ================ My own configuration is quite odd. I've accommodated it for 20 years using iptables and its precursors: - my local address are, in fact, legitimate global addresses - I want to carve up the subnet so that one portion is masqueraded and another portion is not. The masqueraded portion include machines that haven't been hardened. - the split is not 50-50. The natural way to split is the use address ranges. The efficient way is to use overlapping subnets, with priority to the smaller. I don't expect firewalld to cater to my odd case. But it would be nice if happened to be possible.

2 3

rich rules
by D. Hugh Redelmeier 31 Jul '20

31 Jul '20

I'm coming from years of modest use of iptables and its precursors. I'm trying to configure a router with firewalld. My router has two interfaces, one for the LAN and one for the WAN. The WAN interface is zone "external". The router has a static IP address assigned by the ISP. The ISP also routes a subnet to me (not containing the static IP address). The subnet is globally routable. The LAN machines have addresses in that subnet. I have three constraints that I want to express but don't know how. Rich rules seem the best bet. 1. I want to masquerade a subset of nodes on the LAN, even though they have routable addresses. Currently I have all masqueraded. How can I be selective? Do I unselect "masquerade" and replace it with an ordered sequence of rich rules, the last of which applies masquerading? 2. I want traffic coming in from the LAN with destination addresses in the masqueraded set to be dropped. In other words, those nodes should only be reached through masquerading. This does not seem to happen by default (as I would have expected). 3. I want the set of services offered by my router itself to be different from the set of services offered by the non-masqueraded nodes. Motivation for 2: my insecure boxes are a lot more secure if they are safely behind NAT. But they have routable IP addresses and my current firewalld configuration allows all the machines to be directly addressed. I tried to use a rich rule to block this, but it had no effect. I assumed that I should use "rule ipv4 destination address=... drop". That seemed to have no effect. Switching to "source" didn't help. I assume that the masquerade setting somehow overrides. Motivation for 3: the services that I wish to expose on my LAN nodes are different from those I wish to offer on my router. I don't know how to express this. (Of course a separate firewall on each LAN node would work but that's a lot more work and a lot easier to get wrong.)

2 3

How do iptables and nftables work in conjunction?
by Gunnar Niels 27 Jul '20

27 Jul '20

I've been continuing to experiment with firewalld and learn the underlying userspace tools like iptables and nft for expressing firewall rules, but from what I've been reading, it seems like nftables is intended to replace iptables, which is possibly heading towards deprecation (if anyone can shed some light on that, would be much appreciated)? If that's true, it appears that firewalld whever it is in use still needs to work on top of *both* iptables and nftables. When I add a direct rule, that gets added directly to the cooresponding iptables chain, while rich rules look like they are added to nftable chains. I'm working on my Arch Linux workstation, but I'm also responsible for a number RHEL/CentOS boxes that I'd like to upgrade to their respective v8 editions, but I'd really like a rock solid understanding of firewalld and the systems underneath before I'm comfortable in productions. So how do iptables and nftables work in conjunction with one another when they seem like they potentially could hold conflicting rules? Is there some order of precedence where these are ultiately boiled down to a single golden source of rules within the kernel? -GN

3 2

Setting up a restricted libvirt network with firewalld?
by Gunnar Niels 20 Jul '20

20 Jul '20

Hello, I'm experimenting with VMs and firewalld while trying to get comfortable with CentOS 8 and am hitting a bit of a wall, hopefully someone here can point me in the right direction. [What I'd like to do] I have a LAN (192.168.2.0/24) with my CentOS 8 VM host (192.168.2.3). I also have a file server with a samba share at 192.168.2.2. On my VM host, I'm trying to run a Windows VM so I can use a USB device that has Windows only drivers, and then write some files to my samba share. However, I don't trust Windows, so I want to block all network traffic associated with this VM *except* the samba connection to my file server. I'm using libvirt to run this VM, and thought I'd like to have a dedicated libvirt virt network that's "disconnected" in this way; it has no connection ability apart from that which I whitelist. This network is called "libvirt_discon", and it uses libvirt NAT forwarding and DHCP. Its subnet is 192.168.100.0/24. [What I've done] I created a new firewalld zone called "libvirt_discon" and assigned the libvirt network's dev "virbr1" to the zone (this is done via the libvirt network xml). I added dhcp to the list of the zone's services, and can confirm this allows the machine to get an ip address. I set the zone's target to "%%REJECT%%" since I want this to be the default behavior of the zone. Then I tried to whitelist samba with the following rich rule: firewall-cmd --zone=libvirt_discon --add-rich-rule='rule family=ipv4 destination address=192.168.2.2 service name=samba accept' This does not work; I'm testing with a fedora machine on the libvirt-discon network and trying to list the samba shares, my connection is immediately rejected: $ smbclient --user=samba --list=192.168.2.2 do_connect: Connection to 192.168.2.2 failed (Error NT_STATUS_HOST_UNREACHABLE) [Questions] I suspect I'm stumbling because I'm using libvirt NAT instead of a bridged device (which admitedly I don't fully understand). Dumping the nft ruleset, it looks like my zone settings strictly affect the zone's input chain. At some point my packets need to traverse the NAT from virbr1 (zone libvirt_discon) to my eth NIC (zone public), and back again. I'm not sure how this works, could someone shed some light on that? Do I need to enable masquerade on one of the zones here, and if so which one or both? When exactly do I need to enable masquerade? Are these considered FORWARDed packets, and therefore the INPUT chain rules I've actually written with my rich rule not apply? (They demonstrably are not logging..) Thank you very much for your time, hopefully someone can point me in the right direction based on what I'm trying to accomplish. GN

4 8

Info on nft rules created by firewalld
by Andrea Pasquinucci 20 Jul '20

20 Jul '20

Hi, I am learning how to use firewalld with nft on fedora 32. I have 2 simple questions: 1. is it possible to show counters of packets/bytes for tables/chains/rules as it was for iptables? I did not find anything about this in firewalld. 2. I am confused by the use of jump and goto in the rules created by firewalld: for example in the rules below (generated by firewalld on one of my PCs) in the chain filter_INPUT_ZONES there are 'goto' whereas in the other chains there are 'jump', so what happens to a ct-new packet with 'iifname "eno1"' and not to 'tcp dport 22'? Does it end up to 'policy accept' or to 'reject with icmpx type admin-prohibited' or where? Thanks! chain filter_INPUT { type filter hook input priority filter + 10; policy accept; ct state { established, related } accept ct status dnat accept iifname "lo" accept jump filter_INPUT_ZONES ct state { invalid } drop reject with icmpx type admin-prohibited } chain filter_INPUT_ZONES { iifname "eno1" goto filter_IN_FedoraWorkstation iifname "virbr0" goto filter_IN_libvirt goto filter_IN_FedoraWorkstation } chain filter_IN_FedoraWorkstation { jump filter_IN_FedoraWorkstation_pre jump filter_IN_FedoraWorkstation_log jump filter_IN_FedoraWorkstation_deny jump filter_IN_FedoraWorkstation_allow jump filter_IN_FedoraWorkstation_post meta l4proto { icmp, ipv6-icmp } accept } chain filter_IN_FedoraWorkstation_pre { } chain filter_IN_FedoraWorkstation_log { } chain filter_IN_FedoraWorkstation_deny { } chain filter_IN_FedoraWorkstation_allow { tcp dport 22 ct state { new, untracked } accept } chain filter_IN_FedoraWorkstation_post { }

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

firewalld-users July 2020