While IPFire 2.x' web interface does not support IPv6, users can
technically run it with IPv6 by conducting the necessary configuration
changes manually.
To provide these systems as well, we should disable acceptance of ICMPv6
redirect packets - which is apparently not default in Linux, yet. :-/
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
The strict mode, as specified in RFC 3704, section 2.2, causes packets
to be dropped by the kernel if they arrive with a source IP address that
is not expected on the interface they arrived in. This prevents internal
spoofing attacks, and is considered best practice among the industry.
After a discussion with Michael, we reached the conclusion that
permitting users to configure the operating mode of RPF in IPFire causes
more harm than good. The scenarios where strict RPF is not usable are
negligible, and the vast majority of IPFire's userbase won't even
notice a difference.
This supersedes <495b4ca2-5a4b-2ffa-8306-38f152889582@ipfire.org>.
Suggested-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Reviewed-by: Adolf Belka <adolf.belka@ipfire.org>
This is recommended by KSPP, Lynis, and others. Indeed, there is no
legitimate reason why an unprivileged user on IPFire should do any
profiling. Unfortunately, this change never landed in the mainline
kernel, hence a distribution patch is necessary.
The second version of this patch rebases the kernel patch by Jeff
Vander Stoep against Linux 5.15.17 to avoid fuzzying.
Tested-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
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>
sched_min_granularity_ns and sched_migration_cost_ns are not
available for sysctl anymore. They can only altered via debugfs
if scheduler debugging is enabled.
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This is recommended by various Linux hardening guides in order to
prevent accidential overwriting of existing core dumps. While it has
probably little to no relevance to the average IPFire user, enabling it
won't harm and fixes a Lynis warning. :-)
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Similar to hard- and symlink protection introduced a while ago, this
patch enables protections against unintentional writes into
attacker-controlled regular files or FIFOs, where a program expected to
create new ones. This makes exploiting TOCTOU flaws harder.
See also: https://www.kernel.org/doc/Documentation/sysctl/fs.txt
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
RFC 1337 describes various TCP (side channel) attacks against
prematurely closed connections stalling in TIME-WAIT state, such as DoS
or injecting arbitrary TCP segments, and recommends to silently discard
RST packets for sockets in this state.
While applications still tied to such sockets should tolerate invalid
input (thanks to Jon Postel), there is little legitimate reason to send
such RST packets altogether.
At the time of writing, no collateral damage related to active RFC 1337
implementations is known. Measuerements in productive environments did
not reveal any side effects either, which is why I consider enabling RFC
1337 implementation to be a safe change.
See also: https://tools.ietf.org/html/rfc1337
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
These parameters increase the throughput on various (large-ish)
systems by 5-10% on the slight expense of higher power consumption.
Socket buffers are increases and the system is configured to be
less aggressive when scheduling processes from one processor to
another one which ensures that the cache remains "hot" for longer.
On a slower system (apu1d) no performance improvement or loss
could have been measured.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The setting cannot be set on the default system because the ip_vs
module is not loaded by default and there is no reason to load it
just because we would be able to set the setting.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Make sure kernel address space is hidden from files somewhere
in /proc . This reduces attack surface and partially addresses #11659.
Signed-off-by: Peter Müller <peter.mueller@link38.eu>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This seems to be a failed concept and causes issues with transferring
large packets through an IPsec tunnel connection.
This configures the kernel to still respond to PMTU ICMP discovery
messages, but will not try this on its own.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
It comes much more handy to compile in the IPv6 kernel module
(because it is loading almost everywhere) and disable the IPv6
functionality when the system starts up.
Therefore, IPv6 is not accidentially enabled at any time unless
someone wants to use it and disables the systcl options.
This commits removes some settings from /etc/sysctl.conf that have
been there forever with no particular reason.
They could improve performance on internet connections, especially
on lines with massive packet lost.
