adrelanos
commented
8 months ago The logging of martians doesn't seem all that important. One could say that someone who wanted to look for these things would also know how to enable the logging.
So in order to fix connectivity by default, we're better off commenting these out by default.
BTW: While tracking this down to and looking at 990-security-misc.conf, I noticed a few other settings that could/will have undesirable effects in certain use cases. Perhaps there needs to be some sort of Wizard that at least lets the user be aware of what is going on under the hood without making assumptions and generalisation, allowing them to accept or mitigate the risks?
Please open separate tickets.
raja-grewal
Defaulting ether of
to a 'on'/1 value breaks thing and makes the machine very slow, even crashing it...
TL;DR; See *** at the bottom.
Join me, for a moment, in my pain and sympathise with the hours of frustration and lost sleep in getting to the bottom of this one...
I found this while fighting with Network Manager to bring a host and it's VMs up in a predictable and repeatable way, this is where the VMs are bridged to a VLAN and then to the same network, no NAT here.
This worked fine until I did the in-place upgrade/switch to KickSecure. After than networking went bad big time. On all occasions to date I backed off and resorted to manual configuration though that is not without issues. So even when not being obviously broken the machine seemed to come with an 'odd' feeling.
In trying to resolve this I found I could often take the network connection down and even hang it up for no apparent reason.
..techy bit.. ...hopefully the way I understand this is correct, happy to be informed otherwise ....
A Martian is an IP packet somehow arriving through an interface where it was not expected, regardless of transport. I.e. One that is outside of the interfaces current IP+Subnet mask ('s - pleural) defined for that interface. And, indeed from a security perspective this would be packet spoofing, ARP poisoning or a rogue DHCP.
The default state of most unconfigured Ethernet adapters is receive all broadcasts until configured or disabled. Some adapters have built in tables other's simply turn on a receive all flag and let the downstream systems handle it. Without that convention, booting over LANs would be rather unreliable. From an IP perspective a valid or invalid packet is one of many perfectly fine Ethernet broadcast frames i.e. groupcasts, non-ip Ethernet payloads, multicasts, DHCP, ICMP, ARP,...
So, logically, an unconfigured adapter has an IP address of "NONE" (I don't think that is even 0.0.0.0/0 as that is still a unicast IP address despite meaning 'this host')
If the IP is only expecting 'NONE' packets, any unicast, broadcast or multicast data arriving is..... A Martian!!! Yikes, better tell somebody....
---- Techy bit out of the way, textbooks down please...
With the sysconfig log_martians setting enabled, this results in kernel
dmesglog getting spammed (almost literally) to death. It seems (and this is new to me) the Kernel has some sort of rate timer and de-configures interfaces that spam it. I guess so as to remove the offending interface, making the assumption that there is a hardware, configuration or external issue, e.g. a packet storm.Now when you setup bridging, you don't want the bridge port interface
UPorconfiguredas that prevents you from adding it to the bridge, but obviously it must exist (i.e. have a driver) or you would also not be able to add it..(Side note about another issue, that compounds and makes this occur frequently... It seems that even for any unconfigured interface, if it is 'up' then Network Manager gets all excited and kindly takes over and 'configures' it for you... and any other interfaces it comes across while it's there. It does that even if told not to (unless made "strictly unmanaged") and will happily remove any settings (i.e. IP address) that you have added that it's unaware of. But that's that's a but for somebody else, so I'll moan about that elsewhere....
I set network manager to explicitly own but not configure the interface, so that it can build the bridge without tripping itself up, but in doing that is was still failing. So, to investigate, when I took over and activated the bridge or, if for any reason, the LAN connection breaks momentarily then NM 'reconfigures' it and.... - BOOM! No up with no IP, so the Martians arrive....
On this last occasion I was piping the dmesg log to another console, and I saw the issue occur in real time.
Suggestion. I can understand the reasons for enabling log_martians, i.e. that we want to log_martians for the benefit of detecting eves-dropping, but we must only do that on configured interfaces, perhaps as part of the if-up and if-down (i.e. those that have a valid IP connection and are up) and not just by default. It probably needs some sort of watchdog or hook that ensures a broken interfaces that does not go down through ifup/down is reset properly. Otherwise typing
ip addr delete....will still blow up.BTW: While tracking this down to and looking at 990-security-misc.conf, I noticed a few other settings that could/will have undesirable effects in certain use cases. Perhaps there needs to be some sort of Wizard that at least lets the user be aware of what is going on under the hood without making assumptions and generalisation, allowing them to accept or mitigate the risks?