[turingfail]

> run a queue that will pull the data over.

Are there standards for these kind of general pseudo devices in virtual machines? (Or you would use the cut&past buffer for example?)

To my knowledge, secure sites use(d) hardware methods to guarantee a one way channel (snip half an ethernet cable, override peer/auto detection and then use udp.)

[nikcub]

You'd host the queue service on a separate machine on the private network and communicate with it using either HTTP or standard TCP (all firewalled to restrict everything else)

So you have your gateway virtual machine which has one interface to the public web and one interface to the internal network. On that network you have two or more machines:

a) is the web server, which can't make any requests out to anywhere except other machines on the same local network. It can receive tor or http traffic in from the gateway

b) other servers hosting local services, which can't make any requests out at all but can receive queries from the web server on their http/queue port. A database server for your web application would also sit on a machine like this.

You can put b) on yet another separate network behind the web server if they don't need to route out over Tor (or even if they do).

Your slicing the tasks up and isolating them on separate machines to minimize the attack surface. Someone breaking into the web server will not be able to make any queries out to the web or to tor, and will only be able to query local services servers in b) such as the queue.

RabbitMQ has an HTTP interface, 0MQ uses TCP.

The other way to do it is to isolate every machine from every other machine and implement a SOA over Tor.

Taking the example of your web server needing to know the latest bitcoin price, you would implement an API on another hidden service and restrict access to it from only your web server. The web server would then have to be allowed to make queries out over Tor, but this can remain on the Tor network and can again be restricted to only your hidden 'proxy' services.

Most people associate Tor and hidden services with sites being slow and down all the time, but that is more a function of the level of experience in the field. Tor hidden sites have a different threat model so the ideal architecture is different to most common network architectures.

[kxo]

I personally like the idea of building a machine that terminates TOR (exclusively) into VMs, allowing no other outbound (non-whitelisted) traffic.

The biggest and most obvious threat to a lot of these hidden services are application-layer attacks.

You should not be using platforms that have the ability to do vast inspection of their runtime environment or make arbitrary outbound requests.

I'm not necessarily a fan of the "SOA-over-Tor" approach for something like a Bitcoin price: the explicitly-whitelisted bitcoin-price-checker-service communicating over a small-surface API (0MQ, Rabbit (albeit this is a bit of a larger attack surface, internally)) to another VM that has externally-terminated Tor-only outbound internet access is probably easier to work with.

I should spin up a CoreOS distribution with all guest VM outbound access turned off and try out host-level Tor termination.