Skip to content

Commit

Permalink
sysctl.d: switch net.ipv4.conf.all.rp_filter from 1 to 2
Browse files Browse the repository at this point in the history 
This switches the RFC3704 Reverse Path filtering from Strict mode to Loose
mode. The Strict mode breaks some pretty common and reasonable use cases,
such as keeping connections via one default route alive after another one
appears (e.g. plugging an Ethernet cable when connected via Wi-Fi).

The strict filter also makes it impossible for NetworkManager to do
connectivity check on a newly arriving default route (it starts with a
higher metric and is bumped lower if there's connectivity).

Kernel's default is 0 (no filter), but a Loose filter is good enough. The
few use cases where a Strict mode could make sense can easily override
this.

The distributions that don't care about the client use cases and prefer a
strict filter could just ship a custom configuration in
/usr/lib/sysctl.d/ to override this.
  • Loading branch information
@lkundrak @poettering
lkundrak authored and poettering committed Nov 28, 2018
1 parent 0d34228 commit 230450d
Show file tree
Hide file tree
Showing 2 changed files with 10 additions and 1 deletion.
9 changes: 9 additions & 0 deletions NEWS
View file
Expand Up @@ -70,6 +70,15 @@ CHANGES WITH 240 in spe:
glibc is going to make it available too. This locale enables UTF-8
mode by default, which appears appropriate for 2018.

* The "net.ipv4.conf.all.rp_filter" sysctl will now be set to 2 by
default. This effectively switches the RFC3704 Reverse Path filtering
from Strict mode to Loose mode. This is more appropriate for hosts
that have multiple links with routes to the same networks (e.g.
a client with a Wi-Fi and Ethernet both connected to the internet).

Consult the kernel documetnation for details on this sysctl:
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

CHANGES WITH 239:

* NETWORK INTERFACE DEVICE NAMING CHANGES: systemd-udevd's "net_id"
Expand Down
2 changes: 1 addition & 1 deletion sysctl.d/50-default.conf
View file
Expand Up @@ -22,7 +22,7 @@ kernel.sysrq = 16
kernel.core_uses_pid = 1

# Source route verification
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.rp_filter = 2

# Do not accept source routing
net.ipv4.conf.all.accept_source_route = 0
Expand Down

7 comments on commit 230450d

@antonov-impulsm
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it normal that we set "net.ipv4.conf.all.rp_filter", but did set "net.ipv4.conf.default.rp_filter" (before) ?

just asking (I'm trying to understand)...

@antonov-impulsm
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i got

The max value from conf/{all,interface}/rp_filter is used
when doing source validation on the {interface}.

value "2" will be used. right?

@baybal
Copy link
Contributor

@baybal baybal commented on 230450d Dec 5, 2019 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://seclists.org/oss-sec/2019/q4/122

The article above tells of possible VPN attack scenarios, but can think of other protocols too. Think of revering to 1, and not changing to 2 until users definitely understand what they are doing.

@h1z1
Copy link

@h1z1 h1z1 commented on 230450d Dec 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hosts that have multiple routes also have, hopefully, administrators who know what the hell they are doing and will properly add further security measures to their network. How in the world did this ever get committed without ANY DISCUSSION??

The strict filter also makes it impossible for NetworkManager to do
connectivity check on a newly arriving default route (it starts with a
higher metric and is bumped lower if there's connectivity).

So you completely compromise millions of hosts in the process? What the fuck.

CVE aside, this is a horrendously asinine thing to have ever committed.

@FlorianHeigl
Copy link

@FlorianHeigl FlorianHeigl commented on 230450d Dec 8, 2019 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this commit should be preseved, as a good reminder that these days gov agencies don't necessarily need to subvert open source projects anymore.

  1. find a project that has no mandatory discussions for security critical changes
  2. subscribe to commit log
  3. wait till someone feels constrained by security settings and values their own workflow efficiency higher than the drawbacks for other people
  4. exploit "secure" connections for 1-2 years

footnotes:

  • this is NOT the fault of the PR submitter
  • not of the person signing off (except in the specific case when it's the project lead)
  • the problem is that there's no double-sign off, no mandatory discussion etc

read up on efficiency vs. effectiveness

@h1z1
Copy link

@h1z1 h1z1 commented on 230450d Dec 15, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's also a reminder of companies are able to rewrite history. Notice the comments are removed.

Seriously considering the access Red Hat and now IBM have to Government systems all over the place, for this to have so little change management process is astounding. Entire threads, gone. I'm honestly amazed @poettering still has commit rights at all.

@stryngs
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My thoughts on the whole debacle:
https://github.com/stryngs/hysteria

Please sign in to comment.