Kicksecure Network Configuration

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.

1 Like

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?

1 Like

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.

1 Like

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:

  1. Create performance-misc and include these changes, or
  2. If the creation of performance-misc is premature, merge into security-misc for 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.

1 Like

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.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]