I learn something new everyday
Does this belong in the kicksecure-network-conf package too?
For now, yes.
(I will later create a
kicksecure-network-conf-gui package to refactor that out but that has time.)
Let me know when you have a buildable branch with these changes. New releases are overdue with Tor’s new DoS fixes
Maybe this could help you; this is a list of required dependencies and recommendations from this exact package on an Ubuntu system I maintain:
network-manager-gnome (requirements and recommendations)
libjansson4 (various versions depending on distro)
libmm-glib0 (various versions depending on distro)
dhcpcanon systemd unit fails at boot due to missing debhelper apparmor integration
Will remove dhcpcanon because broken anyhow. And no reaction from upstream.
Also dhcpcanon is not integrated with NetworkManager therefore not used anyhow.
Will also remove ifupdown configuration file
/etc/network/interfaces.d/30_kicksecure because we’re now using NetworkManager and having that config file would make eth0 unmanaged by NetworkManager.
If anyone has better ideas for Kicksecure host network configuration let me know.
- https://packages.debian.org/buster/iw (existing default package)
- https://packages.debian.org/buster/wpasupplicant (should be added?)
Needed for wifi support
For dhcp client it comes down to dhclient vs dhcpcd
Per https://bbs.archlinux.org/viewtopic.php?id=152376 NetworkManager uses dhclient by default to manage dhcp leases so this is what we should use.
dpkg -l | grep dhc shows no packages. And allegedly network-manager has its own internal DCHP client included. Therefore not changing any packages.
There appears to be several areas where we could improve networking performance across all systems while not comprimising security (even perhaps increasing).
Based on including subsections “Increasing the size of the receive queue” → “Enable MTU probing” from the Arch wiki:
Some of these will demand more CPU and memory usage on high bandwidth systems.
Additionally, the “Tweak the pending connection handling” section highlights how the system can be made more robust to DoS attacks in combination with kernel hardening settings we are already using.
I have been using these parameters and the default and have noticed some decrease in latency.
Thoughts on including any of them?
I guess if primarily for better performance, that would be best kept outside
security-misc and placed in a separate package
performance-misc or so.
Yes the primary benefits would be network performance. Especially for whonix users given the slowness of Tor. People using typical VPNs may also benefit with having increased UDP limits (as these services scarcely use the TCP protocol, at least by default).
The added protections against DoS attacks would also be quite effective as they are going to be combined with existing sysctl parameters in security-misc.
I have committed the changes on a local branch shown below:
Two possible strategies moving forward are:
performance-miscand include these changes, or
- If the creation of
performance-miscis premature, merge into
security-miscfor now and separate the changes later.
For Kicksecure there isn’t any network level fingerprinting concern.
For Whonix there is but probably the other security hardening might already worsen the network fingerprint at ISP level.
Probably a lot better.
Since performance isn’t related to security. Also security-misc is already doing lots of things which risks breaking corner cases. Mixing it even more would make it harder to debug.
It’s not fingerprinting that concerns me, but the security implications which are still valid for KS.
Disabling MTU probing was necessary along with some other TCP options to mitigate the SACK vuln. You might say that it is fixed and water under the bridge, but the argument still stands that the less functionality turned on in the kernel the safer and really that’s the only thing we care about here as long as performance is usable and acceptable.
If your system is prone to these TCP SACK PANIC vulnerabilities, you need to take quick action by disabling the vulnerable component. Alternatively, you can use iptables to drop connections whose MSS size can successfully exploit the vulnerability. The second is more effective as it mitigates the three vulnerabilities. To prevent connections with low MSS, use the following commands for traditional iptables firewalling (Note: You need to disable net.ipv4.tcp_mtu_probing for this fix to work effectively). This drops all connection attempts whose MSS size ranges between 1 and 500.
Other articles about TCP stack problems and mitigations. I think this should be incorporated in security-misc if not already.
Agreed, I will revert the enabling of MTU probing when a ICMP black hole is detected.
However, other proposed settings relating to connection handling would harden against DoS attacks.
Regarding networking performance being usable and acceptable. I believe that is very subjective since many people do not have gigabit connections. Speedtest’s global median fixed broadband speed in August 2022 is ~70mbps. Assuming multiple other household devices/users it is reasonable to assume the median is much lower.
Combining this with slowness ToR, I think providing end users the maximum possible networking speeds is advantageous provided zero security compromises are made. Excluding the MTU probing setting, I think the other proposed changes appear to only have a networking performance upside.
The list proposed in sysctl - ArchWiki is huge. One shouldn’t blindly turn options on and hope for the best. Some of the stuff on there like TCP Timestamps is being recommended for security, but we know all too well the downsides. It will take a lot of time to research every parameter on there such as Google’s BBR routing. Some of these may have security or anonymity consequences yet to be discovered because there isn’t enough interest or eyes on the code. We don’t have time at the moment to look into it.
I understand and yes the list on the Arch wiki is huge. However, I am not at all suggesting that all the sysctl’s should be copy pasted, especially not enabling TCP timestamps or BRR routing.
Instead, what I was proposing (and commited) was a far smaller list of curated inclusions. These largely involve increasing total connection limits and allocated memory while making TCP connections more robust. Though due to time limitations, this topic can certainly be revisited at a later date.