Written setup scripts for turning a raspi into an hidden server. Comments needed.

Development
1

Hi,

I’m posting this in the developers section, because it’s meant to be read by developers, rather than the wider public, because the project I’m going to talk about, is in a too early stage to be interesting for most users.

I’ve written some ansible scripts meant to enable people to setup a raspberry pi as a very cheap server for hosting hidden services without too much hassle. What I have made so far, sets up a set of LXC containers, of which one acts as a proxy to the tor network, another acts as a proxy for everything regarding APT, and an arbitrary number of containers are acting as containers for hosting hidden services.

Within those containers, applications don’t know the IP of the host, and don’t have any access to the internet, but can be reached from the tor proxy, so they can host hidden services, as well use the APT tools normally, thanks to the APT proxy.

In short, this setup is meant to eliminate the risk, that an attacker can learn the IP of an hidden service due to an configuration error (like enabling modinfo.php), or manipulate a software in a way, that those software contacts something like fbi.gov from its real IP. Additionally the playbooks take measures to harden the host in many ways, but that part is not completely done yet.

I’m posting this, because I want to make you aware of my project, so that those of you, who are interested, can test my project, steal the parts, that are good, and tell me, which parts are bad or could be improved.

Finally, the link to my little project is: http://studygarden2nrpb.onion

P.S.
Please use my own forum to answer.

1 Like
2

interesting project. There have been requests over the years for low power ARM devices running Whonix but we don’t have the resources. Thanks for sharing your efforts. I would like to see your work become an official port under the Whonix umbrella so I will discuss a few important points.

How feasible is it to transform your scripts to use KVM? AFAIK RPi is capable of running VMs. We believe that the only type of isolation that is worth supporting is hypervisors because the attack surface is way too great for containers.

How easy is it to integrate our build scripts and repos into your build system? Are you interested in doing this?

PS. Please keep Law Enforcement out of your examples. Our software’s goal is not to circumvent civil or criminal law or aid criminals but protecting basic human rights like privacy from infringement carried out illegally - no matter what entity does it.

3

Hi,

the answer depends. I’m trying to answer in a comprehensive fashion:

In my opinion, raspis are well suited as small servers, running a minimal system and just a few applications. That’s what I’ve tried to achieve. Especially when utilizing ramdisks and so on, they’re performing okay. But they’re lacking, if more processing power is required, than a smartphone or a 15 year old computer would provide. Therefore, I’d suspect, that several operating systems running inside VMs could be too demanding on the hardware. But I honestly don’t know, and I’ll try it out, as soon as that’s possible.

Another thing regarding raspis is, that until a few days ago, they haven’t been supported by the linux kernel. Every release meant to be run on a raspi used a heavily patched kernel, which often never was updated. Therefore, the base OS on which my script builds, is raspbian, which sucks security-wise, and probably won’t run KVMs, but is easy and available. The overall situation regarding Banana Pis, and so on, is even worse. At least as far as I know.

However: A few days ago a new kernel release came out, which is said to run natively and without any patches on raspis. I haven’t tried it yet, but as soon as there’s some kind of installer, I’d change the script in a way, that it expects a normal debian system. I think, that this is very interesting, because at this point, the script would support little RasPis as well as big hosted servers, as long as both are running a debian OS. Raspbian basically is debian with different repositories, a few hacks, and a patched kernel, so this wouldn’t be too much effort.

As soon as this is the case, KVM would be supported, if it runs on ARM at all. It might be too much to run several OSes on such a little device, and I’d have to find something useable that runs inside the containers, but it would be supported. So my script could be made to support LXC and KVM at the same time.

This should give you an overview of what’s planned, as well as an idea in what sense I could make use of your repositories. Regarding your build system, I don’t have a clue, as I haven’t seen it yet. Do you have a link and maybe some kind of documentation?

If you’d be interested in something along those lines, then I’d like to be part of your project. If that would be the case, we should talk about a few details. Like, what to expect, and how to go on.

