Thanks to Andrew, ononizing the Qubes repos is now documented here (I’ll add to Whonix wiki “onionizing repositories” section if that’s okay with you Patrick):
###Hidden Service Repos
Run the following commands in dom0 in order to use Qubes’ Tor hidden service repos for each type of VM.
Note: The cats are optional, for confirmation only.
sudo sed -i ‘s/yum.qubes-os.org/qubes-yum.kkkkkkkkkk63ava6.onion/’ /etc/yum.repos.d/qubes-dom0.repo && cat /etc/yum.repos.d/qubes-dom0.repo
sudo sed -i ‘s/yum.qubes-os.org/qubes-yum.kkkkkkkkkk63ava6.onion/’ /etc/yum.repos.d/qubes-templates.repo && cat /etc/yum.repos.d/qubes-templates.repo
qvm-run -a --nogui -p -u root $FedoraTemplateVM ‘sed -i “s/yum.qubes-os.org/qubes-yum.kkkkkkkkkk63ava6.onion/” /etc/yum.repos.d/qubes-r3.repo && cat /etc/yum.repos.d/qubes-r3.repo’
Debian and Whonix
qvm-run -a --nogui -p -u root $DebianTemplateVM ‘sed -i “s/deb.qubes-os.org/qubes-deb.kkkkkkkkkk63ava6.onion/” /etc/apt/sources.list.d/qubes-r3.list && cat /etc/apt/sources.list.d/qubes-r3.list’
Thanks to @fortasse for setting all the repos up on the .onion!
Re: why it’s not on a qubes’ onion address, I’m not sure - you’d have to check out the qubes issues and forums. I think it was something to do with Whonix having the space, and the original .onion slated for Qubes repos was not able to be used for some reason (no private key?)
Now it’s set up, I don’t think they are going to make this a priority i.e. qubesosXXXXXXXX.onion for repos.
Documentation on that question has just now been added here:
Thanks! The feeling is mutual.
The downside of such “manual” approach is the repository definitions are managed by some package, so if you modify it, you’ll need to apply further updates also manually.
I’ve added onionizing Qubes packages to the wiki based on Andrew’s steps. Awaiting reviewer sign-off.
I’ve decided to go for a general checklist of the most important ‘hardening’ ideas as a wiki entry instead and mark some items as ‘Qubes-Whonix or non-Qubes-Whonix only’.
This fits better with the Security wiki and it’s nice to have a quick reference for users who don’t want to trawl the documents and discover various things they could (or should) have done, but missed.
See the suggested entry further below. If you’re happy with it, I’ll post it straight away.
Ideas I’ve discarded:
Running hardened alpha Tor Browsers if adventurous due to near-term (December) sandboxing opportunities;
-> Scrapped this idea, since we now know sandboxing works with any Tor Browser series.
following Qubes guideline for MAC spoofing
-> Scrapped this idea.
Although this is now easy using a Debian-9 template and the latest Network Manager (see updated Qubes docs), MAC spoofing is NOT recommended for home PCs or laptops from my reading e.g. TAILS docs, because it hurts your anonymity. So, this can’t be recommended unless one is using a laptop from various locations. Plus, MAC addresses are largely hidden, especially with use of VMs and Whonix.
Anyhow, based upon the lengthy discussions in this thread and input from various people, I think this entry is now suitable for the Security wiki:
#General Hardening Checklist
It is possible to significantly harden your platform and improve the chances of successful anonymous activity. This depends upon a user’s skill level, motivations and available hardware. This checklist is intended to provide a quick overview of some of the most important issues, categorized by difficulty level (easy, moderate and difficult).
Note: some of these recommendations are Qubes-Whonix or non-Qubes-Whonix specific; they have been marked accordingly.
- To blog anonymously, follow all the Whonix recommendations to minimize threats of keyboard/mouse biometrics, stylometry analysis and other covert channels. https://www.whonix.org/wiki/Surfing_Posting_Blogging
Disabling/Minimizing Hardware Risks
- In Qubes-Whonix, only use a mouse and keyboard utilizing PS/2 ports (not USB ports) to prevent malicious compromise of dom0 (PS/2 adapters and available controllers are required);
- Do not enable audio input to any VM unless strictly required and consider disabling microphones where possible (muting on the host) or unplugging external devices; https://www.whonix.org/wiki/Computer_Security_Education#Microphone
- Preferably detach or cover webcams unless they are in use; and https://www.whonix.org/wiki/Computer_Security_Education#Webcam
- Avoiding using wireless devices, since they are insecure. https://www.whonix.org/wiki/Computer_Security_Education#Wireless_Input_Devices
Mandatory Access Control
- Enable all available apparmor profiles in the Whonix-Workstation and Whonix-Gateway TemplateVMs; and https://www.whonix.org/wiki/Security_Guide#AppArmor
- Enable seccomp on the Whonix-Gateway AppVM. https://www.whonix.org/wiki/Security_Guide#Seccomp
Passwords and Logins (Qubes-Whonix Only)
- Store all login credentials and passwords in an offline vault VM (preferably with KeypassX) and securely cut and paste into the Tor Browser; and
- Copy something else into the clipboard after pasting so the password is purged and cannot be accidentally pasted elsewhere.
Tor Browser Series and Settings
- Consider using the ‘hardened’ Tor Browser series for additional ALSR memory protections;
- Default search settings to the DuckDuckGo .onion hidden service;
- Select ‘ClearClick’ protections in NoScript;
- Run the Tor Browser Security Slider in the highest position;
- Use .onion hidden services where possible to stay within the Tor network; and
- Follow all other Whonix recommendations for safe use of the Tor Browser. https://www.whonix.org/wiki/Tor_Browser
VirtualBox (non-Qubes-Whonix Only)
- Remove a host of VirtualBox features to reduce the attack surface; https://www.whonix.org/wiki/Security_Guide#VirtualBox_Hardening
- Take regular ‘clean’ VM snapshots that are not used for any activities; and https://www.whonix.org/wiki/Security_Guide#VM_Snapshots
- Spoof the Initial Virtual Hardware Clock Offset. https://www.whonix.org/wiki/Advanced_Security_Guide#Spoof_the_Initial_Virtual_Hardware_Clock_Offset
- Install newer Tor versions via jessie-proposed-updates. https://www.whonix.org/wiki/Whonix-APT-Repository#Change_Whonix_APT_Repository
Create a USB Qube (Qubes-Whonix only)
- Prepare and utilize a USB qube to protect dom0 from malicious USB devices. https://www.qubes-os.org/doc/usb/
Networking (Qubes-Whonix Only)
- Use the Debian-8 Template for networking (sys-net and sys-firewall) since it is minimal in nature and does not ‘ping home’, unlike the Fedora Template. https://github.com/QubesOS/qubes-issues/issues/1781Disable sys-net pings to fedoraproject.org
Newer Kernels (Qubes-Whonix Only)
- Install newer kernels to benefit from additional protections (including grsec elements) being mainlined by the kernel hardening project. https://www.qubes-os.org/doc/software-update-dom0/
- Default the Debian, Whonix and Qubes package updates to Tor hidden service repositories. https://www.whonix.org/wiki/Security_Guide#Onionizing_Repositories
- Use the alpha sandbox to restrict the Tor Browser; and https://www.whonix.org/wiki/Tor_Browser#Sandboxing_Tor_Browser_in_Qubes-Whonix
- Use Firejail to restrict Firefox-ESR, VLC and other applications. https://www.whonix.org/wiki/Security_Guide#Firejail
Secure Back-ups (Qubes-Whonix Only)
- Store encrypted back-ups on a separate back-up disk that is already encrypted with LUKS. https://github.com/QubesOS/qubes-issues/issues/971
Time Stamps (non-Qubes-Whonix only)
- Disable ICMP and TCP timestamps on your host operating system. https://www.whonix.org/wiki/Computer_Security_Education#Disable_TCP_Timestampshttps://www.whonix.org/wiki/Computer_Security_Education#Disable_ICMP_Timestamps
Anti-Evil Maid (Qubes-Whonix only)
- If you have a Trusted Platform Module, use AEM protection to attest that only desired (trusted) components have been loaded and executed during the system boot. https://www.qubes-os.org/doc/anti-evil-maid/ https://github.com/QubesOS/qubes-antievilmaid/blob/master/anti-evil-maid/README
Chaining Anonymizing Tunnels
- Avoid this course of action; the anonymity benefits are unproven and it may actually hurt your anonymity and security. https://www.whonix.org/wiki/Tunnels/Introduction
Disposable VMs (Qubes-Whonix Only)
- Run all instances of the Tor Browser in a DispVM - preferably uncustomized to resist fingerprinting. https://www.whonix.org/wiki/Qubes/Disposable_VM
Email (Qubes-Whonix Only)
- Use split-GPG for email to reduce the risk of key theft used for encryption/decryption and signing. https://www.qubes-os.org/doc/split-gpg/
- In Qubes-Whonix, use dom0, Debian, Fedora and Whonix grsec templates to provide significant kernel exploit protections; and https://www.whonix.org/wiki/Grsecurity#How-To:_Qubes-Whonix
- In non-Qubes-Whonix, install the latest Grsecurity kernel on your host or KVM Whonix guest. https://www.whonix.org/wiki/Grsecurity#How-To:_Non-Qubes-Whonix
Host Security (non-Qubes-Whonix Only)
- Follow all Whonix recommendations to harden your host OS e.g. minimize the attack surface, utilize full-disk encryption, torify apt-get traffic, scan your firewall, and other measures. https://www.whonix.org/wiki/Advanced_Security_Guide#Host_Security https://www.whonix.org/wiki/Advanced_Security_Guide#Physical_Attacks
new addresses are here deb.qubesos4rrrrz6n4.onion yum.qubesos4rrrrz6n4.onion ftp.qubesos4rrrrz6n4.onion
We could probably add an ‘expert’ category to this list… any others you’d care to add?
Disable Intel ME Blobs
- It is possible to partially deblob Intel’s (despicable) ME firmware image by removing unnecessary partitions from it (warning: high risk of bricking of your computer!). https://github.com/corna/me_cleaner/blob/master/me_cleaner.py http://hardenedlinux.org/firmware/2016/11/17/neutralize_ME_firmware_on_sandybridge_and_ivybridge.html
Flash the Router with Opensource Firmware
- Flash the insecure, limited-utility, proprietary firmware on your router with a powerful open-source Linux alternative (warning: risk of bricking your router!). https://www.flashrouters.com/ddwrt-router-information https://www.flashrouters.com/ddwrt-router-information
- Libreboot is a free, opensource BIOS or UEFI replacement (firmware) that initializes the hardware and starts the bootloader for your OS (warning: incompatible with newer architecture; risk of bricking your computer!). https://libreboot.org/
Looks fine overall! Please add!
A few nitpicks…
On home PCs MAC spoofing is without positive effect. But also without negative effect. (=“not useful”) Doing it for a home PC / notebook is most useful if spontaneous travel may happen. If that is excluded, indeed then it’s not useful.
It’s actually not so much about blogging. Any posting in any forum post anywhere applies as well. Also any chat / file send. So Surfing_Posting_Blogging really is an a name for that page that leaves room for improvement. The content is important, but page name, titles and presentation is leaves room for improvement.
As for subjects… If you are going to add
Disposable VMs (Qubes-Whonix Only)… Perhaps make that just
Disposable VMs (as subject)
Only reason for that: It’s because anchored links become ugly when using certain special characters such as
The General Hardening checklist is awaiting reviewer sign-off.
OK, I think this thread is done
Time to revisit sandboxing Tor Browser in Qubes-Whonix and see if it now works with the Qubes kernel based on feedback you got recently. Then, that sandboxing wiki entry can be finalized.
Also, once coldhak releases the Fedora grsec kernel for Qubes in the next few weeks, the grsec wiki entries can be added to. I’ll probably have time to test if grsec works also in the Whonix templates using the default Debian template instructions, because I’m impatient and willing to smash a template or two.
One nitpick. What I find non-ideal is using external links (
https...) rather than
[internal links]. As well as using references for major points.
* Disable ICMP and TCP timestamps on your host operating system.<ref>https://www.whonix.org/wiki/Computer_Security_Education#Disable_TCP_Timestamps</ref> <ref>https://www.whonix.org/wiki/Computer_Security_Education#Disable_ICMP_Timestamps</ref>
* [[Computer_Security_Education#Disable_TCP_Timestamps|Disable ICMP timestamps]] and [[Computer_Security_Education#Disable_ICMP_Timestamps|disable TCP timestamps]] on your host operating system.
I envisioned to use footnotes for stuff that is less important for users.
- To hide complexity from someone who just wants to absorb the information. To present the complexity in smaller steps.
- More detailed technical reasoning why one or another thing is stated. This gives people who want to question/audit this information on why it was done. So they and we are spared from a lot questions. Also because it’s a lot stuff which is easily forgotten in a year from now.
- To back up controversial / unpopular claims. For example under Windows Hosts we say:
This feature includes a kill switch that can allow Microsoft (or any one with an exploit for this mechanism) to delete programs on your machine without your consent.
- For someone not into that topic it sounds outrageous and unbelievable this easily triggers a “conspiracy theorist bullshit” thought. Therefore we back it up with a reference to a PC magazine saying the same and going into details. http://www.pcmag.com/article2/0,2817,2400985,00.asp
What do you think?
I was only using external links, because my knowledge of the wiki platform and editing is almost non-existent So, I can change all those to internal links easy enough.
Re: major points, do you want that stuff fleshed out in summary detail for each bullet point that is an external reference e.g. a paragraph or two or more? Is that the idea?
That fleshing out might make less sense for internal links, since we’d just be repeating ourselves with information already available in the wiki. But, if you think it improves readability, then I can paraphrase existing material in the wiki if you’d like.
I think almost all the points were footnoted/referenced, so not sure which claims are controversial there and not backed up. Which ones do you think - maybe the VPN hurts your anonymity claim? Others?
PS We have advice throughout the wiki to use strong and unique passwords, to change passwords and so on, but I don’t think any actual recommendation on how this is done properly. I think it belongs in the Security Guide somewhere.
My thinking is showing people how quickly password hashes under 12 characters can now be brute-forced, and people should be defaulting to Diceware passphrases of 6 or 7 random words in length, particularly for encryption/decryption, accounts and email signing.
This puts their passwords beyond bruteforce cracking by 3 letter agencies, until quantum computers are utilized in the future.
I didn’t mean to suggest that.
I also vary of duplication. Then we may be better of moving it rather than duplicating.
I haven’t made my mind up about that. If I hear an argument on what improves usability, by all means, I am listening.
Sorry, I was just speaking generally on how I envisioned footnotes to be used. Perhaps I should have made that a separate post. (Nothing controversial / not backed up in your edits.)
OK - I understand you now.
I fixed up the General Hardening Checklist with internal references etc. I agree, it looks a lot nicer now.
I also added Diceware passphrases under the Passwords and Logins category to prevent the feasibility of successful brute-force attacks without quantum computers.
You know that research shows that 123456 is still one of the most popular passwords out there? LOL
Thanks. Has already been added to the wiki entry.
Tor onion instructions may require some changes.
should use tor+http / apt-transport-tor rather than Acquire::BlockDotOnion "false";:
Fixed. changed to -> tor+http in various places in the security wiki.
I also added email provider suggestions to the relevant section under the hardening wiki entry, and noted that sandboxing Tor Browser in non-Qubes-Whonix is blocked due to Whonix 14 developer repository issues.
A post was split to a new topic: Should we recommend to avoid WiFi?
A post was merged into an existing topic: firejail / seccomp / More Options for Program Containment