<div dir="ltr"><div dir="ltr"><div class="gmail_signature">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 <a href="http://10.0.0.0/24">10.0.0.0/24</a>, the hostname "invalid.invalid", etc...</div><div class="gmail_signature"><br></div><div class="gmail_signature">It was thinking like this which led me to draft this (now slightly dated) document; but overall it still is useful: </div><div class="gmail_signature"><br></div><div class="gmail_signature"><a href="https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-production-onion-server.md">https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-production-onion-server.md</a> </div><div class="gmail_signature"><br></div><div class="gmail_signature">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. </div><div class="gmail_signature"><br></div><div class="gmail_signature">Then: work out for yourself how to do software updates via (say) a HTTP proxy + VPN.</div><div class="gmail_signature"><br></div><div class="gmail_signature">    -a</div><div class="gmail_signature"><br></div><div class="gmail_signature"><br></div></div></div>