Following Enno’s research on “Testing RFC 6980 Implementations with Chiron“, we decided to redo the experiment with FreeBSD targets.
The lab setup was very similar:
- A Cisco Catalyst 3560 switch running the software “C3560c405ex-UNIVERSALK9-M” version 15.2(2)E4 connecting
- A Linux based attacker system running Chiron and
- A FreeBSD target system, running different OS versions and configurations and
- A Linux based laptop running a control script that remotely performed the necessary tasks on the two machines mentioned above
The main question was: Would the impact on the target system and the possible attacks that were observed with the Windows Server 2016 victim be reproducible on other operating systems? Or would those behave totally differently?
Our testing procedure was simple: First, we manually tested if router advertisements could be successfully sent and be accepted by the target system without any countermeasures taken. Second, we manually tested the functionality of RA guard on the switch by verifying that the RA would not be delivered when it was enabled.
Last we had a script do the testing procedure for us which consisted of the following steps for each of the cases laid out in the initial post:
- Execute tcpdump on both attacker and target
- Execute the chiron command for the current test on the attacker machine
- Stop tcpdump on both machines
- Write the target route (netstat -r) and IP (ifconfig) information to files
- Collect both pcap files and the target route and IP info and save them on the control system
- Reset the target network interface to ensure a clean state for the next test
- Proceed to next test case
The baseline chiron command was the same as in Enno’s experiment:
./chiron_local_link.py enp0s25 -ra -pr 2001:db8:10:50:: -pr-length 64 -mtu 1400 -s fe80::ee9a:74ff:fef5:a385
(For further reference on the exact usage of chiron please see the manual.)
This automated setup enabled us to test various OS versions and configurations in a rather short amount of time, simply needing to execute it once with the attacker connected to a port without RA guard enabled and once with the attacker connected to a port where RA guard was enabled.
We started testing on a FreeBSD 11.0 target system which behaved just the way the Windows Server 2016 instance in the other tests. Then we switched to FreeBSD 10.3 as this is still a supported stable version.
As FreeBSD 10.3 doesn’t activate IPv6 without further configuration, we needed to explicitly activate IPv6 and the router solicitation daemon (rtsold):
With this configuration, some of the attacks that were possibe without and even with RA guard on the other systems didn’t have any impact.
Observing this, we redid the tests on FreeBSD 11.0 adding the same configuration, just to see it behaved like before, and not like the 10.3 as we we’d expected.
To summarize the results:
- The behavior of a plain unconfigured FreeBSD 11.0 is completely analog to Ennos results with Windows Server 2016
- The behavior of the FreeBSD 11.0 with the exact same configuration from the handbook doesn’t differ from an unconfigured 11.0
- The behavior of a FreeBSD 10.3 with the IPv6 confguration referenced in the handbook differs a lot
- With FreeBSD 10.3 most of the attacks don’t even work without RA guard
- With the combination of RA guard and FreeBSD 10.3 it was possible to thwart all attacks that had been previously possible