Security Best Practice: Fortify the Gateway – Use Kicksecure as Your sys-net Template
In our previous posts, we fortified the network stack by silencing clearnet leaks and made the network controller disposable. We treated the perimeter with suspicion. Then we established the cardinal rule: never connect a Template directly to the internet.
But there is one more layer of defense we have yet to address.
Even when following all the rules, even when keeping templates isolated, there remains a consideration: the template itself.
The default sys-net template in Qubes OS is Fedora, a general-purpose operating system designed for broad compatibility. It is the foundation upon which your network infrastructure qube runs.
While Qubes OS is explicitly designed to handle the compromise of individual qubes, including sys-net, without catastrophic system-wide failure, reducing the attack surface of network-facing components remains sound security practice.
This is where Kicksecure enters the equation.
The Exposure of sys-net
Let us be clear about the threat model.
sys-net is the component in Qubes OS that directly interfaces with your physical network hardware. It is the only qube that has direct access to your Wi-Fi card, Ethernet controller, and the outside world.
This makes it the most exposed component in your entire system.
Every packet that enters your machine passes through sys-net first. Every connection, every handshake, every potential exploit vector flows through this gateway.
What Qubes Architecture Assumes
Qubes OS explicitly assumes that network-facing qubes may become compromised. That is why:
sys-net is isolated from dom0
sys-firewall exists as a separate qube
Disposable networking is possible
USB devices are isolated
dom0 is air-gapped from networking
A compromised sys-net:
Does not automatically compromise dom0
Does not automatically compromise other qubes
Does not automatically bypass compartmentalization
However, a compromised sys-net can manipulate traffic or perform man-in-the-middle attacks on unencrypted connections. Reducing the likelihood of that compromise through template hardening is therefore valuable.
Why Template Choice Matters
Fedora is an excellent distribution. It is stable, well-maintained, and widely supported. But It is a general-purpose OS with:
Standard kernel configurations
Default security settings optimized for usability
Broad hardware compatibility over hardened defaults
A large attack surface from bundled services
For sys-net, it is a liability.
Kicksecure is a security-focused operating system that provides the base for Whonix. It offers additional hardening compared to stock Fedora through:
Stricter defaults: Conservative configuration out of the box
Reduced telemetry: Less data transmission to external services
Hardened sysctl settings: Kernel parameters tuned for security
More conservative service exposure: Fewer running services by default
Additional hardening configurations: Security-focused system tuning
AppArmor confinement: Mandatory access control for services
Security-focused packaging decisions: Careful review of included software
Replacing Fedora with Kicksecure for sys-net is best understood as incremental defense-in-depth, not a dramatic architectural security leap. Qubes security fundamentally depends more on Xen isolation and compartmentalization than on whether sys-net uses Fedora or Kicksecure.
However, for users operating under serious threat models, every layer of hardening counts.
The Implementation
The process is straightforward. Follow these steps:
Step 1: Download and Install Kicksecure Template
Open a terminal in dom0:
Qubes Menu > System Tools > Xfce Terminal
Run the following command to install the Kicksecure template:
qvm-template install kicksecure-18
Wait for the download and installation to complete. This may take several minutes depending on your connection speed.
Verification:
After installation, verify the template is available:
qvm-template info kicksecure-18
You should see the template listed with its version and status.
Step 2: Prepare the Template for sys-net
Before switching templates, ensure sys-net is shut down.
Shut Down sys-net:
Open Qubes Manager.
Right-click on sys-net.
Click Shutdown.
Change the Template:
In Qubes Manager, right-click on sys-net again.
Hover over the Templates menu in the context menu.
Select kicksecure-18 from the list.
Click Yes if a confirmation dialog appears.
Restart sys-net:
Right-click on sys-net in Qubes Manager.
Click Start/Resume.
You may need to re-enter your Wi-Fi password.
The Trade-off: Stability vs. Security
As with all security hardening, there is a cost.
The Consequence
Kicksecure is more restrictive than Fedora. Some hardware drivers or network configurations that work on Fedora may require additional configuration on Kicksecure.
Potential Issues:
Driver Compatibility: Some proprietary Wi-Fi drivers may not be available in Kicksecure.
Network Configuration: You may need to reconfigure network settings manually.
Mitigation:
Test the configuration before relying on it for critical work.
Document any custom configurations for future reference.
The Bigger Picture
This configuration is another expression of "Security by Architecture."
By replacing Fedora with Kicksecure for sys-net, you are not creating an impervious fortress, you are raising the security baseline of your network infrastructure qube incrementally.
You are acknowledging that:
The network gateway deserves additional protection beyond the default.
General-purpose OSes are not optimized for high-risk roles.
Security hardening should be applied at every layer where feasible.
Defense-in-depth means stacking reasonable measures, not relying on any single one.
This is the essence of compartmentalization: each component receives the security posture appropriate to its risk profile.
Remember: Qubes OS's fundamental security comes from Xen isolation and compartmentalization. Kicksecure is an additional layer, not a replacement for proper architecture
Stay vigilant. Stay compartmentalized.