P.S.
Sorry about the example with fbi.gov. I don’t support anything illegal, but I tried to make sure, that everyone understands the attack vectors I’ve been talking about. Maybe I’m spoiled by too much talk about the prisoners dilemma :wink:

2 Likes
4

I don’t want to rush anyone, but shouldn’t there be some kind of further reply?

1 Like
5

How about you try parts of your setup or all of it on the Whonix gateway or workstation and see how it goes? Or try if building Whonix on debian arm* or raspbian succeeds. If both does work merge it and test again. Maybe do some benchmarking since rpi’s are not that fast, combined with virtualization it could be worse.
Documentation for building from source is on the wiki.

2 Likes
6

Here is the link to our main build scripts and sources:

https://github.com/Whonix/Whonix

Yes we are very much interested and have been looking for help on this for some time now. Please stick around and excuse the slow communication. We’ve been a bit busy this past week. For more details on the ins and outs of the build system @Patrick should be able to help since he knows the most about it.

I think the best way forward is to see how to modify our build scripts to pull from Debian ARM sources and bootstrap the build process on an x86 machine. For faster code review, please upload to gitlab or similar because your onion site is not always reachable.

1 Like
7

Don’t bother with Whonix 13. Go straight to Whonix 14.

https://www.whonix.org/wiki/Dev/Build_Documentation/14_full

The build script is very flexible. Whonix doesn’t have any platform specific code. So it could be really simple. Something like this might do.

sudo ./whonix_build --target raw --flavor whonix-gateway --build --arch arm64 --kernel linux-image-arm64 --headers linux-headers-arm64

sudo ./whonix_build --target virtualbox --flavor whonix-gateway --build --arch arm64 --kernel linux-image-arm64 --headers linux-headers-arm64

sudo ./whonix_build --target qcow2 --flavor whonix-gateway --build --arch arm64 --kernel linux-image-arm64 --headers linux-headers-arm64

Feel free to try and let me know.

8

Rather than running high-resource virtualization on RPis, have you considered building an array of RPis to split the workload and isolate each task, not only in software, in hardware? Each RPi could be a discrete node in a USB communication tree/chain (or for even more security through obscurity, the i/o pins!) with the final network connection exposed on only the first one.

9

Frankly sounds like a terrible idea because USB is a very infamous infection vector.

We do support physical builds but VMs aare a better guarantee for ensuring no cross infection of underlying hadware happens. While the RPi can serve as a cheap disposable computer replacing the peripherals attached to it like the screen/mouse/keyboard because they were connected to an unrusted machine, would quickly become an expensive ordeal.

10

Sounds a bit like: Qubes Air: Generalizing the Qubes Architecture | Qubes OS
Under “Qubes on “air-gapped” devices”. It is certainly doable the question is who would use it and if it is feasible for the average end user. I’m also still wondering if it easier to break out of the VM or just exploit the next hop on the network.

How should this look in practice?

The question is if and how you could protect the hardware? It won’t matter if malware can’t flash the firmware on those devices but ideally the enduser can. This sort of implies some write protection switch for the firmware. I’m not sure if in each case it would be possible for malware to flash the firmware. In some case you might still need physical access, so maybe you could get along without real hardware write protection. In this case you could randomize serial numbers, maybe change the model …
So you could save some money. It would be even better of course if you could do this for the RPI or similar device, too. Then still a lot of people would need to use such kind of setup in order to hide in the crowd. And some more advanced fingerprinting methods beyond mere serials numbers etc. might still apply.

Other general nitpicks:
The rpi 3 is sadly one of the few arm64 boards with no aes support. It might not matter however for using tor if it still can handle the average download speed and not bottleneck the connection. It also has integrated wifi which makes it a bit less suitable as some kind of workstation. Virtualbox is not available for arm, so only KVM or Xen would be an option. Torbrowser is not officially available for arm64 though it seems to be possible to build it yourself. Hopyfully this will change sooner or later when arm64 devices become more widespread.

1 Like