I’ll try now to understand what’s involved in having multiple instances running on the same node, but I guess there’s the need for a radical different approach (i.e. not following https://www.torproject.org/docs/debian.html.en#ubuntu as I did for building the module in the first place)

see https://www.torservers.net/wiki/setup/server#multiple_tor_processes

for a start.

Did you take a look at the existing projects?

https://github.com/search?q=tor+puppet

Maybe you should merge your project with one of the existing ones?

Is anyone at torservers & partners or anyone else using puppet to manage multiple relays and could share their experience?

https://www.torservers.net/partners.html

On 15. Juni 2014 at 15:56:29, Philipp Borgers (borgers@mi.fu-berlin.de) wrote:

Did you take a look at the existing projects?

https://github.com/search?q=tor+puppet

Maybe you should merge your project with one of the existing ones?

Yeah, but it’s usually easier said then done. I had a look on the forge to see if there was something suitable, but couldn’t find. As for GitHub, there are 3 pages of them. I can spend some time to go through them and see if there’s one fitting my use case, then get in touch with the developer and see if it’s interested in collaboration, but usually it’s much much faster for me to write my own, test it locally, and ship it to my puppet master.

As I already said, this was meant to be an easy way for me to start with Tor on a server I had, I didn’t think about making it suitable for public usage at that time. Anyway, I’ll try to follow the advise and see if there’s some other module I could merge into, but it will take some time.

Some things I would do/change:

• add a license ohterwise we can't contribute

True that. I’ll go for the same Tor is using, I guess GPL

• colorize the examples in the readme (```puppet)

Right

• add a modulefile so people can use librarian-puppet etc.

Right. Also, puppetlabs/apt module is actually already a dependency (only if you set a certain parameter when declaring the class though)

• add tests

Also can be done. I’m still not 100% convinced by the whole TDD idea for Puppet manifests, but I understand it will make it easier to adopt, so no big deal to add them.

@all, thanks for your feedback, very appreciated.

-- Alexander Fortin http://about.me/alexanderfortin

On Mon, Jun 16, 2014 at 4:40 AM, Moritz Bartl moritz@torservers.net wrote:

Thank you for this. I've come across several Puppet and Ansible recipes for Tor over time, but sadly have not found time to properly review or even use them for our own servers yet.

Thank you for the feedback. I'm new in the Tor land but I think a well crafted CM module could definitely help the adoption, so I'm happy to see there's some discussion here.

https://github.com/shaftoe/puppet-tor/blob/fixes/manifests/apt.pp key => '886DDD89'

You should never rely on short key IDs for anything. They can be forged within minutes. When you look at https://www.torproject.org/docs/debian.html.en , it fetches the key using the short key ID, but only imports a key that matches the whole fingerprint.

Ok

I found keys.gnupg.net to be unreliable sometimes, it would be good to have some fallback options.

Maybe add this fallback options to https://www.torproject.org/docs/debian.html.en too?

Tor generates key material, the default location is /var/lib/tor. I always wondered if it was possible to pregenerate the necessary files locally, and then push them to the relays, where /var/lib/tor is on a ramdisk.

I've been told on #tor that the secret_id key is more to be thought as a 'state' more then as a configuration, and if a Tor relay has to be moved on a different server, it's best practice to just start a new one from fresh. Or better said, there's no actual need of keeping a fingerprint consistent.

Personally, I think it would be great to not only have puppet modules spread out somewhere across the Internet, but a full-fledged guide/wizard that makes it easy for people to locally configure relays without knowing anything about Tor configuration options. In my dream world, it would not only support Debian: Right now, most of the Tor network runs on Debian, which is not ideal. We need more *BSD and Solaris! And FreeDOS! :)

Yeah, I share the dream too :) It should be as easy as

include 'tor'

to install a relay with the most common configurations default (in my case, a non exit relay), regardless of the platform.

On Sunday, June 15, 2014, Moritz Bartl moritz@torservers.net wrote:

Personally, I think it would be great to not only have puppet modules spread out somewhere across the Internet, but a full-fledged guide/wizard that makes it easy for people to locally configure relays without knowing anything about Tor configuration options.

+1; this would be great for Tor Cloud users.

In my dream world, it would not only support Debian: Right now, most of the Tor network runs on Debian, which is not ideal. We need more *BSD and Solaris! And FreeDOS! :)

Why is this not ideal? I'm not following. Also, do you mean Debian or Debian-like? If the latter, Tor Cloud (Ubuntu) probably accounts for a fair bit of that inbalance.

On 17. Juni 2014 at 23:56:43, Zack Weinberg (zackw@cmu.edu) wrote:

Why do you disable directory mirroring? It's my understanding that this should basically always be on.

Not sure why, I think at the beginning I wanted to use the ‘minimal’ config, and I didn’t even now about directory services, but please keep in mind I’m still missing the big Tor picture and many things are new to me That’s actually one of the reasons for this thread: if you think such and such configuration should be defaulted, or available as a custom parameter, well, please say so :)

It would be nice if exit-relay mode enabled an HTTP "exit notice" as described at https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment.

Point 4 says: "If you run your DirPort on port 80”. Should it be enabled only when DirPort = 80?

Tor relays get pounded on by the script kiddies -- a degree of hardening is appropriate. I don't know if there are any stock Puppet "tighten security" modules but these are the things that I remember having done to mine. Note that my relays serve no other traffic and have no non-root user accounts; some of these configuration choices may be inappropriate for multi-use machines.

I don’t know of any such ‘security silver bullet module’ I am afraid :)

About the security enhancements, they are definitely interesting, but to me seems they are out of the scope of the ‘install relay’ Puppet module itself, and also against the usual modular approach of Puppet modules. First, my understanding is that having a node with only Tor running is suggested, but not mandatory, but in any case, those enhancements are more suitable for a separate 'tor-security’ like module that one may or may not be interested in.

-- Alexander Fortin http://about.me/alexanderfortin

On 18. Juni 2014 at 16:26:38, Zack Weinberg (zackw@cmu.edu) wrote:

Best practice as I understand it is that you should have an exit notice on all exit relays. What I'm not sure of is whether "DirPort 80 + DirPortFrontPage" is the recommended way to accomplish that. The CMU Tor exit uses a separate lighttpd install, I think primarily because we didn't know about DirPortFrontPage when we set it up. I can make a case either way - less software = less attack surface; separate install = compartmentalization.

I understand the 'less software’ benefit; I’m currently reading https://en.wikipedia.org/wiki/Compartmentalization_(information_security) but still not sure if I understand correctly the reference to the ‘compartmentalization' in this case.

As long as we're talking about exits, a nice touch would be to include the reduced exit policy as an option ( https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy ); the ideal would be a three-way choice of not an exit / wide-open exit / reduced exit (no email or BitTorrent) plus a place to add local exit rules.

Yes, makes sense, and should not be too complex to implement, I’ll try to add this and get back here for some review. Thanks for the feedback

-- Alexander Fortin http://about.me/alexanderfortin

On Wed, Jun 18, 2014 at 1:49 PM, Alexander Fortin alexander.fortin@gmail.com wrote:

On 18. Juni 2014 at 16:26:38, Zack Weinberg (zackw@cmu.edu) wrote:

...

Best practice as I understand it is that you should have an exit notice on all exit relays. What I'm not sure of is whether "DirPort 80 + DirPortFrontPage" is the recommended way to accomplish that. The CMU Tor exit uses a separate lighttpd install, I think primarily because we didn't know about DirPortFrontPage when we set it up. I can make a case either way - less software = less attack surface; separate install = compartmentalization.

I understand the 'less software’ benefit; I’m currently reading https://en.wikipedia.org/wiki/Compartmentalization_(information_security) but still not sure if I understand correctly the reference to the ‘compartmentalization' in this case.

If the process listening on port 80 is the Tor process, then any vulnerability in the HTTP service it presents to port 80 can be exploited for a direct attack on the relay itself. If port 80 service is provided by a separate program (e.g. lighttpd) running under a different user ID, then an exploit of *that* program may not be able to affect the relay. That's all I meant. (The Wikipedia article is talking about a related thing, but not really the same.)

If you turn DirPort on at all, that exposes Tor's built-in HTTP server to the Internet -- perhaps on a nonstandard port, but still -- so I'm not sure the compartmentalization is really buying anything in this case.

zw

On 17. Juni 2014 at 23:56:43, Zack Weinberg (zackw@cmu.edu) wrote:

Tor relays get pounded on by the script kiddies -- a degree of hardening is appropriate

I was thinking a little more about this point, and I’m wondering how running a Tor relay is increasing the likeliness of being hit by script kiddies attacks. I mean, usually I just consider *any* server with a public IP already open to such kind of attacks.

-- Alexander Fortin http://about.me/alexanderfortin