The best way to run a hidden service: one or two computers?

[hikki at Safe-mail.net]

Well--I'm still convinced that running two physical computers is the best 
way to run a critical hidden service (instead of one computer optionally 
with a VM).

Like this: Linux Web Server -> Linux Tor Gateway -> DSL Router ->
No wireless equipment, just LAN cables between them.

The so far arguments against this setup, for rather using a VM on one 
single computer, are these (might be more, and I'm willing to learn!):

#1 An attacker with root access gained can read off hardware serial 
numbers on the Linux Web Server, like using tools as dmidecode. With that 
knowledge, those serial numbers can be linked to a certain purchase of 
those components, like having used a VISA card on a web shop. That also 
goes for the MAC address of the NIC.

#2 Direct attack on the NIC on the Linux Tor Gateway box. As Robert 
Ransom wrote:

> Yes.  I read a report years ago that at least one model of Ethernet
> card had a remote âfirmware upgradeâ âfeatureâ built in, with
> absolutely no authentication of the new firmware blob.  The card
> firmware had access to the host's DMA hardware, which can be used to
> root the host.

----

So here are my arguments against those:

#1 I've been able to find a brand new motherboard that doesn't leak any 
serial numbers of any components attached to it. I had to buy a few to 
find that one, but they do exist and it was worth it! When I run tools 
like dmidecode on that motherboard, the serial number lines for all the 
components are either blank, has just 'OEM' written or '123456789'. 
No serial numbers are shown. Neither any MAC addresses when running 
dmidecode. Though MAC-s are easilly read off by running 'ifconfig', even 
as an unprivileged user.

But it does show the model of the motherboard, and the models of some of 
its components, so having a brand new one might narrow down the buyers 
some. But still it would be hard to find ONE buyer world wide without one 
single serial number.

By using some older components from here and there--the secondhand marked 
is drowning in decent computer parts for give-away-prices--that 
additionally doesn't leak serial numbers during DMI decoding, should be 
very very very safe IMO.

The MAC address can be temporary spoofed, and it's very easy to do on a 
Linux system. Just one simple command in the Terminal, and 
'sudo ifconfig -a' shows your spoofed MAC until you reboot, not the real 
one. You'll just have to remember to change it after a reboot!

#2 Regarding attacks on LAN devices, you can just buy a really simple 
one, without any firmware upgrade features at all, just a cheap and 
simple LAN card with a ROM chip, that just works. Nothing spicy or fancy.
The simpler, the better, right? :)

And I think it will generally be harder to crack hardware than cracking 
software, if we look at VMs in compare.

----

My point is that a VM is a software guest computer inside a host OS. 
Firewalling the VM with apparmor or selinux might help a lot. But braking 
out if a hard box seems way more difficult, and cracking a hardware LAN 
interface just by sending packets to it. And the server box will be 
totally isolated from the Internet anyway--it will only listen on the 
webserver ports, and only allow outgoing traffic that matching the 
incoming webserver requests.

----

But all this is only relevant if the attacker gains root access on the 
server. So I guess running a hardened simple Linux OS on the server, 
without a GUI, like OpenBSD or something, would make it extremely hard to 
contact and gain root on the gateway box--while I think it's a lot easier 
gaining root on a host machine that runs a guest OS inside a VM, because 
they're both on the same box.

I'm just thinking loudly here, I'm not pretending to be a wise guy nor 
a specialist. I appreciate to be proven wrong and learn something new! :)

-Hikki
***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/