That's correct. Most of these guys are getting cauought because they didn't believe that will have to eventually face an enemy with so many resources (FBI/NSA).

I believe that avoiding detection online can be done if you are very strict about your policies.

I don't believe DRP had the knowledge to understand and the how's and why's of a setup you're describe unlike skilled engineers[1] who design multi-layered approaches.

[1] http://www.daemonology.net/blog/2014-04-09-tarsnap-no-heartb...

  > they didn't believe that will have to eventually face an enemy with so many 
  > resources (FBI/NSA).  I believe that avoiding detection online can be done
  > if you are very strict about your policies.

I think the NSA has sufficient resources and incentive to mount a sybil/correlation attack on the Tor network.

> 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.)

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.

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.

True, this would be much more secure. My eyes glazed over the "isolating proxy" part.

By the way, upon re-reading the FBI's full report, it looks like they may not have found the IP address through the environment variable leak, but rather some of its resources (like its CAPTCHA image) were actually be served from its clearnet IP address.

If your server needs to make requests, can/should it be doing them through tor, and would that be sufficient protection?

What do you mean by terminate? I know it means end but not getting the just of what you mean

I fail to see how this was not an Illegal hacking attempt by the FBI? They want us to believe they just had some goons sit at a desk all day and just type crap into the auth box until somehow an IP address was erupted out?

That makes zero sense.