Hello Mirimir, First, thank you for being such an amazing contributor to Wilders. I have learned so much from you. I have read through many of your forum posts from other topics and have a few questions about some of the things you've said. Thank you in advance. 1) I am considering further distancing myself. Is it possible to put your setup on a VPS or dedicated server? Meaning, install the pfSense routing on a headless VPS. I have read about using Remote Virtualbox to have a GUI - but I wonder have you done it? Or if you know if it is possible? Obviously, the btc I use to purchase the VPNs will be mixed thoroughly. To be clear, the setup: ISP -> VPN1 -> SSH to VPS -> VPN2 on VPS (through VPS pfSense) -> VPN3 on VPS (through VPS pfSense) I imagine anything you're able to do on a normal machine you're able to do on a headless VPS, no? 2) You mention that when you mix btc, you sometimes create Whonix VM pairs as "nodes" in between mixing. Then you delete them. From a technical and forensic standpoint, what is the harm in simply "cloning" a pair? Does re-importing them from scratch make them seem like separate machines? If so, how is it different from cloning? 3) I have heard that some exit nodes are preconfigured with SSLStrip to pilfer unwary TOR users who are sending bicoins. Does that threat still exist when we are using Multibit? Finally, as a small improvement suggestion for your already wonderful guides, I would recommend that you ask users to harden Firefox via turning off WebRTC and other phone-home programs. That part seemed to be missing and I found a WebRTC leak. Of course, this wouldn't happen if networking was separated via pfSense or hardened via iptables.
Another question: 4) Can you recommend any hosting servers that are privacy-minded in lieu of #1? Thank you!
De nada While it's possible, with some combinations of emulation and virtualization apps, to run VMs inside VMs, I wouldn't attempt that on commercial VPS. But you can easily run OpenVPN, Tor, a lean desktop and an X server on Linux VPS, and use an X client via SSH. You'll need a dedicated server if you want to run setups like mine with multiple pfSense VPN-client VMs, Whonix VMs and other workspace VMs. Also, with a dedicated server you can use dmcrypt-LUKS for FDE, and SSH to dropbear in initramfs for booting remotely. However, given that there's no assured physical security, FDE is no protection against resourceful adversaries. So with a remote server, you have much better anonymity and deniability, but much less data security. Yes, it's easy to setup remote display for VirtualBox, using RDP with TLS. I've used Remmina as an RDP client. It might even be possible to route that via SSH. Yes, of course That works fine using remote dedicated servers, but probably not with VPS. You could use multiple remote VPS, and route between them via SSH or OpenVPN. But there would be latency issues. On a remote headless dedicated server, yes. On a VPS, no. It probably doesn't matter, as long as you change network adapter MACs. But doing dist-upgrade separately might add some randomness. Yes, that is a risk. But I've never had problems. Also, I'm not sure whether Multibit or Electrum is the better light wallet. Full blockchain wallets are now impractical via Tor, given storage and network throughput for multiple instances. The huge network throughput would also attract unwanted scrutiny. Yes, I ought to mention that. But I'm not too worried, as long as I'm using nested VPN chains with pfSense VPN-gateway VMs. Everything done in a particular workspace VM can be interlinked and correlated, but it's still compartmentalized from stuff in other workspace VMs. Check out all providers listed in https://en.bitcoin.it/wiki/Trade#Security_Services and look for VPS and server hosting. For VPS, also check out https://bithost.io/ which is a Digital Ocean reseller.
Just my own two cents here: Why the jump straight to VPS's instead of local VM's? Seems expensive and unnecessarily complicated. For three hops, you can put a VPN on your router, your main OS, and the VM, without having to go through the complexities of dealing with pfSense (not hating but it's not super easy to set up). Unless you need the VPS' dedicated IP address to host a website or a service, I see little need for using one. Acquiring a VPS anonymously is non-trivial in most cases, and everything you do on it can be monitored. And SSHing to a VPS that is running a VPN may be problematic because you're introducing NAT's into the equation, of course there are workarounds but think about it. As for where to have a VPS hosted, it all depends on what you intend to do with it. Russia, Ukraine, etc. won't be super helpful if the US/EU authorities come knocking, and vice-versa. Iceland has decent privacy laws and cheap hosting but are friendly with the US/EU.
While I can't speak for OP, using remote servers or VPS does provide deniability, as long as they've been leased and accessed anonymously. Once I have a VPN account, I can setup a pfSense gateway VM in less than 30 minutes. Yes, you need to route via the "physical" NIC for your source IP. And with Tor, you can SSH to a hidden service. I'm not sure how cooperative Russia would be these days But as long as they don't know who you are, cooperation wouldn't be fatal.
Sure, but going back to Ulbricht's case, the "accessing anonymously" part is easier said than done. Hacked RDP's that make you look like an actual person not a VPS lessee are better, if that's what the OP is into I don't think using yourself as the example is very fair, you must know the process forwards and backwards since you wrote a guide. For somebody that's never done it before, like presumably the OP, it'd take quite a while. IMHO, for novices I'd stick with "keep it simple stupid," playing with stuff you don't understand 100% is begging for trouble, but whatever floats your boat. True, but to me this seems like additional work/complexity for little benefit. If the OP is a networking guru I don't think he'd be posting here... Yes, that's the entire idea
Ulbricht may be a decent coder, but his OPSEC was hopeless. Fair enough. But I did write the guides to be step-by-step. Playing with stuff that I don't understand is how I learn But I do agree that overreaching is begging for trouble. It's a hard call, sometimes.
I'd be very careful in dealing with Russian VPS providers if you come from a non Russian/CIS country. They will either steal your money or blackmail you. RBN (russian business network) died in 2008 and the owner is probably dead, likley killed by the FSB. So tread very carefully in dealing with Russian providers. If you want a provider that won't come down once the crap hits the fan you have three options. I'm not sure posting them is in the publics interest though You will never get a VPS provider to install Pfsense on a VPS. They won't do it. So you will be stuck with Debian, Ubuntu or CentOS. "IF" I was looking for a VPS provider I would look to providers like Voxility and getting one of their Romanian boxes with DDoS protection. Another good option is Elcatel in the Netherlands. They will host anything as long as you pay. And I mean anything. But no DDoS protection. There are more VPS providers that you should look into but you need to do your own research first. I hope this helped somewhat.
It looks like my best bet is to rent a dedicated server and NOT a VPS, especially because I want to have the pfSense setup I have now but remotely. Yes, I've seen the name Elcatel in so many places now when I run a whois. Thank you. Do you have any suggestions for a domain registrar? I am more concerned about hypothetical plausible deniability and being able to distribute trust further than what mirimir's current pfSense setup allows. So ideally, I'd like to find a dedicated server that respects privacy laws and is not known to cooperate much. I am not concerned about "accessing anonymously" for me as I have my entire pfSense setup and compartmentalized. I would never access my server from a coffeeshop with no VPNs/TOR in between I agree with mirimir. It now takes me less than 30 minutes to fully setup a pfSense and wireshark test it. The big part I am unfamiliar with is: 1) how to set this up remotely on a dedicated server. Mirimir, do you have any detailed guides or pointers that I can check out to do this? 2) which dedicated server to rent from that would sufficiently allow me to distribute trust (and preferably non-compliant) Thank you all for the help. So with the dedicated server setup running pfSense VMs, I would run into issues SSH'ing into the base server itself?
@krustytheclown2 I'm not sure what you mean by "hacked RDP" making me look like an actual person and not a VPS lessee. Can you elaborate? Thank you.
I haven't written a guide, as I recall. There are probably posts on Wilders about it. It's been a while since I did it, so I'd need to review notes first. You will need a server with IPMI, because you can't install dropbear (for remote LUKS unlocking) before the initial post-install boot. Ideally, you want IPMI that's accessible via private VPN, and which is disabled when no longer needed. That's hard to know for sure. But see the bitcoin.it list No, because the VPN clients are running in pfSense VMs NATed to the host NIC. But if you run a VPN on the host, you'll need a route exception from the VPN gateway.
Hmmm really? Well then I was wrong. I don't think many providers would install Pfsense for you. Guess I'm wrong.
Hmmm most of the so called bulletproof providers I have dealt with don't speak english let a lone offer support for anything but vanila linux distro's.
mirimir I have a question of my own. Could you "theoretically" use a tails ISO on a dedicated server and run a virtualbox vm of Whoinx hosting a TOR hidden service? Could you also acceses the virtualbox Whoinx vm hosting the TOR hidden service with SSH? I'm worried about running TOR over TOR but I'm curious to know if it's doable. Also have you had any experience with using Qubes with a VPS/Dedicated server? I was thinking of running Whoinx ontop of Qubes too on a VPS/Dedicated server.
You'd need Tails plus VirtualBox and the Whonix VMs. Maybe that could be done using a Tails USB with persistent storage. But if you're going to use Whonix VMs, why use Tails? If you want read-only, you could create a custom LiveCD with stripped-down Whonix using bootcd. But you only have 4.7GB on a DVD, and fitting three Debian systems would be nontrivial. I've managed to fit headless Debian host, a pfSense Tor-gateway VM and a stripped-down Whonix workstation VM with Openbox. But then you'd need a hosting provider who would use your DVD. And you'd need to periodically update the DVD. Sure. Tor over Tor is a bad idea. No, I've never tried that. That would resist attacks better, but the hosting provider still owns the box.
Yes it would resit attacks better I think too. I know the providers still owns the box and that is a big problem I haven't overcome yet. Some hosts like prq.se, elcaltel.info will host anything but they can and do get raided. I'm not sure how to tackle the problem
FDE is the best defense that I know. But a competent adversary will use portable UPS and power-patching tools, and take stuff back to their lab while still powered up. On the other hand, a competent hosting provider will pull the plug on everything during a raid When PRQ was raided a couple years ago, for example, everything went down. Physical hardening also helps: deadman case switches, removing all external ports except NIC, embedding boards in heat-conductive composites with tripwire grids and electromagnetic shielding, and so on. But that's expensive, and now you're talking colocation. Plus the challenge of anonymous shipping.
OK, here's a draft overview: Code: Preparation collect information about remote server IP, gateway, netmask, local DNS server(s) nature of IPMI, IP and instructions for accessing decide what you want to install Debian 8.1.0 x64 server and Ubuntu 14.04.2 x64 server are good choices generally, Ubuntu will have more recent versions of packages than Debian stable does and it may be hard to get bleeding edge packages to build or install on Debian stable however, what I have is instructions for Debian, so that's what I recommend Overview you'll be using a custom netinstaller built for the remote server you start by installing Debian 8.1.0 x64 server on a local box, your "build box" you want that local box to have an apparent IP in the same area as your remote server use your VM host as a nested-VPN-chain router add a second NIC create a pfSense "output" VM attach its WAN to LAN of appropriate pfSense VPN-gateway VM bridge its LAN to the second host NIC attach the build box to the output NIC get necessary packages and source files tweak config files for building netinstaller (amd64.cfg, d7preseed.cfg, local) make netinstaller files test IPMI connection scp netinstaller files to remote server connect to IPMI ssh user@remote.server.ip.address su tweak grub to boot netinstaller by default, and run update-grub reboot remote server at ssh prompt in IPMI remote console have "Continue installation remotely using SSH" screen hit "Start installer" ssh installer@remote.server.ip.address with network-console password complete installer, using dm-crypt/LUKS and LVM2, with separate /boot reboot after install in IPMI remote console type LUKS passphrase now setup dropbear for unlocking LUKS remotely without IPMI ssh user@remote.server.ip.address su check networking setup cat /etc/network/interfaces, run ifconfig and cat /etc/resolv.conf apt-get install dropbear busybox will generate dropbear_dss_host_key and dropbear_rsa_host_key tweak initramfs.conf and run update-initramfs -u cp /etc/initramfs-tools/root/.ssh/id_rsa /home/user/id_rsa_dropbear chown user:user /home/user/id_rsa_dropbear get id_rsa_dropbear, and put in local ~/.ssh ssh user@remote.server.ip.address su dropbearkey -y -f /etc/initramfs-tools/etc/dropbear/dropbear_rsa_host_key |grep -i fingerprint reboot unlock LUKS via dropbear ssh -o "UserKnownHostsFile=~/.ssh/known_hosts.initramfs" -i ~/.ssh/id_rsa_dropbear root@remote.server.ip.address echo -ne [LUKS-passphrase] >/lib/cryptsetup/passfifo exit test login to fully booted system ssh user@remote.server.ip.address su edit /etc/default/dropbear in SRV-20055 to disallow root login and password logins DROPBEAR_EXTRA_ARGS="-w -s" reboot unlock LUKS via dropbear ssh -o "UserKnownHostsFile=~/.ssh/known_hosts.initramfs" -i ~/.ssh/id_rsa_dropbear root@remote.server.ip.address echo -ne [LUKS-passphrase] >/lib/cryptsetup/passfifo exit scp local id_rsa.pub to user@remote.server.ip.address ssh user@remote.server.ip.address mkdir .ssh nano ~/.ssh/authorized_keys read ~/id_rsa.pub save and exit su nano /etc/ssh/sshd_config ... PermitRootLogin no ... PasswordAuthentication no save and exit service ssh restart without closing ssh connection, test ssh logins (so you're not locked out if something went wrong) ssh root@remote.server.ip.address => should see "Permission denied (publickey)." ssh user@remote.server.ip.address => should get in using local id_rsa passphrase
Well I may have come up with a solution. prq.se lets you send in Rasberry Pi's that they co-locate. Now only if you could run Qubes on a Rasberry Pi. Can you run Qubes on a Rasberry Pi mirimir? I would think you could because you can certanly run Debian on one. Now if you could fill the Rasberry Pi with a epoxy matirial so that it can not be taken apaprt otherwise it destroys the Rasberry Pi then we could be good to go. Forensics will more than likley not have procedures yet for a Rasberry Pi. They might have a portable UPS but I know people in forensics and they usually don't.
Very cool Thanks for sharing that Yes, you can run Raspbian and Raspuntu. But those are ported to ARM. I'm sure that Qubes could also be ported to ARM. But I doubt that even the Pi2 could handle it. There's just 1GB RAM. What interests me more is replacing VMs with Pi2s. Someone proposed that two years ago: http://theinvisiblethings.blogspot.com/2013/03/introducing-qubes-odyssey-framework.html Yes. I'm tending towards http://www.amazon.com/Arctic-Alumina-Thermal-Adhesive-5g/dp/B0009IQ1BU/ It's not that different. Well here's a small UPS[0] and this clamp-on plug[1] could be easily modified for patching. [0] http://www.amazon.com/APC-BE550G-Back-UPS-8-outlet-Uninterruptible/dp/B0019804U8/ [1] http://www.amazon.com/Leviton-Straight-Residential-Polarized-Non-Grounding/dp/B000FPAN84/
mirimir I'll take a look at that Quebes framework thanks For epoxy material I know Coollaborotry PRO would work. Problem is encasing the Rasberry Pi in it. I've seen Coollaborotry PRO destroy motherboards and laptops.