#782323 linux-image-3.16.0-4-amd64: setting net.ipv6.conf.all.accept_ra to 0 has no effect, thus does not protect against SLAAC attacks

Package:
src:linux
Source:
linux
Submitter:
Vincent Lefevre
Date:
2022-06-01 09:48:03 UTC
Severity:
normal
Tags:
#782323#5
Date:
2015-04-10 12:15:17 UTC
From:
To:
I've set /proc/sys/net/ipv6/conf/all/accept_ra to 0 (via /etc/sysctl.conf)
to protect my machine against SLAAC attacks, as suggested in the following
thread: https://lists.debian.org/debian-user/2015/04/msg00388.html
but this has no effect:

ypig:~> ip -6 a l dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:1::21f:29ff:fe04:3efb/64 scope global mngtmpaddr dynamic
       valid_lft 2591999sec preferred_lft 604799sec
    inet6 fe80::21f:29ff:fe04:3efb/64 scope link
       valid_lft forever preferred_lft forever

ypig:~> ip -6 ro l
2001:1::/64 dev eth0  proto kernel  metric 256  expires 2591995sec
fe80::/64 dev eth0  proto kernel  metric 256
default via fe80::21d:9ff:feb3:1563 dev eth0  proto ra  metric 1024  expires 30523sec hoplimit 64

ypig:~> cat /proc/sys/net/ipv6/conf/all/accept_ra
0

As a consequence, the machine can no longer connect to hosts that
have an IPv6 address (such as security.debian.org for instance),
which makes it hardly usable.
#782323#12
Date:
2022-05-31 22:35:03 UTC
From:
To:
This bug was filed against kernel version 3.16 and the chance that an upstream
kernel developer will devote time to it is ~ 0%, so I'm closing this bug.

If you can reproduce it with

- the current version in unstable/testing
- the latest kernel from backports

please reopen the bug, see https://www.debian.org/Bugs/server-control
for details.
#782323#15
Date:
2022-05-31 22:35:03 UTC
From:
To:
This bug was filed against kernel version 3.16 and the chance that an upstream
kernel developer will devote time to it is ~ 0%, so I'm closing this bug.

If you can reproduce it with

- the current version in unstable/testing
- the latest kernel from backports

please reopen the bug, see https://www.debian.org/Bugs/server-control
for details.
#782323#20
Date:
2022-06-01 09:36:03 UTC
From:
To:
Hi,

I cannot test (at least at the moment), but after some search, I may
have an explanation of the issue (this would not be a kernel bug and
the switch to systemd may have fixed it). There's an upstream related
kernel bug

https://bugzilla.kernel.org/show_bug.cgi?id=11655
  "/proc/sys/net/ipv6/conf/all/* controls don't work"

regarded as invalid, because the user was changing the settings
manually, and it is said that *.all.* variables must be set before
the device is created so that they are taken into account.

Now, in my case, I wasn't setting the variable manually, but via
the /etc/sysctl.conf file. So everything depends on when this file
is read. I've looked at old boot log files, and it was apparently
read via the /etc/init.d/procps script, which could be run rather
late, sometimes after the network was set up! So this was definitely
wrong.

Now, with systemd, there is documentation at

https://www.freedesktop.org/software/systemd/man/sysctl.d.html

which says in particular:

  The settings configured with sysctl.d files will be applied early
  on boot. The network interface-specific options will also be
  applied individually for each network interface as it shows up in
  the system. (More specifically, net.ipv4.conf.*, net.ipv6.conf.*,
  net.ipv4.neigh.* and net.ipv6.neigh.*).

So, if I understand correctly, the settings are now read much earlier,
and normally before the network interfaces show up. Thus everything
should now be fine.
#782323#25
Date:
2022-06-01 09:45:40 UTC
From:
To:
Great that you found a (potential) proper fix. I hope it works for you :-)