- tor-relays - lists.torproject.org

"Very Safe" Exit Policy
by Stephen R Guglielmo 18 Feb '15

18 Feb '15

Hi list, I was looking for suggestions/discussion on very conservative policies for an exit relay. I run a relay now that is "reject *:*" and I wanted to open up a few exit ports. I don't want to open up major ports due to potential abuse issues. My server host states that, although they do allow Tor, there is a chance of the relay being terminated at their will [1]. I was considering using a whitelist exit policy and opening up only the following ports to be "safe": 43 - WHOIS protocol 53 - DNS 389 - LDAP 464,543,544,749 - Kerberos 531 - AOL IM 636 - LDAP over SSL 706 - SLIC 873 - rsync 5190 - ICQ and AOL Instant Messenger 5222,5223,5269,5280,5281,5298 - XMPP 5353 - Multicast DNS 5999 - CVSup 8332,8333 - Bitcoin 9091 -Transmission (BitTorrent client) Web Interface 11371 - OpenPGP key server 64738 - Mumble/Murmur I constructed the list based on a quick skimming of the WP ports list [2]. I suspect allowing IRC would eventually be grounds for my host to terminate my relay. This would be my first time running an exit relay and I'd be happy to hear advice and suggestions! Thanks, Steve [1] https://trac.torproject.org/projects/tor/wiki/doc/ISPCorrespondence#OVH [2] https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

9 11

new ansible-tor features: automatic instance configuration + automatic MyFamily generation (PATCH)
by Nusenu 18 Feb '15

18 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi David, thanks for creating ansible-tor. I added two features that are crucial to me and maybe useful for others as well. If you like it, feel free to merge - this is my first ansible experience and it is lightly tested. Example: lets say you have added a new server to your inventory. The server has 3 public IP addresses (1.1.1.1, 2.2.2.2, 3.3.3.3). After running ansible-tor with the new changes you will have the following 6 tor instances/ORPorts running (without manually specifying IP addresses first): 1.1.1.1:80 1.1.1.1:443 2.2.2.2:80 2.2.2.2:443 3.3.3.3:80 3.3.3.3:443 including MyFamily configuration across all servers/instances. regards, Nusenu changes ======= - - auto instance deployment without manual IP/ORPort configuration (new) starts 2 tor instances per available IP address by default makes manually specifying IP addresses and ORPorts via proc_instances obsolete ORPorts default to 80 and 443 (DirPort not added yet) replace "single.yml" + "instances.yml" -> instance.yml only (handles both cases dynamically) - - MyFamily autogeneration (new) Keeping all relay fingerprints in sync is probably one of the most annoying tasks for a relay operator managing multiple relays, now ansible takes care of this (all relays need to be in the 'relays' group) - - directory structure (changed) defaults: configs -> /etc/tor/<ip>_<orport>.torrc log dir -> /var/log/tor/<ip>_<orport>.log datadir -> /var/lib/tor/<ip>_<orport>/ pid dir -> /var/run/tor/<ip>_<orport>.pid (previously everything was located in /etc) - - added torrc sanity check (tor --verify-config ) (new) - - torrc files are owned by root (previously owned by $tor_user) - - the pid file check has been removed since the file is not required to exist (it will be created when tor starts) open - ----- - - it does not take care of instance removals yet (in case IPs are no longer available or amount of ORPorts have been reduced) - - allow opt-out -> only 1 tor instance per host (even if there are more IPs available) - - DirPort support - - detect RFC1918 IPs (opt-in) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJU4i+CAAoJEFv7XvVCELh0y+kP/i4Mn/XClgXYloGdgWU9UPR+ Y8yZv97FvJOMPI40tccPKcNPcLQFRvGFYkR96sAOGoMfbJT/tQeH2dOxwAEF31mv afFkLsVPAOpNzlyO2qP1mkLtB/aYXtZ6jb2+JtpAhVBLKOVFBN2nNRiwdgFYZFGy f0ZIp7xyR9XcAhXo4nc0hlETREAnbMOgFGM6vqqIpJfimF3liE6va5HNw2CD+7Zd MmeIOuVNvQh09SiYf48AJpBeBRoybOvmFIPphtXEYlC/y6cd/IyUIYdOBuaLa5td vQnrQOC7TUgp74uarl0yaatOYOEagl0lrNeN6+Vgy5e0e12TgVccWW5ZosM1PBXG VH2FTfjHXUO+VN0p4xn6AS0dhWTRKb7isj3jpznTMsiq0AcvXM6DZjkzkcCPChVz jptdUbNvgpdP7j5X11iZniGpxVe7aFo2wCzgZORY1xMysiigJsL4M/nonr4YO4G9 w7kyNcco9gStklJSvOJXbfX4HrOCuWdq8hp4xubyON+5jpEUgMmG1o/v5NJANV4C CLzlz4kf9l9o351Z7DJQzilxzDEwe6oZwSWnsq+yB65Mgj5sUJnchi40iPLOHSUr DaVSSUxoZ8VVNYqqvGYb2fysYa7DsCgofsF/eXP4QyJp1WFNwc0ft6qIhyAGIDwx RfwQHrA+Lg95mdXDyr0B =QHkD -----END PGP SIGNATURE-----

