[tor-onions] Privacy Audits for Onion Services
Alec Muffett
alec.muffett at gmail.com
Thu Aug 30 16:19:11 UTC 2018
Not to put too fine a point on it: I would start by running an onion server
on a dedicated machine in a network enclave behind NAT and with
intentionally invalid hostnames, so that any/all metadata that might leak
in (say) Apache headers, is mostly useless; the NAT-internal network would
be 10.0.0.0/24, the hostname "invalid.invalid", etc...
It was thinking like this which led me to draft this (now slightly dated)
document; but overall it still is useful:
https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-production-onion-server.md
The other benefit of putting your onion servers in a NAT enclave is that
you can lock down your guards to a limited set and drill holes in your
firewall specifically for those, and then ban all other outgoing traffic
from your machine; this will help prevent identification via DNS lookups,
package update checks, pingbacks in your CMS stack, etc.
Then: work out for yourself how to do software updates via (say) a HTTP
proxy + VPN.
-a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-onions/attachments/20180830/7c5234a7/attachment.html>
More information about the tor-onions
mailing list