Advanced Host Security

From Kicksecure
Jump to navigation Jump to search

Kicksecure comes with many security Kicksecure is Security Hardened by default and also provides extensive Documentation including a System Hardening Checklist. The more you know, the safer you can be.

This page is targeted at advanced users who wish to improve the general security of their host operating system to become even more secure.


apt-transport-tor is a package that allows host operating systems or non-Kicksecure VMs that are not behind a torifying gateway (like Kicksecure) to torify their APT traffic for individual repositories.

With non-Kicksecure systems in mind, for security reasons APT blocks clearnet connections to .onion domains by default. APT developers want to protect users from accidentally trying to use .onion repositories without using Tor. Otherwise, a rogue DNS server could redirect users to a false domain and trick them into thinking they are using Tor when they are not.

apt-transport-tor (tor+http) is the default from Kicksecure 14 onward because it provides better error handling. [1] [2]


If users have a shared network -- such as a cable modem/router or ADSL/router setup that is utilized by others -- then consider configuring a Kicksecure

A properly configured DMZ restricts Kicksecure from accessing, and being accessible to, other nodes on the network like printers, phones, computers and laptops. This is true even if root access is somehow achieved.

Should an incursion take place, a DMZ prevents an adversary from exploring other systems and possibly compromising them. However, in this case a DMZ does not protect the user's anonymity, since the adversary could just ping a remote server and discover the real IP address. Another benefit of a DMZ is that should other systems be compromised, it is more difficult to compromise Kicksecure.

Hardware Security[edit]

Info Kicksecure cannot provide protection against hardware backdoors.

Trusted computer hardware is fundamental to security. It is recommended to purchase and use "clean" computers that have components manufactured by reputable companies. It is preferable to pay in cash so hardware IDs do not leak your identity.

As outlined in the System Configuration and Access entry, it is safest to purchase a computer that is solely used for Kicksecure activities because this minimizes the risk of a prior hardware compromise.

Key Hardening Steps[edit]

For greater security, advanced users should harden the host operating system (OS) as much as is practicably possible. This includes, but is not limited to applying relevant steps from the System Hardening Checklist and instructions found throughout this section:

Layered Defense[edit]

Attack Surface Reduction[edit]

In addition to the checklist above, it is suggested to also follow the principles of minimizing the attack of the OS, and securely configuring services -- for example when using SSH, implementing so only key authentication is allowed.

The attack surface concept deserves more consideration. Simply put, it is the sum of different attack vectors (aggregate of vulnerabilities) where an unauthorized user can try to enter or extract data from an environment. [3] To reduce the attack surface and mitigate risks, it is necessary to: [4]

  • Enforce least privilege for all executed processes and reduce entry points for untrusted users.
  • Control system and network segment access across the network, for example, reduce (unauthenticated) access to network endpoints.
  • Minimize exposed system targets by reducing the amount of code running and removing unnecessary functionality.
  • Remove or shutdown software and services (channels, protocols) that are infrequently or rarely used.
  • Frequently patch security vulnerabilities.

Proactive Defenses[edit]

This includes, but is not limited to:

Retroactive Defenses[edit]

The usefulness of this approach is limited because it does not prevent security breaches; it can only help in making future breaches less probable:

The programs listed in this section are only a very brief introduction to this topic. If interested, users should research these topics in depth because they are beyond the scope of this guide.

Separate VirtualBox User Account[edit]

Security-wise, it makes sense to create a separate user account solely for using VirtualBox, which is not in the admin/sudo group.

Virtualization Platform[edit]


VirtualBox is developed by Oracle, a company which has a reputation of not being very "open". In the past, concerns have been raised about how they announce security issues in their products and how well they communicate with each other, leading to a negative perception by the security community.

VirtualBox is primarily a simple, "user-friendly", desktop solution and is most certainly not designed with the Kicksecure threat model in mind. Development is reported to be at a standstill and the author is not aware of any serious code audits having been completed. [5] Kicksecure developers would like to recommend a different VM solution at least as an alternative, but many popular, open source options like KVM and Xen are not cross-platform. Further, the latter examples seem to still lack a reliable "internal networking" feature, which Kicksecure heavily depends upon. Any readers who have in-depth knowledge of this issue are encouraged to edit this paragraph accordingly.

Users that have a strong preference for security should strongly consider using Kicksecure for Qubes, if they have suitably modern hardware. In short, Kicksecure for Qubes is more secure than the default Kicksecure configuration using a Type 2 hypervisor like VirtualBox.

Related VirtualBox Links:

See also:

Secure Labeling[edit]

VirtualBox has a secure labeling feature (VBoxSDL) which has not yet been implemented in Kicksecure. [6] This feature addresses the security risk of running in full screen mode:

When running guest operating systems in full screen mode, the guest operating system usually has control over the whole screen. This could present a security risk as the guest operating system might fool the user into thinking that it is either a different system (which might have a higher security level) or it might present messages on the screen that appear to stem from the host operating system.

In order to protect the user against the above mentioned security risks, the secure labeling feature has been developed. Secure labeling is currently available only for VBoxSDL. When enabled, a portion of the display area is reserved for a label in which a user defined message is displayed. The label height in set to 20 pixels in VBoxSDL. The label font color and background color can be optionally set as hexadecimal RGB color values.

Any readers who are knowledgeable in this area are encouraged to share their expertise and edit this section accordingly.

See Also[edit]


  1. source:

    That said, it might make sense to use a-t-tor anyhow even if not strictly needed as it will deal better with certain tor anomalies given that it knows tor is involved reporting better errors (like telling you that the .onion address you typo'ed is too long/short; saying "unreachable host" if a service is… well, not reachable, instead of saying "TTL expired" which is reported by Tor and technically more correct but unhelpful), will use different circuits for different sources and stuff.

  2. For instance it reports if the .onion address is too long or short, and will use different circuits for different sources.
  3. Wikipedia: Attack
  6. Partially because it is not available on the macOS platform.

Unfinished: This wiki is a work in progress. Please do not report broken links until this notice is removed, use Search Engines First and contribute improving this wiki.

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!