Kicksecure Network Configuration

Needed for wifi support

For dhcp client it comes down to dhclient vs dhcpcd

Per [Solved] Confused about dhclient and dhcpcd / Networking, Server, and Protection / Arch Linux Forums 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

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.

1 Like

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.

1 Like

Posted on social media too.

1 Like

Decided to close github draft PR.

The additions to the to the are:

## Network optimisation

* Increases the size of the receive queue and the number of maximum connections.

* Increases memory dedicated to the network interfaces.

* Raises the default UDP limits.

* Enable TCP Fast Open to reduce network latency.

* Raise the number of pending connections in order to be more resistant to simple DoS attack.

* Disables TCP slow start after idle.

* Reduces the TCP keepalive time.

Creation of the file etc/sysctl.d/30_network-opt.conf containing:

## Copyright (C) 2019 - 2023 ENCRYPTED SUPPORT LP <>
## See the file COPYING for copying conditions.

## Improvements in networking performance largely based on Arch's recommendations

## Increasing the size of the receive queue

## Increase the maximum number of connections

## Increase memory dedicated to the network interfaces
## Set max cache size (in bytes) to 16MB
## These settings are for extremely fast connections and likely allocate excessive memory for typical networks
net.ipv4.tcp_rmem=4096 1048576 2097152
net.ipv4.tcp_wmem=4096 65536 16777216

## Increase the default UDP limits

## Enable TCP Fast Open for both incoming and outgoing connections

## Raise maximum queue length of pending connections

## Raise maximum number of sockets in TIME_WAIT state

## Let TCP reuse an existing connection in the TIME-WAIT state

## Seconds to wait for a final FIN packet before the socket is forcibly closed

## Disable TCP slow start

## Change TCP keepalive parameters
## Reduces the TCP keepalive period from 2 hours to 2 minutes
1 Like