Message ID | 5afbf7f4-cb4c-afc9-ee8c-4858fd6fbea5@ipfire.org |
---|---|
State | Accepted |
Commit | d21e6d94cb7d0b6faba8e6b4cf8ae14d431fe554 |
Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4JcHvY3Snbz3wcx for <patchwork@web04.haj.ipfire.org>; Sun, 16 Jan 2022 14:47:53 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4JcHvW4M9Mz2Kw; Sun, 16 Jan 2022 14:47:51 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4JcHvW0p2Vz2yXw; Sun, 16 Jan 2022 14:47:51 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4JcHvT0w1Fz2xgV for <development@lists.ipfire.org>; Sun, 16 Jan 2022 14:47:49 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4JcHvS0W9czsy for <development@lists.ipfire.org>; Sun, 16 Jan 2022 14:47:47 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1642344468; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=GhJzOwVUKNPBDsf5HcIGqbBg2kWEhuKsn5/kd6DldfQ=; b=etdU4s+u2qcURVzqTlaCGuHPjM3OloPdjCxj4TWJ73M4D9Fpo4OgCHZDG2o6XSFhfFr1Z/ QdLeYbFG0rWHPEBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1642344468; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=GhJzOwVUKNPBDsf5HcIGqbBg2kWEhuKsn5/kd6DldfQ=; b=AQzIoEWaCo6QDjEOFknkN7CjVWupRWtLyixUZdwy6T1dq2IdvbsdiNehW+tElm3CUNeNL1 ZES3wPnPoc7MCFvfpAk5J35hh3asy56YvzfY8zW7Py9t+NKZ17aTNlaGUsREvZokGIPj9B bIcMkw/ahfJQApjvbOl+VtxE+vJ6t+bBh6SQoYFSpL20CeUVCnALE8GWAXKxgWfxRzgpaf s+sY4kM07veoSWYjoYLZqX7VIuVp9Vfbr3GDuDz0br2Z901ivhwzVKk7WSiNN2mAw//3JW tox/7niC5G/orHCOK3e1g6Pr3RUwbBDjiKx7GHhoYouCe0MEc8UuNw0m8Hv/GQ== Message-ID: <5afbf7f4-cb4c-afc9-ee8c-4858fd6fbea5@ipfire.org> Date: Sun, 16 Jan 2022 14:47:25 +0000 MIME-Version: 1.0 Content-Language: en-US To: "IPFire: Development" <development@lists.ipfire.org> From: =?utf-8?q?Peter_M=C3=BCller?= <peter.mueller@ipfire.org> Subject: [PATCH] sysctl.conf: Enable Loose Reverse Path Filter according to RFC 3704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <https://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <http://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <https://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
Series |
sysctl.conf: Enable Loose Reverse Path Filter according to RFC 3704
|
|
Commit Message
Peter Müller
Jan. 16, 2022, 2:47 p.m. UTC
For historical reasons, we were always reluctant to reverse path
filtering, since configuration changes were tricky to evaluate for a
larger userbase, IPFire permits a number of complex scenarios, and due
to limited resources.
As a compromise, this patch suggests to enable Loose Reverse Path
Filtering, as specified in RFC 3704 (section 2.4), to gain at least some
security achievement on this end.
To quote from that:
Loose Reverse Path Forwarding (Loose RPF) is algorithmically similar
to strict RPF, but differs in that it checks only for the existence
of a route (even a default route, if applicable), not where the route
points to. Practically, this could be considered as a "route
presence check" ("loose RPF is a misnomer in a sense because there is
no "reverse path" check in the first place).
The questionable benefit of Loose RPF is found in asymmetric routing
situations: a packet is dropped if there is no route at all, such as
to "Martian addresses" or addresses that are not currently routed,
but is not dropped if a route exists.
There is no legitimate reason why we cannot enable this: If IPFire
receives a packet on some interface it cannot route on _any_ interface
at all, there is no sense in processing it.
While testing this change, I was unable to produce a situation where it
actually causes any harm. In theory, it shouldn't do so anyways.
In the future, we will hopefully be able to set these sysctl's to "1",
using Strict Reverse Path Filtering, as specified in RFC 3704 (section
2.2). Doing so was found to work fine in my testing environment as well,
but there is no asymmetric routing in place there.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
---
config/etc/sysctl.conf | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
Hello, How are we going to test this with a wider audience? I do not expect this to break anything, but I would like to make sure that this assumption holds true. -Michael > On 16 Jan 2022, at 14:47, Peter Müller <peter.mueller@ipfire.org> wrote: > > For historical reasons, we were always reluctant to reverse path > filtering, since configuration changes were tricky to evaluate for a > larger userbase, IPFire permits a number of complex scenarios, and due > to limited resources. > > As a compromise, this patch suggests to enable Loose Reverse Path > Filtering, as specified in RFC 3704 (section 2.4), to gain at least some > security achievement on this end. > > To quote from that: > > Loose Reverse Path Forwarding (Loose RPF) is algorithmically similar > to strict RPF, but differs in that it checks only for the existence > of a route (even a default route, if applicable), not where the route > points to. Practically, this could be considered as a "route > presence check" ("loose RPF is a misnomer in a sense because there is > no "reverse path" check in the first place). > > The questionable benefit of Loose RPF is found in asymmetric routing > situations: a packet is dropped if there is no route at all, such as > to "Martian addresses" or addresses that are not currently routed, > but is not dropped if a route exists. > > There is no legitimate reason why we cannot enable this: If IPFire > receives a packet on some interface it cannot route on _any_ interface > at all, there is no sense in processing it. > > While testing this change, I was unable to produce a situation where it > actually causes any harm. In theory, it shouldn't do so anyways. > > In the future, we will hopefully be able to set these sysctl's to "1", > using Strict Reverse Path Filtering, as specified in RFC 3704 (section > 2.2). Doing so was found to work fine in my testing environment as well, > but there is no asymmetric routing in place there. > > Signed-off-by: Peter Müller <peter.mueller@ipfire.org> > --- > config/etc/sysctl.conf | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/config/etc/sysctl.conf b/config/etc/sysctl.conf > index bc2d21c93..c8c775d13 100644 > --- a/config/etc/sysctl.conf > +++ b/config/etc/sysctl.conf > @@ -12,13 +12,13 @@ net.ipv4.tcp_syn_retries = 3 > net.ipv4.tcp_synack_retries = 3 > > net.ipv4.conf.default.arp_filter = 1 > -net.ipv4.conf.default.rp_filter = 0 > +net.ipv4.conf.default.rp_filter = 2 > net.ipv4.conf.default.accept_redirects = 0 > net.ipv4.conf.default.accept_source_route = 0 > net.ipv4.conf.default.log_martians = 1 > > net.ipv4.conf.all.arp_filter = 1 > -net.ipv4.conf.all.rp_filter = 0 > +net.ipv4.conf.all.rp_filter = 2 > net.ipv4.conf.all.accept_redirects = 0 > net.ipv4.conf.all.accept_source_route = 0 > net.ipv4.conf.all.log_martians = 1 > -- > 2.31.1
Hello Michael, thanks for your reply. Well, besides amending the patch for Core Update 164 (or beyond), mention it in the changelog, and encourage people running special setups to test this update, I have no idea. Since the vast majority of IPFire installations will have a default route set, Loose Reverse Path Filtering cannot break anything for them. Therefore, I am willing to risk the procedure mentioned above. Thanks, and best regards, Peter Müller > Hello, > > How are we going to test this with a wider audience? > > I do not expect this to break anything, but I would like to make sure that this assumption holds true. > > -Michael > >> On 16 Jan 2022, at 14:47, Peter Müller <peter.mueller@ipfire.org> wrote: >> >> For historical reasons, we were always reluctant to reverse path >> filtering, since configuration changes were tricky to evaluate for a >> larger userbase, IPFire permits a number of complex scenarios, and due >> to limited resources. >> >> As a compromise, this patch suggests to enable Loose Reverse Path >> Filtering, as specified in RFC 3704 (section 2.4), to gain at least some >> security achievement on this end. >> >> To quote from that: >> >> Loose Reverse Path Forwarding (Loose RPF) is algorithmically similar >> to strict RPF, but differs in that it checks only for the existence >> of a route (even a default route, if applicable), not where the route >> points to. Practically, this could be considered as a "route >> presence check" ("loose RPF is a misnomer in a sense because there is >> no "reverse path" check in the first place). >> >> The questionable benefit of Loose RPF is found in asymmetric routing >> situations: a packet is dropped if there is no route at all, such as >> to "Martian addresses" or addresses that are not currently routed, >> but is not dropped if a route exists. >> >> There is no legitimate reason why we cannot enable this: If IPFire >> receives a packet on some interface it cannot route on _any_ interface >> at all, there is no sense in processing it. >> >> While testing this change, I was unable to produce a situation where it >> actually causes any harm. In theory, it shouldn't do so anyways. >> >> In the future, we will hopefully be able to set these sysctl's to "1", >> using Strict Reverse Path Filtering, as specified in RFC 3704 (section >> 2.2). Doing so was found to work fine in my testing environment as well, >> but there is no asymmetric routing in place there. >> >> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >> --- >> config/etc/sysctl.conf | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/config/etc/sysctl.conf b/config/etc/sysctl.conf >> index bc2d21c93..c8c775d13 100644 >> --- a/config/etc/sysctl.conf >> +++ b/config/etc/sysctl.conf >> @@ -12,13 +12,13 @@ net.ipv4.tcp_syn_retries = 3 >> net.ipv4.tcp_synack_retries = 3 >> >> net.ipv4.conf.default.arp_filter = 1 >> -net.ipv4.conf.default.rp_filter = 0 >> +net.ipv4.conf.default.rp_filter = 2 >> net.ipv4.conf.default.accept_redirects = 0 >> net.ipv4.conf.default.accept_source_route = 0 >> net.ipv4.conf.default.log_martians = 1 >> >> net.ipv4.conf.all.arp_filter = 1 >> -net.ipv4.conf.all.rp_filter = 0 >> +net.ipv4.conf.all.rp_filter = 2 >> net.ipv4.conf.all.accept_redirects = 0 >> net.ipv4.conf.all.accept_source_route = 0 >> net.ipv4.conf.all.log_martians = 1 >> -- >> 2.31.1 >
Hello, Okay. Let’s give it a try. I will refer anyone running into problems to you :) -Michael > On 18 Jan 2022, at 21:18, Peter Müller <peter.mueller@ipfire.org> wrote: > > Hello Michael, > > thanks for your reply. > > Well, besides amending the patch for Core Update 164 (or beyond), mention it in the changelog, > and encourage people running special setups to test this update, I have no idea. > > Since the vast majority of IPFire installations will have a default route set, Loose Reverse > Path Filtering cannot break anything for them. Therefore, I am willing to risk the procedure > mentioned above. > > Thanks, and best regards, > Peter Müller > > >> Hello, >> >> How are we going to test this with a wider audience? >> >> I do not expect this to break anything, but I would like to make sure that this assumption holds true. >> >> -Michael >> >>> On 16 Jan 2022, at 14:47, Peter Müller <peter.mueller@ipfire.org> wrote: >>> >>> For historical reasons, we were always reluctant to reverse path >>> filtering, since configuration changes were tricky to evaluate for a >>> larger userbase, IPFire permits a number of complex scenarios, and due >>> to limited resources. >>> >>> As a compromise, this patch suggests to enable Loose Reverse Path >>> Filtering, as specified in RFC 3704 (section 2.4), to gain at least some >>> security achievement on this end. >>> >>> To quote from that: >>> >>> Loose Reverse Path Forwarding (Loose RPF) is algorithmically similar >>> to strict RPF, but differs in that it checks only for the existence >>> of a route (even a default route, if applicable), not where the route >>> points to. Practically, this could be considered as a "route >>> presence check" ("loose RPF is a misnomer in a sense because there is >>> no "reverse path" check in the first place). >>> >>> The questionable benefit of Loose RPF is found in asymmetric routing >>> situations: a packet is dropped if there is no route at all, such as >>> to "Martian addresses" or addresses that are not currently routed, >>> but is not dropped if a route exists. >>> >>> There is no legitimate reason why we cannot enable this: If IPFire >>> receives a packet on some interface it cannot route on _any_ interface >>> at all, there is no sense in processing it. >>> >>> While testing this change, I was unable to produce a situation where it >>> actually causes any harm. In theory, it shouldn't do so anyways. >>> >>> In the future, we will hopefully be able to set these sysctl's to "1", >>> using Strict Reverse Path Filtering, as specified in RFC 3704 (section >>> 2.2). Doing so was found to work fine in my testing environment as well, >>> but there is no asymmetric routing in place there. >>> >>> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >>> --- >>> config/etc/sysctl.conf | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/config/etc/sysctl.conf b/config/etc/sysctl.conf >>> index bc2d21c93..c8c775d13 100644 >>> --- a/config/etc/sysctl.conf >>> +++ b/config/etc/sysctl.conf >>> @@ -12,13 +12,13 @@ net.ipv4.tcp_syn_retries = 3 >>> net.ipv4.tcp_synack_retries = 3 >>> >>> net.ipv4.conf.default.arp_filter = 1 >>> -net.ipv4.conf.default.rp_filter = 0 >>> +net.ipv4.conf.default.rp_filter = 2 >>> net.ipv4.conf.default.accept_redirects = 0 >>> net.ipv4.conf.default.accept_source_route = 0 >>> net.ipv4.conf.default.log_martians = 1 >>> >>> net.ipv4.conf.all.arp_filter = 1 >>> -net.ipv4.conf.all.rp_filter = 0 >>> +net.ipv4.conf.all.rp_filter = 2 >>> net.ipv4.conf.all.accept_redirects = 0 >>> net.ipv4.conf.all.accept_source_route = 0 >>> net.ipv4.conf.all.log_martians = 1 >>> -- >>> 2.31.1 >>
Hello Michael, please do. It would be interesting to see setups where this breaks anything... Thanks, and best regards, Peter Müller > Hello, > > Okay. Let’s give it a try. I will refer anyone running into problems to you :) > > -Michael > >> On 18 Jan 2022, at 21:18, Peter Müller <peter.mueller@ipfire.org> wrote: >> >> Hello Michael, >> >> thanks for your reply. >> >> Well, besides amending the patch for Core Update 164 (or beyond), mention it in the changelog, >> and encourage people running special setups to test this update, I have no idea. >> >> Since the vast majority of IPFire installations will have a default route set, Loose Reverse >> Path Filtering cannot break anything for them. Therefore, I am willing to risk the procedure >> mentioned above. >> >> Thanks, and best regards, >> Peter Müller >> >> >>> Hello, >>> >>> How are we going to test this with a wider audience? >>> >>> I do not expect this to break anything, but I would like to make sure that this assumption holds true. >>> >>> -Michael >>> >>>> On 16 Jan 2022, at 14:47, Peter Müller <peter.mueller@ipfire.org> wrote: >>>> >>>> For historical reasons, we were always reluctant to reverse path >>>> filtering, since configuration changes were tricky to evaluate for a >>>> larger userbase, IPFire permits a number of complex scenarios, and due >>>> to limited resources. >>>> >>>> As a compromise, this patch suggests to enable Loose Reverse Path >>>> Filtering, as specified in RFC 3704 (section 2.4), to gain at least some >>>> security achievement on this end. >>>> >>>> To quote from that: >>>> >>>> Loose Reverse Path Forwarding (Loose RPF) is algorithmically similar >>>> to strict RPF, but differs in that it checks only for the existence >>>> of a route (even a default route, if applicable), not where the route >>>> points to. Practically, this could be considered as a "route >>>> presence check" ("loose RPF is a misnomer in a sense because there is >>>> no "reverse path" check in the first place). >>>> >>>> The questionable benefit of Loose RPF is found in asymmetric routing >>>> situations: a packet is dropped if there is no route at all, such as >>>> to "Martian addresses" or addresses that are not currently routed, >>>> but is not dropped if a route exists. >>>> >>>> There is no legitimate reason why we cannot enable this: If IPFire >>>> receives a packet on some interface it cannot route on _any_ interface >>>> at all, there is no sense in processing it. >>>> >>>> While testing this change, I was unable to produce a situation where it >>>> actually causes any harm. In theory, it shouldn't do so anyways. >>>> >>>> In the future, we will hopefully be able to set these sysctl's to "1", >>>> using Strict Reverse Path Filtering, as specified in RFC 3704 (section >>>> 2.2). Doing so was found to work fine in my testing environment as well, >>>> but there is no asymmetric routing in place there. >>>> >>>> Signed-off-by: Peter Müller <peter.mueller@ipfire.org> >>>> --- >>>> config/etc/sysctl.conf | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/config/etc/sysctl.conf b/config/etc/sysctl.conf >>>> index bc2d21c93..c8c775d13 100644 >>>> --- a/config/etc/sysctl.conf >>>> +++ b/config/etc/sysctl.conf >>>> @@ -12,13 +12,13 @@ net.ipv4.tcp_syn_retries = 3 >>>> net.ipv4.tcp_synack_retries = 3 >>>> >>>> net.ipv4.conf.default.arp_filter = 1 >>>> -net.ipv4.conf.default.rp_filter = 0 >>>> +net.ipv4.conf.default.rp_filter = 2 >>>> net.ipv4.conf.default.accept_redirects = 0 >>>> net.ipv4.conf.default.accept_source_route = 0 >>>> net.ipv4.conf.default.log_martians = 1 >>>> >>>> net.ipv4.conf.all.arp_filter = 1 >>>> -net.ipv4.conf.all.rp_filter = 0 >>>> +net.ipv4.conf.all.rp_filter = 2 >>>> net.ipv4.conf.all.accept_redirects = 0 >>>> net.ipv4.conf.all.accept_source_route = 0 >>>> net.ipv4.conf.all.log_martians = 1 >>>> -- >>>> 2.31.1 >>> >
diff --git a/config/etc/sysctl.conf b/config/etc/sysctl.conf index bc2d21c93..c8c775d13 100644 --- a/config/etc/sysctl.conf +++ b/config/etc/sysctl.conf @@ -12,13 +12,13 @@ net.ipv4.tcp_syn_retries = 3 net.ipv4.tcp_synack_retries = 3 net.ipv4.conf.default.arp_filter = 1 -net.ipv4.conf.default.rp_filter = 0 +net.ipv4.conf.default.rp_filter = 2 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv4.conf.default.log_martians = 1 net.ipv4.conf.all.arp_filter = 1 -net.ipv4.conf.all.rp_filter = 0 +net.ipv4.conf.all.rp_filter = 2 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.all.log_martians = 1