Re rich rules
by D. Hugh Redelmeier
[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.
3 years, 7 months
rich rules
by D. Hugh Redelmeier
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.)
3 years, 7 months
How do iptables and nftables work in conjunction?
by Gunnar Niels
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 years, 7 months
Setting up a restricted libvirt network with firewalld?
by Gunnar Niels
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
3 years, 8 months
Info on nft rules created by firewalld
by Andrea Pasquinucci
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 {
}
3 years, 8 months