4 15

Re: [tor-relays] new ansible-tor features: automatic instance configuration + automatic MyFamily generation (PATCH)
by Raynardine 17 Feb '15

17 Feb '15

On 02/17/2015 04:01 PM, Moritz Bartl wrote: > My algorithm. Hm. This all sucks because Tor still doesn't scale across > multiple cores. There should be more affordable dedicated host service providers that provide professionally overclocked servers. Liquid nitrogen isn't that expensive to generate, if you use solar power to make the electricity required more affordable. It seems dedicated servers are becoming less and less common as virtual private servers attract cheap customers. For things like Tor that are dumb and can only bind to a single core, overclocking and overvolting that one core professionally could be a practical business venture. Unfortunately, due to the nature of mixnets like Tor, unless a large number of equivalent service providers do it, the benefit provided is minimal at best. The Tor relay pool is strongest when the hosting providers are as diverse as possible. If 51% of Tor relays are hosted by the same company and in the same country, Tor may as well not exist.

1 0

Re: [tor-relays] Mozilla-Middles losing guard
by Raynardine 17 Feb '15

17 Feb '15

On 02/17/2015 02:59 PM, lpwzi9i84(a)use.startmail.com wrote: > ...but what we want are nonmalicious guards, right? If you want non-malicious guards, you may consider manually configuring bridge relays. Manually verifying and authenticating the identity of bridge relay operators is probably the only sure way to get non-malicious guard relays.

1 0

Re: [tor-relays] Mozilla-Middles losing guard
by lpwzi9i84＠use.startmail.com 17 Feb '15

17 Feb '15

at this very moment all of them got the flag, right. But theyre loosing it at seemingly random order. I kept an eye on Atlas for some time, at 18:00 (UTC+1) Mozilla13 was at 1.51 MB/s without Guardflag. On Tue, February 17, 2015 19:50, Nusenu <nusenu(a)openmailbox.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > >> i am wondering about losing of guard state of the Mozilla Middle >> Relays. > what makes you think they [1] lost guard flag? > > [1] https://atlas.torproject.org/#search/mozilla > https://consensus-health.torproject.org/consensus-health.html > > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJU442PAAoJEFv7XvVCELh0FbUP/27q3GoeFaqEEjRrd88w3S5C > PGhX0yPe/0zZzTCWwBR8GR44qm6XyO6rQloGVFJAbcUfPjZEvYSED3CVDfgiuoIb > t9mg4nH5W6ZMMGQJhT+wmKZTFOIK68nZpfmtlsrAfstbQ4NMj4QHOb1mDos+XnE5 > DPYvjmfiarVbghM5KsB6w8s26bqT/By5coxEdGOlHLv5E8iqUpCUYWP45FAcY7uE > MGp7smOheykVF7MsNHG8uhWaEp63jSKS0hgqAXYQJfyAheo5y+zuoA6rL+7J7CqK > 9VRRg33qmCnuT4uRrk51Ggdbl9yS2qtJEnPVzxGJc8433wKHut6PlNz0SnusLuDN > Hal0ndXp0ZjQrAysBvMGJ7pcR/7+pw3kmLSyXfszMZVh4gkkWjDXdfQa3kTORdJ2 > XrIs/E+IqhwEGt1Sj+CcQBLiVJ0Wp3HMFl94rVH0qB2UhracoJ+tCfEvmKW8fZWf > lKpAZYGUgROgI1NHyyaFnhxvCPxma/bLjqjShaDJNR5Dak8DFHqzHnP78Y4w9hZm > 5Kk54Tg+jqjWapnwHQwgIj+mk8KiacqMirjHm5gBGRa34E8TZmoyZgINE+yRH4cj > ogvopd2DJerDwOaYb66ed1r1gsg78eDfBPE27kwAzfsY3ur/G6JDCTv3vSsyoO5r > XABeYlaQuf760OikXwXV > =aJUd > -----END PGP SIGNATURE----- > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

4 5

Mozilla-Middles losing guard
by lpwzi9i84＠use.startmail.com 17 Feb '15

17 Feb '15

Hi, i am wondering about losing of guard state of the Mozilla Middle Relays. Is it cause of 1 physical machine handles 6 IP's, 2 Relays each? Maybe the total bandwidth should shared by 4 IP's, 2 Relays each to increase the chance to keep a bandwidth throughput beyond 2 MB/s. Guardstate will be rejected by falling below 2MB/s, right? Just wondering if the Mozilla setup could be more smoothed... cheers (this emailadress will expire automatically after 2 weeks)

2 1

Tor weather - signature not found
by mattia 16 Feb '15

16 Feb '15

Hi all, I have recently converted a bridge to a relay. Its fingerprint is 0D14A4498E7D1854696CC07548653EA4CD3CB2DA. I wanted to subscribe to Tor Weather but when I try I get the "We could not locate a Tor node with that fingerprint." error. Searching the web I found it was a common error years ago, but shouldn't be now. Any ideas about it? Thanks!

5 6

tor weather not sending emails?
by Nusenu 16 Feb '15

16 Feb '15

Hi, I subscribed to tor weather to get notifications in case something is wrong with a relay. Although the relay had several downtimes (>1 day), I never got an email. (I subscribed to with the minimal setting 1 hour) Did anyone get emails from tor weather in the past 2-3 weeks during downtimes? thanks!

5 8

Value of an unused bridge?
by Elliott Jin 14 Feb '15

14 Feb '15

Hi all, I've had an EC2 bridge <https://globe.torproject.org/#/bridge/FD0814BDD15B2E591B04868B988D87FC6D331…> up for 2 weeks, and it seems to have gotten no usage. I'm considering converting it into a middle relay instead, but before I do so, I'm just wondering: - Is there value in having a marginal unused bridge "in reserve"? - Is this value greater than that of an active middle relay? Thanks! -Elliott -- Anonymous Feedback <http://www.admonymous.com/eyjin>

4 4

Thoughts on new relay
by Niklas Femerstrand 11 Feb '15

11 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Moin, Our relay is online as of Jan 23 and recently I've been thinking about pivoting it into a bridge instead. The relay lives in Cambodia and may naturally be a bit off from the rest of the network (latency). Consensus weight is steadily increasing despite various initial downtime incidents, which you can see in Atlas graphs. (We've had some network upgrades and during a separate event even had a monkey yanking the eth from the nic.) Currently we advertise 435.66 KB/s and with our current ~9d 10h uptime we have downloaded 3.6 GB resp uploaded 3.7 GB. Theoretically our tubes fit 10 Mbps download and 30 Mbps upload. The question is whether the relay is worth keeping with its current setup or if we can contribute more by re-configuring into a bridge. Unfortunately it is very risky for us to allow exit traffic, but we <3 any cipher packet. Please advice! https://atlas.torproject.org/#details/94F806110B23E727AE8BAD74DD95B0EE0B7A8… Regards, King Kong -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU2gGzAAoJEHxAR3sGx+rLTzEP/05TJK3vzfPe3kUjUfg0G/wm vlc1vZLshAvK/pE1mf2DqDSgnuxR+QHHJI8htJOaU5VJVMlnEy4nsF0uE76It1EW OLUo7+LU452Sx7XjyVYMKOu6OJ9kD1Cg6OkNT2HEIOR+57x7vNJTYr7oF0uNu6dt UzVFJKkM3Y1ca4GsMS2M/oXFw2jGrrvmx4DLHu2OSDwNumy3ndOETnZscVfErAMK A/K4JI0Ws6pInBRciEHdak9ZBkR/f9jYGPbUXOSwnJN6XIsawijTIbrRLfYiUcro 0wj6mZYqXgKRDOvP57UNkf5UaolADQb6ssiLkhhAGu+DHnTt5V8g2vkqtY3wU02N 823X7o3oNZYq5yZFTbexH8Al+ys9KvKlu5q0YRYvbBwvI/yGHyr/gEI7ufV+9tZ6 z9Mo2hCBsaM0vrikBzejhjSw5qc4HcwMKErlC3cHQHIbszryu1O0WY1G22pwYgss mAGDr6OcdeIdMyNcJlpyH8+jToRSJrkAwDSPdQz+IVMq785x0GnOo2uV2/7NTr2J +LVUjSjAenRhPX+TrAFFujNYXZf5uD/EUfsGyUyCdBhJ5PWsLjYQ/EYD6PToDX8P BdocR3XfxZS7nD5PYRDfyWNeckCL6VPrnZrgMGIYBEXAn7jhX608vzmZV7IU7mzv 3NrnDWpllK4M42hT7fXs =hV51 -----END PGP SIGNATURE-----

3 3