IPv6 RA flood (THC flood_router6) causes network disconnection even after flood ceases #2977
Comments
|
Super interesting Test results.
If you stop the flood attack and restant both the whole system hangs . Kernel hangs with "soft lock" We really don't do FW stuff but yes Solutions: There are many ways to stop this attack.
We can do RA guard let's talk about it . Hm, I agree networks should not crash. But question is should we do this @poettering @teg @keszybz ? |
|
Thanks for looking into this problem. There are some challenges with your ideas towards a solution.
I would suggest a simpler solution. If you look at a Linux disto before systemd, the stack survived this kind of attack (RA flood). I ran this kind of testing at Ciena in 2012. The stack has some configurable items, including I think having configurable tables sizes for neighbors, routes and addresses, and small defaults would go along way to helping with the problem. Currently, I see a neighbor table size of around 3300, and route table size of 20,000. Using a smaller table size, and a FIFO (First In, First Out) approach to populating the tables, means that when the RA flood is over, and a real RA arrives, a bogus entry will be pushed out of the table and the real RA will be installed, thus restoring connectivity. |
|
Thanks for coming out with nice idea how we can do this.
yes . This means manually by user while under attack (not always).
Any specific reason for this ? We receive the packet and before we process anyting we first
Right but yes when trying to identify an ICMPv6 Router Advertisement message,
yes we can put a limit. I have to think more. We need to fix the crash first |
|
I agree that not being fooled by RAs encapsulated in bogus extension headers will be a nice addition. I don't think requiring a user to add a default route (with a link-local address) is all that practical. It will trip up users when the router is replaced (since the MAC address will change, and so will the link-local of the router), and it doesn't scale well (think: adding default route to a 100 machines). This is why I suggested a FIFO approach in which the correct default route would be re-established after the attack has ended (by receiving a real RA). That said, there may be other approaches which don't require manual entering of static default routes which are better than the FIFO approach. |
…lingering This is partial fix for #2228 and #2977, #3204. bridge-test: netdev ready docker0: Gained IPv6LL wlan0: Gained IPv6LL eth0: Gained IPv6LL Enumeration completed bridge-test: netdev exists, using existing without changing its parameters vboxnet0: IPv6 enabled for interface: Success lo: Configured docker0: Could not drop address: No such process vboxnet0: Gained carrier wlan0: Could not drop address: No such process eth0: Could not drop address: No such process eth0: Could not drop address: No such process eth0: Could not drop address: No such process vboxnet0: Gained IPv6LL vboxnet0: Could not set NDisc route or address: Invalid argument vboxnet0: Failed [New Thread 0x7ffff6505700 (LWP 1111)] [Thread 0x7ffff6505700 (LWP 1111) exited] Assertion 'link->state == LINK_STATE_SETTING_ROUTES' failed at src/network/networkd-link.c:672, function link_enter_configured(). Aborting. Program received signal SIGABRT, Aborted. 0x00007ffff6dc6a98 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: dnf debuginfo-install iptables-1.4.21-15.fc23.x86_64 libattr-2.4.47-14.fc23.x86_64 libidn-1.32-1.fc23.x86_64 pcre-8.38-7.fc23.x86_64 Debugging (gdb) bt "link->state == LINK_STATE_SETTING_ROUTES", file=0x5555556a34c8 "src/network/networkd-link.c", line=672, func=0x5555556a56d0 <__PRETTY_FUNCTION__.14850> "link_enter_configured") at src/basic/log.c:788 src/network/networkd-link.c:672 src/network/networkd-link.c:720 flags=0 '\000', scope=0 '\000', cinfo=0x7fffffffe020) at src/network/networkd-address.c:344 (rtnl=0x5555556eded0, message=0x55555570ff20, userdata=0x5555556ec590) at src/network/networkd-manager.c:604 m=0x55555570ff20) at src/libsystemd/sd-netlink/sd-netlink.c:365 at src/libsystemd/sd-netlink/sd-netlink.c:395 ret=0x0) at src/libsystemd/sd-netlink/sd-netlink.c:429 revents=1, userdata=0x5555556eded0) at src/libsystemd/sd-netlink/sd-netlink.c:723 src/libsystemd/sd-event/sd-event.c:2268 src/libsystemd/sd-event/sd-event.c:2629 timeout=18446744073709551615) at src/libsystemd/sd-event/sd-event.c:2688 bus=0x5555556eeba0, name=0x55555568a2f5 "org.freedesktop.network1", timeout=30000000, check_idle=0x55555556adb6 <manager_check_idle>, userdata=0x5555556ec590) at src/shared/bus-util.c:134 src/network/networkd-manager.c:1130 src/network/networkd.c:127 (gdb) f 3 src/network/networkd-link.c:672 672 assert(link->state == LINK_STATE_SETTING_ROUTES); (gdb) p link->state $1 = LINK_STATE_FAILED We should not be in this state . even if vboxnet0 failed we went into this state. vboxnet0: Could not set NDisc route or address: Invalid argument vboxnet0: Failed
|
Retested with systemd-networkd version 231. Passed Now neighbour table size is limited to below 1000, and is consistently cleaned up while under RA flood attack. Closing issue. |
Submission type
NOTE: Do not submit anything other than bug reports or RFEs via the issue tracker!
systemd version the issue has been seen with
NOTE: Do not submit bug reports about anything but the two most recently released systemd versions upstream!
Used distribution
Arch Linux
In case of bug report: Expected behaviour you didn't see
In case of bug report: Unexpected behaviour you saw
In case of bug report: Steps to reproduce the problem
Additional information
The text was updated successfully, but these errors were encountered: