Essential Host Security

From Kicksecure
Revision as of 14:29, 5 December 2021 by Nurmagoz (talk | contribs)
Jump to navigation Jump to search

Kicksecure comes with many security featuresarchive.org iconarchive.today icon. 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.

Host Security Essentials

It is recommended to first read relevant Computer Security Education entries concerning host security, such as:

Hardening

Kicksecure does not yet improve host security. It is recommended to use a secure host operating system like Qubesarchive.org iconarchive.today icon or Debian GNU/Linux and manually harden it. Also follow relevant steps in the System Hardening Checklist for better security.

Hardware Component Risks

In the default configuration, Kicksecure provides significant protection against circumvention of the proxy obedience design. This includes:

  • Applications not honoring proxy settings (proxy bypass IP leaks).
  • Applications disclosing the user's real IP address (protocol IP leaks).
  • Remote code execution exploits with user-only rights (exploit + unsafe browser).
  • Remote code execution exploits with root rights (exploit + root exploit + unsafe browser).

However, if a second exploit is used to break out of the VM, the default Kicksecure installation is broken and the real IP address will be revealed. Only Kicksecure run with physical isolation will defeat this attack. This is because the Kicksecure host does not know the real IP address, only the Kicksecure which is running on another machine. This means deanonymization requires the attacker to either: exploit the physically isolated Kicksecure, subvert the Tor process, or successfully attack the Tor network at large.

Nevertheless, physically-isolated users should be aware that if an adversary manages to break out of the Kicksecure VM using an exploit, then additional risks are posed by the hardware components that are built-in or have been additionally installed. This includes CPU and HDD / SSD temperature sensors, microphones and cameras.

In the case of Kicksecure with physical isolation:

  • The real IP address is still safe, but the temperature sensors can be used for anonymity set reduction.
  • Different CPU, HDD and SSD models will report different sensor information, depending on climate and weather. If possible, it is advised to remove or to obfuscate the sensor results.
  • Webcams, microphones and speakers can be covertly activated by the adversary. Remove external hardware and/or disable them in BIOS if possible. At a minimum, cover them or ideally remove them.

In the case of a default Kicksecure installation, the same general recommendations apply, although it does not really matter since the user will have been deanonymized successfully.

Hostnames

The hostname given to a home computer or device can be leaked via a number of protocols, posing a privacy risk depending on the specificity of the naming convention. For further information, see here.

Power Saving Considerations

Warning: Upon system suspend / standby, Full Disk Encryption (FDE) keys are still kept in RAM.

Users at high risk or traveling should avoid leaving a system in the suspend or standby state. Instead, the recommended power mode to use is hibernation. This will lock all system partitions to a safe state, though there is a small trade-off in startup time.

On GNU/Linux hosts, standby will not always result in having LUKS keys retained in memory. Some experimental projects [1] and custom setups with systemd+scripting are able to erase the keys before system suspend to avoid mistakes.

Following a system standby period, the network fingerprint for Tor on the Kicksecure is identical to a standard Tor instance on the host that has gone through the same procedure. There are some old connections that go stale and need renewal, but nothing is seen by a network adversary because time leak identifiers have been stripped out of Tor's protocol / OpenSSL, and TCP Timestamps are gone.

To reconnect to Tor following a suspend / standby / hibernation period:

See Also

Footnotes

  1. ↑ https://github.com/jonasmalacofilho/ubuntu-luks-suspendarchive.org iconarchive.today icon
  2. ↑ This step will be unnecessary once hypervisor-specific post resume hooks are used, because guest clocks will be seamlessly updated upon power state changes from the host.
  3. ↑ https://github.com/Kicksecure/sdwdate/blob/master/etc/qubes/suspend-pre.d/30_sdwdate.sharchive.org iconarchive.today icon
  4. ↑ https://github.com/Kicksecure/sdwdate/blob/master/etc/qubes/suspend-post.d/30_sdwdate.sharchive.org iconarchive.today icon
Notification image
Your support makes
all the difference!

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!

Retrieved from "https://www.kicksecure.com/w/index.php?title=Essential_Host_Security&oldid=53474"