...
 
Commits (2)
......@@ -11,17 +11,17 @@ tags:
---
At Ablative Hosting we prefer to use .onion networking everywhere we can. .onion's ensure that our web properties
can never be blocked, our employees can trust the end-to-end nature of the connectivity, our endpoints aren't exposed
in Certificate Transparency Logs. Tor prevents adversaries from trivially tapping
the upstream of our metrics or log servers and seeing the IP addresses of all our other servers _(or employees)_ when they connect.
in Certificate Transparency Logs. Most importantly; Tor prevents adversaries from tapping
the upstream of our metrics or log servers and trivially discovering the IP addresses of all our other servers _(or employees)_ when they connect.
This blog post will take you through the creation of a distributed metrics system that routes _all_ traffic via Tor .onions.
We will be working with 2 nodes, **A** and **B**. **Server A** is the hub where all metrics are sent and **Server B** is an example of
one of the many servers one could distribute around the world.
one of what could be many servers.
Whilst we normally host all our servers on OpenBSD this guide will focus on Fedora Server (32) because the external resources we'll be linking to provide additonal documentation that maps well to other Linux distros.
Whilst we normally host all our servers on OpenBSD this guide will focus on Fedora Server (32) because the external linked documentation maps well to all other Linux distros.
Overall the high level design we're aiming for is something akin to this;
At a high level the design we're aiming for is something akin to this;
```
+------------+ +-----------+ +--------------+
| Tor SOCKS5 | ------- Tor ------- | .onion | -----Tor ---- | +--------------+
......