[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.
[threading still wrong]
Eric asked:
| On Fri, Jul 31, 2020 at 04:11:51PM -0000, D. Hugh Redelmeier wrote:
| > firewalld.richlanguage(5) section "Information about logging and | > actions" does not say on which chain or at which priority masquerading | > is applied. So my use of negative priority was an experiment, after | > trying no priority. | | That chain suffix/sorting (_pre, _log, _deny, _allow, _post) applies | to all rich rules. But the different chain (input, prerouting, | postrouting) used by a rich rule varies depending on the rich rule. | "service value=... accept" would go to input. forward-port would go to | prerouting, masquerade goes to postrouting.
The "Information about logging and actions" section lists chains but does not actually say that the chains are applied in the listed order. It probably isn't obvious to all readers. This should be made explicit.
I'm not sure but for at least the external zone, this list is only about packets coming into an interface. This should be made explicit in the documentation.
(I used the words ingress and egress relative to an interface (zone) whereas you seemed to use it for a network (eg. a LAN).)
If the rules (other than masquerade or logging) only apply in ingress, then source and destination are clear. But only if that's true.
In an abstract way, masquerading is done in both directions. It's just that inbound traffic is handled by connection tracking and not explicit masquerading rules. This should be spelled out in the documentation.
I think that it is important that firewalld users not have to understand the lore of what's underneath it. I don't even know what that is by default. (Seems to be netfilter on Fedora 32.)
| > I had a nagging fear that my rules might apply on egress as well. | | Masquerading _must_ be applied on postrouting (egress). | | With the few exceptions (forward-port, masquerade) firewalld rules | apply to the input chain (ingress).
I wanted to make sure no local IP addresses leaked to the internet. So an egress rule seemed reasonable. Nothing in "Information about logging and actions" made it clear to me that my rules were ingress-only.
If "source" and "destination" keywords were replaced with "outside" and "inside", one rich rule could specify both ingress and egress. But you don't have rules that are bidirectional, so that doesn't matter. This certainly was part of my confusion.
I'm glad you are about to land forwarding and egress rich filters. I didn't see documentation. I didn't dig into your git commits.
On Fri, Jul 31, 2020 at 04:15:29PM -0400, D. Hugh Redelmeier wrote:
[threading still wrong]
Eric asked:
| On Fri, Jul 31, 2020 at 04:11:51PM -0000, D. Hugh Redelmeier wrote:
| > firewalld.richlanguage(5) section "Information about logging and | > actions" does not say on which chain or at which priority masquerading | > is applied. So my use of negative priority was an experiment, after | > trying no priority. | | That chain suffix/sorting (_pre, _log, _deny, _allow, _post) applies | to all rich rules. But the different chain (input, prerouting, | postrouting) used by a rich rule varies depending on the rich rule. | "service value=... accept" would go to input. forward-port would go to | prerouting, masquerade goes to postrouting.
The "Information about logging and actions" section lists chains but does not actually say that the chains are applied in the listed order. It probably isn't obvious to all readers. This should be made explicit.
I'm not sure but for at least the external zone, this list is only about packets coming into an interface. This should be made explicit in the documentation.
That's not true. Masquerade for example applies when the packets are leaving via the zone, e.g. internal --> external. In the nat table look at the chain POST_external.
(I used the words ingress and egress relative to an interface (zone) whereas you seemed to use it for a network (eg. a LAN).)
I don't think our terminology is different. We're just looking at it from different perspectives: a) the network point of view (zones) or b) interfaces.
ingress = packet came IN via an interface assigned to the zone egress = packet goes OUT via an interface assigned to the zone
ingress = packet came IN from a network segment/subnet egress = packet goes OUT to a network segment/subnet
If the rules (other than masquerade or logging) only apply in ingress, then source and destination are clear. But only if that's true.
It is true.
In an abstract way, masquerading is done in both directions. It's just that inbound traffic is handled by connection tracking and not explicit masquerading rules. This should be spelled out in the documentation.
I think that it is important that firewalld users not have to understand the lore of what's underneath it. I don't even know what that is by default. (Seems to be netfilter on Fedora 32.)
"It should be spelled out in the documentation"
and
"it is important that firewalld users not have to understand what's underneath"
are sort of contradicting statements. That being said, I'm okay with making it explicit in the documentation.
[..]
On Fri, Jul 31, 2020 at 03:27:56PM -0400, D. Hugh Redelmeier wrote:
[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.
Accurate.
| 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.
What you describe should be the case. It sounds like you have something else going on that causes the unexpected behavior.
If you can share more information perhaps we can track it down.
- show all firewalld configuration --list-all-zones - show all firewall rules - iptables-save - ip6tables-save - nft list ruleset - show all routes - ip route
================
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.
It should be possible using a rich rule to limit what source addresses get masqueraded.
firewalld-users@lists.fedorahosted.org
-
D. Hugh Redelmeier -
Eric Garver