That is why you have it segmented:

> Put it behind a gateway that acts as an isolating proxy.

You don't NAT - you forward the port required through the gateway machine and to the virtual machine. Either terminate Tor on the gateway and forward the web port, or terminate Tor on the web server and forward the Tor traffic on the gateway.

In that case nothing can request out from the web server. If your server needs to make requests, such as getting the latest bitcoin price - you do that on another server and run a queue that will pull the data over.

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.

You egress filter everything that isn't tor, allowing any outbound connections other than tor will cause leaks.

>And obviously if someone gains arbitrary code execution, they can just Google "my IP" and see the externally facing IP.

This is what firewalls are for

No, that's not necessary. The point is that the web server does not have Internet access: it can only access Tor (its network interface is a virtual one that can only access Tor). Any Google search for "my IP" will return whatismyipaddress.com and this site will report the IP of the Tor exit node.

I suppose running a service on IPv6 only would make it a lot harder to track down.

Only if you're trying to scan the entire address space.

For an attack like the one used here (where they found the IP) then there is no difference.

You could also start by using something more secure than PHP.

I realize that a significant portion of the internet runs on PHP, but if you are going to do something as high-risk as SR, you should use more robust tools.

Almost every HTTP server, language, and web framework has at one point had a vulnerability that exposes configuration or environment variables.

The fundamental problem is that no matter what language and server combination you choose, it was never written for hostile environments. Exposing an IP address of an internal server is considered a very low risk vulnerability (as compared to say RCE), so very little work is put into auditing for such risks.

what would you suggest? for all its faults, PHP has seen a lot of hardening efforts over its lifetime and its security flaws are well known and can be compensated for.

A lengthy hardening effort and well-known flaws to compensate for does not sound at all like a secure platform to me.

but on the other hand, it is better than having unknown security properties like e.g. ruby or javascript on node.js. While node is built on the venerable V8 engine which has strong security roots, its core libraries and dependencies are less well explored. Plus javascript is generally a terrible language for secure programming.

I'd rather have ample documentation on how to harden my PHP application than no documentation on how to harden my Node application. Security through obscurity is no security at all. Plus, many of the mitigation strategies are simply rules like "don't use mysql_query" or "use htmlentities with ENT_QUOTES and UTF-8 to escape your output", both of which can be built into a framework. See: laravel.

[edit] downvoting is much easier than formulating a response, isn't it?

You are argue that php is better then than using ruby or javascript. Now I could perhaps weight in on that somewhat dubious claim but I'd much rather ask why are you restricting the pool to php, ruby, and javascript?

Why not Python, or Go, or even Haskell? There are many languages other than the three you mention which have much better reputations for secure web programming.

You likely got downvoted because you presented a false choice to back up your argument.

I chose the languages above mainly due to their popularity outside the sphere of silicon valley - you are right that I should have included python in this list, but go and haskell are still only popular in a very restricted audience and I myself haven't used them - they may well be better for secure programming, they just didn't come to mind when I was thinking of examples.

Personally, I would go with Python.

* The language itself has a pretty good security track record * The more popular application frameworks (Django, Flask, et al.) seem to be doing pretty well * Process isolation techniques are well-known