Ideal Tor Server & ExitNode?

[Chris Palmer]

lkjklj lkjlkj writes:

> 1. That more traffic on a givin node (to a point) increases the
> anonymity of the Tor node? 

I'm not sure what you mean. The Tor server is not in any sense 
anonymous.

It is true that the more traffic and the more types of traffic there are
on the network, the better protected all Tor users are. Whether that has
any meaning vis-a-vis a single particular node, I don't know.

> 2. The closer a node is to it's bandwith limit the more traffic
> analysis data via. meta-data is avaible to an advasary? 

I don't think directly, but CPU utilization on a Tor server is largely a
function of the amount of bandwidth the server passes. There are
indications that traffic analysis may be easier (the timing of packets
is more predictable) when a server's CPU is heavily loaded.

So get more CPU power than you think you need. :)

> If I understand the issues of Tor correctly, having dedicated nodes
> with high bandwith will increase the anonymity/security of the
> network.

At the very least, open exit policies on high-capacity machines make the 
network more usable, and usability enables us to have more users, which 
results in more and more varied traffic, which increases anonymity.

> 1. How much bandwith? 

I don't think we're at the point yet where we want to set limits. There 
is the potential that a high-capacity node might get more traffic, and 
thus if that node is compromised (from the point of view of a particular 
user), then it's a greater risk than it would otherwise be. But we're 
still in experimental mode, and capacity and debugging opportunities are 
welcomed.

> 2. What kind of Exit Policy? (I was concidering a soft exit policy)

The default exit policy is good.

> 3. Should the Pageing file be encrypted or disabled (with enough RAM
> of course)?

You should encrypt or disable swap for all sorts of reasons, besides 
just Tor. So, yes.

> 4. If logs are required how long should they be?

Logs are used for tracking bugs and ensuring correct operation. I think 
you can set a relatively short window for your logs, like maybe a week 
or less. Also, log at the default level, increasing verbosity only if 
you are actually investigating a problem. Decreasing log verbosity might 
be a good idea, but since Tor is still experimental, it might help most 
at this time to stick to the default verbosity level.

> 5. What country would be ideal in regards to server anonymity and
> regualtions [logging, etc]?

No idea.

> 6. Required operations for security/anonymity of server? (Encryption
> of various files/logs/etc)

Host integrity is critical, and you can best ensure that by using a safe
OS (let me know if you find one...) with minimal services enabled. 
Ideally, you'd run nothing but Tor, but realistically you'll probably
also want SSH for administration. But be sure to configure SSH in as
paranoid a manner as is possible for you (allow connections from certain
IPs, allow only certain users, disallow remote root logins, don't use
sudo or use a VERY careful sudo configuration, and so on).

Tor itself should not generate or keep any sensitive information in
non-volatile storage. Not having any non-volatile storage at all is
obviously great if you can do it (e.g. boot from a CDROM that launches
Tor, have no hard drive).

It would be great to have a machine with no writable non-volatile
storage, which runs only Tor and not SSH. Rebooting in case of trouble
would be acheived by one of those remotely-controllable power strips
and/or by physical access. There is the question of logging. Maybe a 
loghost, which the Tor server connects to by tunnelling syslog over UDP 
over TCP over TLS...


-- 
http://www.eff.org/about/staff/#chris_palmer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20050413/ab6a6b94/attachment.pgp>