Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Subscribe to our newsletter

Advertise on LowEndTalk.com

Latest LowEndBox Offers

    Possible?
    New on LowEndTalk? Please read our 'Community Rules' by clicking on it in the right menu!

    Possible?

    GCatGCat Member
    edited January 2016 in Help

    I was thinking, is it possible to do this sort of configuration for a tor hidden service?

    Pretty much the tor HS is hosted on a server (container), and the container is confined to an internal-only network (no public IP, only internal), but still has network connectivity?

    I was thinking likely possible in a OVZ container, just force that VM traffic threw TOR on the main box, however there must be a simpler way?

    The advantage of this style setup, is the backend IP address of the hosting server is significantly harder to find, DNS-masking (no leaking of DNS), no public IP, etc.

    Thoughts?

    Thanked by 1rokok

    My comments are mine and mine alone, and do not reflect the opinion of my business

    Comments

    • GM2015GM2015 Member
      edited January 2016

      @linuxthefish @william @netomx

      IIRC they've heard of tor.

      Thanked by 2GCat raindog308

      Go give Vultr(referral) a try. | GNU/Linux http://debian.org

    • Yes, just set Tor up as a transparent proxy and block traffic with iptables or remove gateway.

      Thanked by 1netomx
    • netomxnetomx Member, Moderator

      Tor on the host node, openvz with internal ip, and proxy your app through tor?

    • WilliamWilliam Member, Provider

      Exactly, if you need outbound.

      This also works for inbound aka hidden service as it does nat traversal fine.

      With this you effectively avoid "getting silkroad'd" by your own captcha provider.

      Thanked by 1GCat
    • Sign up to tor-announce and tor-news if you are running something you want to keep secret, you need to keep tor up to date. If you don't bother upgrading and you run a hidden service it could be game over if there is a 0day and you don't patch or shut the service down!

      And just because your hidden service can't talk to the internet does not mean it can't be found, there are still traffic correlation attacks you need to look at as well as basic stuff like connecting with your own connection to the actual server. I bet Ulbricht would have got off a lot lighter or not been caught at all if the server was not connected back to him, or bothered to check dmesg to see a drive had been removed...

      But yeah, allowing your hidden service to talk to others is just plain stupid.

      Thanked by 1GCat
    • @linuxthefish @William

      Would a server with public IP (KVM box), add a virtual adapter with internal-only IP address, and the web server / PHP / MySQL is run in jailed shell with very little CLI commands executable work?

      My comments are mine and mine alone, and do not reflect the opinion of my business

    • WilliamWilliam Member, Provider

      linuxthefish said: And just because your hidden service can't talk to the internet does not mean it can't be found, there are still traffic correlation attacks

      Yea, but how are you going to tell me if 100ms from Vienna is now in New York or Tashkent (and what if the route is just shit and going over HK)... this works in a circle radius, you know...

      "Real" traffic correlation, as in large scale out of a foreign provider, can only be done by government agencies and even then only very limited ones (i.e. with enough international endpoints to source data from, NSA+partners, GCHQ/UK without NSA, China for asian area, Russia for eastern europe, BND for much of Europe, Israel possibly as well and so on)

      Thanked by 1GCat
    • I'm not an expert in the Tor protocols, so I could be missing some security features in my analysis, but I think it's not that hard to localize a server that can only talk to the Internet through Tor even without wiretap capability (let alone so extensive as to allow traffic correlation).

      Say we find an exploit in LAMP stack or whatever is serving the HS that lets us introduce a program on the server. Of course, if everything is piped through Tor, the program can't call home directly. But, it can "call home" through Tor ... and it can send data through Tor at a modulated rate (i.e., specific delays between packets that can be recognized). Then, controlling only a few Tor nodes, eventually the stream will go through such a controlled node and it can be recognized by the packet delay pattern. We keep track of all the peer IPs we see sending us such a stream. If entry guards are not being used, game over, the most frequent peer IP will the HS server itself. If entry guards are being used, the most frequent IPs will be them. In this case, we tell the program to switch from a modulated pattern to just sending data at a regular rate. Then send spoofed origin RST packets to the entry guards, scanning the entire IPv4 space (or maybe parts of it that correspond to hosting rather than end users if the HS appears to have a lot of bandwidth). When the correct IP/sequence number combination is sent, the connection will drop momentarily (and this will be noticed wherever the data is being sent to). If the RST packets were being sent at a high rate, we won't have a unique IP, but the possibilities will be narrowed to a small range. Then just repeat the process a few times, going slower and slower over the rapidly narrowing range until a single candidate IP remains.

      Thanked by 1perennate
    • I'm sure @deadbeef would be glad to help you with Tor based on your past conversations.

      singsing said: I'm not an expert in the Tor protocols, so I could be missing some security features in my analysis, but I think it's not that hard to localize a server that can only talk to the Internet through Tor even without wiretap capability (let alone so extensive as to allow traffic correlation).

      Thanked by 2GCat deadbeef

      Go give Vultr(referral) a try. | GNU/Linux http://debian.org

    • GM2015 said: I'm sure @deadbeef would be glad to help you with Tor based on your past conversations.

      As always, it is easier to argue than to actually know anything about what you're arguing about.

      But my point is relying on Tor is a bad idea, and it will only get worse as in time (I expect progress in defeating it to be faster than progress in improving it).

    • I don't use tor, especially because of the paranoia that goes around it. I don't need the headache. Proxies and openvpns are fine, which can all traced back to me, but whatever. I don't do stuff that would cause anyone trouble.

      I'm still waiting for the local repairmen to come out and turn my computer on. Damn bastards have been promising to come out for 40 years and we're still waiting for our computers to be turned on.

      singsing said: But my point is relying on Tor is a bad idea, and it will only get worse as in time (I expect progress in defeating it to be faster than progress in improving it).

      Go give Vultr(referral) a try. | GNU/Linux http://debian.org

    • I use Tor sometimes just as a matter of support for the concept of anonymity. Not that often though because I have little need myself.

      As for the OP's suggestion that the IP of the hosting server can be found, that suggestion should really be accompanied with at least some proof of concept.

      Just for the record, I run several onion sites. If anybody is interested, here is the diary of Red Ruler: http://ut3rclysspto2533.onion For those that don't know how to use Tor (surely not anybody here!) you can add .glass or .link to the end of that URL in order to reach it from the clearnet.

    • GM2015 said: I don't do stuff that would cause anyone trouble.

      It's somewhat sad that everyone thinks Tor is being used only for illicit purposes.

      It's great for just surfing the (100% legit) web, and raising the cost of spying on you a few notches.

      Thanked by 1Ole_Juul
    • perennateperennate Member, Provider
      edited January 2016

      singsing said: Say we find an exploit in LAMP stack or whatever is serving the HS that lets us introduce a program on the server. Of course, if everything is piped through Tor, the program can't call home directly. But, it can "call home" through Tor ... and it can send data through Tor at a modulated rate (i.e., specific delays between packets that can be recognized). Then, controlling only a few Tor nodes, eventually the stream will go through such a controlled node and it can be recognized by the packet delay pattern.

      I think that's mostly true, but entry guards make this much less likely to succeed. In summary, Tor client will restrict the relays to use as entry points to a small number of entry guards (which are chosen randomly on each client). This restriction is persistent, so waiting over time won't help.

      (note that, as explained in the link on entry guards above, the attack you mention would work for any client connecting to a malicious server; e.g. it could work for a website if the user keeps the website open for a long enough time, and the website induces network activity via AJAX requests.)

      Edit: also, I don't see any reason why ingress/egress rules cannot be applied to Tor. You have a machine on your private network hosting the hidden service and a router on another machine acting as gateway and routing requests over Tor (we assume the router won't have software vulnerabilities). When the router gets a connection incoming from Tor to hidden service, it doesn't impose restriction, but if it sees connection from hidden service machine, then it drops the connection if it doesn't like the destination IP.

      In fact, most applications don't need any outgoing connections, so you could just permanently drop outgoing connections, and only deactivate this restriction when you need to download upgrades and such.

      Edit2: I didn't see you mentioned entry guards in your post :P. I'm not sure about it then.

      Edit3: for your RST attack, you would need to correctly guess:

      • 32-bit IP address
      • 32-bit sequence number 16-bit port number
      • entry guard IP

      That attack doesn't seem feasible to me, but I guess if you have enough time...

      I mean, attacks on a single connection when you know source/destination IP are already difficult to pull off.

      Edit4: even at 10M pps, it'd take thousands of years to finish. And if you increase the rate sufficiently to bring the expected time to deanonymize down enough, you'll end up taking many of the Tor relays offline.

      Specifically, if we restrict to 10M hosting IPs and 1000 candidate entry relays, with 10M pps that's 10Mx1000x2^16/10M seconds = ~2 years (and connection has to be stable during this time). But this is before we even consider the sequence number (if sequence number is outside some range, the RST is not processed; not sure how much this is used in practice though).

    • perennateperennate Member, Provider
      edited January 2016

      http://tor.stackexchange.com/questions/330/running-a-virtual-machine-vm-that-can-only-connect-through-tor has suggestions for hardening hidden service.

      • Tails: Linux distribution that routes all traffic through Tor
      • it also details example network setup for two machines where one acts as gateway

      Edit: I think https://trac.torproject.org/projects/tor/wiki/doc/SetupTorRelaywithKVM too

    • perennate said: Edit3: for your RST attack, you would need to correctly guess:

      • 32-bit IP address
      • 32-bit sequence number
      • entry guard IP

      I agree it wouldn't be trivial. But not all those need to be guessed to that precision. The entry guards being used are already known at that stage in the attack. Not all 32-bit IP addresses are used for hosting. And AFAIK the 32-bit sequence number does not need to be guessed at that precision, I think anything within the TCP window will successfully cut off the connection, but I'm not 100% sure on that, nor what window size one could safely assume for such an attack.

      perennate said: it could work for a website if the user keeps the website open for a long enough time, and the website induces network activity via AJAX requests

      Not really, because if the circuit does not happen to go through our controlled node, we will never see anything. It is necessary to provoke Tor to change circuits until the traffic happens to go through our controlled node, that would be part of what having a program on the client does. It sounds like Tor would accepts circuit changing by default see IsolateSOCKSAuth PreferSOCKSNoAuth in the man pages but I have not looked at the source code. Of course, these settings could be disabled, which would make things trickier.

      Thanked by 1perennate
    • @GM2015 said:
      I'm sure deadbeef would be glad to help you with Tor based on your past conversations.

      That was witty, I liked it :)

    Sign In or Register to comment.