{{Header}} {{#seo: |description=Host Security Guide, Hardware Considerations and Risks. This page is targeted at advanced users who wish to improve the general security of their host operating system to become even more secure. |image=Hostsecurity23342.jpg }} {{title|title= Essential Host Security }} [[image:Hostsecurity23342.jpg|thumb]] {{intro| This page is targeted at advanced users who wish to improve the general security of their host operating system to become even more secure. }} {{security_intro}} = Host Security Essentials = It is recommended to first read relevant Computer Security Education entries concerning host security, such as:
* [[Core_Dumps|Core Dumps]] * [[Firmware_Security_and_Updates|Firmware Security and Updates]] * [[Hardware_Threat_Minimization|Hardware Threat Minimization]] * [[Hostnames]] * [[Host_Firewall_Basics|Host Firewall Essentials]] * [[Host_Operating_System_Selection|Host Operating System Selection]] * [[MAC_Address|MAC Address]] * [[Malware_and_Firmware_Trojans|Malware and Firmware Trojans]] * [[Open-source_Hardware|Open-source Hardware]] * [[Out-of-band_Management_Technology|Out-of-band Management Technology]] * [[Router_and_Local_Area_Network_Security|Router and Local Area Network Security]] * [[System_Configuration_and_Access|System Configuration and Access]] * [[Disable_TCP_and_ICMP_Timestamps|TCP and ICMP Timestamps]]
= Power Saving Considerations = {{mbox | image = [[File:Ambox_warning_pn.svg.png|40px]] | text = '''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 https://github.com/jonasmalacofilho/ubuntu-luks-suspend 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 {{project_name_gateway_long}} 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: * {{non_q_project_name_long}}: Manual time adjustment is required or the VM can simply be powered off and then powered on again. 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. * {{q_project_name_long}}: After resume, time adjustment is automatic and seamless. https://github.com/{{project_name_short}}/sdwdate/blob/master/etc/qubes/suspend-pre.d/30_sdwdate.sh https://github.com/{{project_name_short}}/sdwdate/blob/master/etc/qubes/suspend-post.d/30_sdwdate.sh = See Also = * [[Advanced Host Security]] = Footnotes = {{reflist|close=1}} {{Footer}} [[Category:Documentation]]