Documentation on that question has just now been added here:
Advanced Security Guide - Whonix

Information Booster might be Available!
Utilizing other resources to help solve questions/issues unspecific to Whonix ™.
Thanks! The feeling is mutual.
Thanks again! However, I should note that @marmarek pointed out a significant limitation of doing this manually:
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.
Thanks, Patrick!
I’ve added onionizing Qubes packages to the wiki based on Andrew’s steps. Awaiting reviewer sign-off.
Thanks!
Done.
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.
###Easy
Blogging
Disabling/Minimizing Hardware Risks
Mandatory Access Control
Passwords and Logins (Qubes-Whonix Only)
Tor Browser Series and Settings
VirtualBox (non-Qubes-Whonix Only)
Whonix Updates
###Moderate
Create a USB Qube (Qubes-Whonix only)
Networking (Qubes-Whonix Only)
Newer Kernels (Qubes-Whonix Only)
Onionizing Repositories
Sandboxing
Secure Back-ups (Qubes-Whonix Only)
Time Stamps (non-Qubes-Whonix only)
###Difficult
Anti-Evil Maid (Qubes-Whonix only)
Chaining Anonymizing Tunnels
Disposable VMs (Qubes-Whonix Only)
Email (Qubes-Whonix Only)
Grsec Templates
Host Security (non-Qubes-Whonix Only)
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?
###Expert
Disable Intel ME Blobs
Flash the Router with Opensource Firmware
Install Libreboot
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)
’’‘Qubes-Whonix Only’’’
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.
Cheers
Thank you!
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>
Proposal.
* [[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.
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.
What do you think?
No problem.
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.
Awaiting signoff.
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";:
https://phabricator.whonix.org/T6101
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.
I was wondering this as well. Any updates on this?
If I would make this change away from the standard would this mean my ‘fingerprint’ would become more unique, or a change list this wouldn’t matter?
Any updates on this?
I doubt there will be ever any updates unless contributed.
This is a Tor Browser issue and unspecific to Whonix. So nothing from Whonix required for contacting The Tor Project.
If I would make this change away from the standard would this mean my ‘fingerprint’ would become more unique, or a change list this wouldn’t matter?
Utilizing other resources to help solve questions/issues unspecific to Whonix ™.