Re: [tor-relays] Become a Fallback Directory Mirror
AA0D167E03E298F9A8CD50F448B81FBD7FA80D56 ++ 21/12/17 10:50 +1100 - teor: >Dear Relay Operators, > >Do you want your relay to be a Tor fallback directory mirror? >Will it have the same address and port for the next 2 years? >Just reply to this email with your relay's fingerprint. > >If your relay is on the current list, you don't need to do anything. > >If you're asking: > >Q: What's a fallback directory mirror? > >Fallback directory mirrors help Tor clients connect to the network. >For more details, see [1]. > >Q: Is my relay on the current list? > >Search [2] and [3] for your relay fingerprint or IP address and port. >[2] is the current list of fallbacks in Tor. >[3] is used to create the next list of fallbacks. > >Q: What do I need to do if my relay is on the list? > >Keep the same IP address, keys, and ports. >Email tor-relays if the relay's details change. > >Q: Can my relay be on the list next time? > >We need fast relays that will be on the same IP address and port for 2 >years. Reply to this email to get on the list, or to update the details >of your relay. > >Once or twice a year, we run a script to choose about 150-200 relays >from the potential list [3] for the list in Tor [2]. > >Q: Why didn't my relay get on the list last time? > >We check a relay's uptime, flags, and speed [4]. Sometimes, a relay might >be down when we check. That's ok, we will check it again next time. > >It's good to have some new relays on the list every release. That helps >tor clients, because blocking a changing list is harder. > >Q: What about the current relay DDoS? > >We don't think the DDoS will have much impact on the fallback list. > >If your relay is affected, please: >* make sure it has enough available file descriptors, and >* set MaxMemInQueues to the amount of RAM you have available per tor > instance (or maybe a few hundred MB less). > >We're also working on some code changes. See [5] for more details. > >[1]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors >[2]: https://gitweb.torproject.org/tor.git/tree/src/or/fallback_dirs.inc >[3]: >https://gitweb.torproject.org/tor.git/tree/scripts/maint/fallback.whitelist >[4]: >https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_2017-05-16-0815-09cd78886.log >[5]: >https://lists.torproject.org/pipermail/tor-relays/2017-December/013881.html > >-- >Tim / teor > >PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B >ricochet:ekmygaiu4rzgsk6n >-------- > >___ >tor-relays mailing list >tor-relays@lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] SSH Bruteforce Attempts
Hey, Yes, I do more or less the same. If the complaint is sent using some automated system, I "do nothing." If the complaint is sent by a human, I'll answer them with a template, see below. If there is a followup response to that, I'll do some more explaining, oftentimes pointing them at the block lists provided by the Tor Project. Here's the default answer: --- Thanks a lot for your notification. The traffic originating from the IP-address is traffic from a Tor exit-node. As I am not sure whether you are familiar with the Tor network, I would like to provide some explanation. Tor is network software that helps users to enhance their privacy, security, and safety online. It does not host any content. Rather, it is part of a network of nodes on the Internet that simply pass packets among themselves before sending them to their destinations, just as any Internet intermediary does. The difference is that Tor tunnels the connections such that no hop can learn both the source and destination of the packets, giving users protection from nefarious snooping on network traffic. The result is that, unlike most other Internet traffic, the final IP address that the recipient receives is not the IP address of the sender. I run a Tor node to provide privacy to people who need it most: average computer users. Tor sees use by many important segments of the population, including whistle blowers, journalists, Chinese dissidents skirting the Great Firewall and oppressive censorship, abuse victims, stalker targets, the US military, and law enforcement, just to name a few. While Tor is not designed for malicious computer users, it is true that they can use the network for malicious ends. Of course, the Tor network may be abused by others and apparently this is what you are seeing. I am very sorry for this to happen to you. In reality however, the actual amount of abuse is quite low. This is largely because criminals and hackers have significantly better access to privacy and anonymity than do the regular users whom they prey upon. Criminals can and do build, sell, and trade far larger and more powerful networks than Tor on a daily basis. To avoid any more traffic from this source, you could (temporarily) block the IP-address of my Tor exit node. You also have the option of blocking all exit nodes on the Tor network if you so desire. The Tor project provides a web service to fetch a list of all IP addresses of Tor exit nodes that allow exiting to a specified IP:port combination, and an official DNSRBL is also available to determine if a given IP address is actually a Tor exit server. --- ++ 04/10/17 02:44 + - teor: > >> On 3 Oct 2017, at 22:35, tanous .c <sawt...@gmail.com> wrote: >> >> Have any of you had this sort of problem? I'm having difficulty determining >> if this log information represents a normal exit relay ocurrence or if my >> server has been compromised... What could i do in order to solve this? > >Yes, Profihost sent me one recently that looked very similar. >Fortunately, I use OutboundBindAddress, so I knew it was >(very likely to be) exit traffic. > >You can: >* do nothing >* respond and ask for verification that they want your exit > to block their site, but explain that they need to block > all Tor Exits for the traffic to stop >* add exit policy entries to block each of the mentioned > IPs and ports >* block port 22 on your exit > >I'll be doing nothing. > >You should consider your provider's reaction, because they >may want you do something about the complaint, even if >it's something ineffective. > >Tim >___ >tor-relays mailing list >tor-relays@lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Draft Fallback Directory List
Hey Tim, My relay now should be available on both IPv4 and IPv6. But, to be honest, I don't see how I can verify the correct functioning of IPv6. Here are the details: namerejozenger fingerprint AA0D167E03E298F9A8CD50F448B81FBD7FA80D56 ipv4 address94.142.242.84 ipv6 address2a02:898:24:84::1 Kind regards, Rejo Zenger ++ 12/12/16 21:39 +1100 - teor: On 12 Dec. 2016, at 19:15, Rejo Zenger <r...@zenger.nl> wrote: Hey! I do have IPv6 available, but I hadn't taken the time to actually enable it. I will look into it one of the next days and when enabled, I'll let you know about the IPv6 address. Node: rejozenger, FP: AA0D167E03E298F9A8CD50F448B81FBD7FA80D56 Kind regards, Rejo Zenger Thanks, that would be great! T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF Signal82597 53935 59879 30955 36233 06160 [...] signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Draft Fallback Directory List
Hey! I do have IPv6 available, but I hadn't taken the time to actually enable it. I will look into it one of the next days and when enabled, I'll let you know about the IPv6 address. Node: rejozenger, FP: AA0D167E03E298F9A8CD50F448B81FBD7FA80D56 Kind regards, Rejo Zenger ++ 12/12/16 08:49 +1100 - teor: On 12 Dec. 2016, at 05:08, Andrew Deason <adea...@dson.org> wrote: On Sun, 11 Dec 2016 23:45:42 +1100 teor <teor2345-re5jqeeqqe8avxtiumw...@public.gmane.org> wrote: One or more of your relays have been selected as fallback directory mirrors[0] for the next tor release. Please keep the relay available on the same addresses, ports, and identity key (fingerprint) for the next 2 years. Does ipv6 connectivity matter at all for the purposes of being a fallback directory mirror? I can see of course it's not required, but I'm not sure if an ipv6 address would be used at all (as a directory mirror). That is, if I added a v6 addr to a relay in that list, would that help anything, or not yet? It helps clients configured to use dual-stack IPv6: ClientPreferIPv6ORPort 1 And clients configured to use IPv6 only: ClientUseIPv4 0 UseMicrodescriptors 0 But as they are manual configs, not many clients use them yet. We want to make dual-stack easier (even automatic) on clients, but we need more IPv6 relays to preserve client privacy. I assume that adding a v6 address does not violate the "keep the same address/port/key for the next 2 years" requirement. Is that correct? Yes, but you need to keep *both* addresses for 2 years after you add IPv6. Let me know, and I'll add the IPv6 address to the fallback list. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF Signal82597 53935 59879 30955 36233 06160 [...] signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] webiron requesting to block several /24 subnet
++ 17/11/15 02:08 +0100 - Cristian Consonni: >2015-11-17 0:36 GMT+01:00 Dhalgren Tor <dhalgren@gmail.com>: >> Webiron's system sends notifications to both the abusix.org contact >> for the IP and to ab...@base-domain.tld for the reverse-DNS name of >> the relay IP. So if you can configure abuse@ for the relay domain to >> forward to you, you will see their notices at the same time as the ISP >> abuse desk. > >Thanks for the advice, I will definitely do that. >(also, at some point all this "pro-tips" for exit node operators >should be documented somewhere). If it is abuse-related, this may be the place: https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF Signal0507 A41B F4D6 5DB4 937D E8A1 29B6 AAA6 524F B68B 93D4 4C6E 8BAB 7C9E 17C9 FB28 03 signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] webiron requesting to block several /24 subnet
++ 20/10/15 13:57 -0700 - AMuse: >The TOR directory of exit nodes is readily available for ISP's and >website operators to apply in their filters. I don't see why them >putting the onus on tens of thousands of exit operators to exit-block >THEIR addresses is in any way reasonable. I do agree with the gist of your message. However, I wish you could say there are 'tens of thousands of exit operators'. :) -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF Signal0507 A41B F4D6 5DB4 937D E8A1 29B6 AAA6 524F B68B 93D4 4C6E 8BAB 7C9E 17C9 FB28 03 signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tools for managing multiple relays
++ 15/10/15 12:28 -0800 - I: >What does NL (CC)? I presume "Netherlands" and "Country Code". In other words, given the number of exit nodes in the Netherlands and/or the volume of bandwidth provided from the Netherlands, it's better to have new nodes elsewhere for reasons as diversity. -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF Signal0507 A41B F4D6 5DB4 937D E8A1 29B6 AAA6 524F B68B 93D4 4C6E 8BAB 7C9E 17C9 FB28 03 signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Calling for more Exit Relays
++ 21/08/15 12:21 + - Sharif Olorin: Could you estimate the number of abuse complaints you receive, or the amount of time you need to spend responding to them - and how many exits for how long, for context? I'd like to operate an exit node[0], With the experience of running a couple of exit relays, some of them high-bandwidth, all of them running the reduced exit-policy: just a few complaints worth responding to every month for every node. Most of the complaints are automated and replying doesn't do anything. I have a default answer that I send to non-automated complaints and hardly ever there is a follow-up to that. Rarely I see a request from a LEA, which always get more or less the same answer (a denial + explanation). In other words, it doesn't take too much time (provided you run your relay with reduced exit policy - or stricter). -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF Signal0507 A41B F4D6 5DB4 937D E8A1 29B6 AAA6 524F B68B 93D4 4C6E 8BAB 7C9E 17C9 FB28 03 signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] clarification on what Utah State University exit relays store (360 gigs of log files)
++ 09/08/15 06:44 + - Sharif Olorin: I'd be curious to know if anyone is running a relay that's not logged at all within its own AS; it seems like it'd be out of the reach of most operators, unless they have a friendly employer. Up until now, my host didn't do anything like netflow - but I am pretty sure that will change sooner or later (but even then I don't expect that data to be retained for any more than seconds). -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF Signal0507 A41B F4D6 5DB4 937D E8A1 29B6 AAA6 524F B68B 93D4 4C6E 8BAB 7C9E 17C9 FB28 03 signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Running a relay in the Netherlands
++ 21/07/15 20:59 +0200 - Jan Hendrik den Besten: I have my node running here in The Netherlands at UPC, now merged with Ziggo. I contacted them once: back then they did not have a problem running even an exit node. If that is a connection at your home and if that is an exit-node, be aware of the risks: your connection may be shut-down by your provider. For a write-up in Dutch: https://www.bof.nl/2014/12/17/juridische-risicos-van-het-draaien-van-een-tor-node/ -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF Signal0507 A41B F4D6 5DB4 937D E8A1 29B6 AAA6 524F B68B 93D4 4C6E 8BAB 7C9E 17C9 FB28 03 signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Leaseweb exit relay notice
++ 25/05/15 12:48 -0400 - t...@t-3.net: A lot of trouble would be prevented for exit node operators if, when they brought their relays up for the first time, they ensured that the exit policy rejected port 25. Even if they desire to run as unrestricted a relay as possible, in my experience, that one really should be rejected. It is the Some (or most or even all) of the Leaseweb nodes didn't forward port 25. So, alltough you advice is a good one, it's not applicable to some (or most or even all) of the nodes that are discussed in this thread. -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF Signal0507 A41B F4D6 5DB4 937D E8A1 29B6 AAA6 524F B68B 93D4 4C6E 8BAB 7C9E 17C9 FB28 03 signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Leaseweb exit relay notice
++ 25/05/15 13:47 -0400 - t...@t-3.net: Doing nothing on email ports but still ending up on a meaningful number of RBLs doesn't sound right. Maybe all it took to piss the ISP off was for one of them to do it. Maybe. Maybe there has been some internal policy change within Leaseweb, maybe there has been a policy change on some sites deploying particular DNSBL's triggering a change of policy within Leaseweb. So many possibilities to choose from. :) -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF Signal0507 A41B F4D6 5DB4 937D E8A1 29B6 AAA6 524F B68B 93D4 4C6E 8BAB 7C9E 17C9 FB28 03 signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Leaseweb exit relay notice
++ 21/05/15 22:04 +0200 - Jurre van Bergen: I got the same message yesterday, I asked leaseweb to put our exit node(hviv103) in a dirty ip-block and asked sectoor for a clarification on what happened. No reply to date of any party. This DNSBL has a fairly straightforward listing for an IP-address: ((the IP-address itself is a Tor exit-node OR the IP-address is within a /24 that has some other IP-address with a Tor exit-node) AND the Tor exit-node(s) allow clients to connect to a list of about 15 different ports). Administrators are supposed to use this list as a scoring mechanisme, not for blocking. Of course, any administrator is free to use this DNSBL he or she wants. There's not much you can do - other than just not running the Tor-node. -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF Signal0507 A41B F4D6 5DB4 937D E8A1 29B6 AAA6 524F B68B 93D4 4C6E 8BAB 7C9E 17C9 FB28 03 signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Leaseweb exit relay notice
++ 21/05/15 22:35 +0200 - Tim Semeijn: The lists of SECTOOR might be used wrongly but they sound like they belong to the ever growing list of 'shitty blacklists'. In my work for In my personal opinion: you are barking at the wrong tree. It's your freedom to create a list of whatever you like with whatever criteria you please and name it whatever it makes you feel good. And yes, of course, it is your freedom to label one more of those lists as shitty blacklists. Point is: I don't think there is such a thing as a shitty blacklist. In the end it's up to the administrator of a server to use or not to use a list. And yes, I am aware some issues may arise if one of thoses lists has a large user base (as, in that case, the compiler of that list may (ab)use that power). It's not that I am 100% in favor of these lists. :) -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF Signal0507 A41B F4D6 5DB4 937D E8A1 29B6 AAA6 524F B68B 93D4 4C6E 8BAB 7C9E 17C9 FB28 03 signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Legal situation of tor in Europe
++ 09/03/15 06:16 + - oneoft...@riseup.net: Can someone point me to an overview of the different legal situations for running tor relays in European countries? I'm especially interested how the situation differs per country. I can't really help you: I don't have the overview of Europe, nor I am a laywer. Having said that, in the Netherlands there would be two considerations to make when running an exit-relay. 1) Your provider may consider your use breaching their AUP. You may be held responsible by your provider for the traffic to the internet that is leaving your connection, even if in fact it is the traffic of others. So, if someone else using the Tor-network, is incidentally using your exit-node and is doing something your provider doesn't like (e.g. sending spam, doing hacking attempts), your provider may complain to you. As you are not in the position to stop this, your provider may disconnect you. However, there's this clause in the eCommerce directive stating that you can't held resonsible for what is leaving your connection if you are only relaying the information (provided you meet three criteria [1]). Whether this also applies to the operator of a Tor-node is unclear: it has never been tested in court. 2) The police may knock on your door and ask you to complain. If someone hacks into a computer while exiting the Tor-network using your relay, your IP-address would seem to be the source of the hack. It's not that unreasonable that the police would ask you to elaborate. This explains why you should never mix your own traffic with that of your exit-node. In the Netherlands, the police does know about Tor more and more. Consequently, the changes that the police will knocking at your door just before dawn is getting smaller and smaller. Most of the times, the police will be able to tell a exit-node is involved and instead will call you for a visit to the police station (to explain the situation). However, the police of course still needs to consider your involvement for a moment and so may make a different judgement in specific cases. To the best of my knowledge, the last time a house has been raided just because the IP-address of the Tor exit-node of the owner was the source of malicious traffic was a long time ago. More than six years ago. I have seen reports of people invited to the police station, but those invitations were much more friendly and mostly meant to get a statement on the exit-node the owner was running. If you do have a different experience, in the Netherlands, please let me know. I have written about this in Dutch: https://www.bof.nl/2014/12/17/juridische-risicos-van-het-draaien-van-een-tor-node/ [1] You do no initiate the transmission, you do no select the receiver of the transmission and you do not select or modify the information contained in the transmission. -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF Signal0507 A41B F4D6 5DB4 937D E8A1 29B6 AAA6 524F B68B 93D4 4C6E 8BAB 7C9E 17C9 FB28 03 pgpSsmGfzTSLS.pgp Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] exit relay not utilising full capacity (even after months)
Hi, I am running an exit-relay and noticed a couple of odd things: 1. Last months, the node seems to be slow in using the full capacity. - Back in April, I changed the relay's configuration to allow the relay to use all the bandwidth it could take. As a result, within a week or two the bandwidth consumption went up to 50 Mbps. In the months of May to July, I had to limit the capacity of the node again. Mid-July I reverted to the same configuration from April. However, the node was a lot slower to pick up the full capacity. [1] - So, the question is: why is it so much slower maximising the full bandwidth? The configuration from mid-July onwards is identical to the one in April. The only thing that has changed is in mid-August, when I moved to relay into a LXC container. However, that doesn't explain the slow pickup in mid-July to mid-August. - And yes, I am aware of the Roger's blogpost. That does explain why the node may be slow to pick up traffic, but it doesn't explain why it was a lot faster in doing so in April then in mid-July. 2. Since Friday there is a considerable drop in the traffic. - Last Friday, around 23:00 hours CET the traffic dropped to about a third of it's usage the days before. Since then, there have been some increase from time to time, but the average is still half or even less than before Friday. There was no change in configuration. I don't have the time to investigate these issues myself. However, if someone wants to look into this, let me know and I am more than happy to provide the details needed. [1] https://rejo.zenger.nl/tmp/94.142.240.243_10-year.png [1] https://rejo.zenger.nl/tmp/94.142.240.243_10-week.png -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF pgpGOs4mGIpVy.pgp Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] exit relay not utilising full capacity (even after months)
++ 29/10/14 10:15 +0100 - Jeroen Massar: There are some weird properties in trying to do full-bandwidth. Deterministic it for sure is not. The IP is not mentioned in atlas: https://atlas.torproject.org/#search/94.142.240.243 Nope. That is the IP-address of the switch in front of the node. The IP-address of the node is 94.142.245.231. The fingerprint is, as you have figured out already, AA0D167E03E298F9A8CD50F448B81FBD7FA80D56. Is Tor 0.2.5.9-rc not outdated? You might be missing some features there. Fixed. It's now running 0.2.5.10. Are you also sure that coloclue likes you playing exit? (I can only assume so ;) Yes. Anyway, I can't explain i) why the node was picking up speed so fast during April, both before and after Heartbleed and why it is so slow picking up speed in mid-July and 2) why there is a sudden drop in traffic since Friday. As said before, I don't have the time (and lacking expertise to do this efficiently) to investigate these issues. If anyone else is interested, I am more than happy to help - of course. -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF pgplcMEtZhCgs.pgp Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] exit node experience: abuse over HTTP, stealrat infection
++ 21/10/14 22:29 +0200 - Manuel Gebauer: Although, the greater risk in my opinion, comes from the question if tor operators can be seen as service providers who would be exempt from responsibility for transmitted information under the term of this law. There's no precedence to my knowledge, but private wireless APs are in fact not exempt from responsibility. Citation needed. Für ein schlecht gesichertes WLAN besteht Störerhaftung. BGH, Urteil v. 12.05.2010, Az. I ZR 121/08, Link: A schlecht gesichertes WLAN is, of course, something else than a deliberately opened router. The intentions of the owner a different, for a starter. Anyway, I am not sure whether this is worth a discussion or debate on this list. -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF pgppe_yiGNEU_.pgp Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] exit node experience: abuse over HTTP, stealrat infection
++ 21/10/14 01:58 +0200 - Manuel Gebauer: I learned that the qualification not select or modify acually IS present in German law. § 8 TMG says, that the service provider is not responsible in so far as he did not chose or modify the transmitted information. As the e-Commerce directive is a directive (duh!) and not a regulation, this European rules need to be transposed to national laws in each every member state. The Dutch also have their own version. Although, the greater risk in my opinion, comes from the question if tor operators can be seen as service providers who would be exempt from responsibility for transmitted information under the term of this law. There's no precedence to my knowledge, but [...] That's right. Like I said: there is no case law, but it would be a most interesting case. -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF pgpfXbgqfnQAv.pgp Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] exit node experience: abuse over HTTP, stealrat infection
++ 19/10/14 16:13 +0200 - Manuel Gebauer: ii) in some legal systems this may mean you can be held responsible for the traffic that is routed via your node. Example? In Germany you might (or might not) be responsible for traffic you relay. But not relaying part of the traffic doesn't change a thing, legally. First: I was discussing a situation where the policy doesn't get published in the descriptor. For example, one is iptables to deny access to some IP-space. This is of course different from configuring this rejection policy in the Tor configuration file. As for the responsinilty: I was referring to the e-Commerce directive in the EU. Article 12 says: Where an [...] service is provided that consists of the transmission in a communication network of information [...], Member States shall ensure that the service provider is not liable for the information transmitted, on condition that the provider [...] does not select or modify the information contained in the transmission. I would says that if an operator rejects traffic using iptables, he does do selection of information contained in the transmission. Of course, this is different when configuring the rejection in the Tor configuration that gets published. As far as I know, there is no case law, so results may differ. -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF pgpVFOWDgvyRL.pgp Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] exit node experience: abuse over HTTP, stealrat infection
++ 19/10/14 13:53 +0200 - Tom van der Woerdt: Sounds familiar. This same company (valuehost.ru?) sends me about 20 abuse reports a day. At first I replied with explanations of what Tor is, explaining why it's hard to do anything against this kind of abuse. Later I [...] IANAL but you can probably just ignore those. I have had exactly the same experience with valuehost.ru. At this moment I'm ignoring any automated notification I receive from them. -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF pgpKQCMfJeiGa.pgp Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] exit node experience: abuse over HTTP, stealrat infection
++ 19/10/14 13:48 + - obx: Same here, I've blacklisted their /24 in my torrc. The complaints stopped. That is not a sound approach: i) Tor clients will see unexpected connection errors as some destinations are unreachable where they should and ii) in some legal systems this may mean you can be held responsible for the traffic that is routed via your node. -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF pgp424K6dGK3E.pgp Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Traffic limitation
++ 18/06/14 20:11 +0200 - johhher: I'm running a Tor relay on a cheap Linux vserver with high bandwidth. I have a traffic limitation of 500Gb per month and was just wondering what would be the best configuration for the network. I have a server with a similar cap and I am using the following configuration to maximize the utulisation (with some other traffic on the same link as well): MaxAdvertisedBandwidth 400 KB RelayBandwidthRate 200 KB RelayBandwidthBurst 400 KB AccountingMax 400 GB AccountingStart month 1 00:00 -- Rejo Zenger E r...@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J r...@zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF pgpLxhBQ6IUsz.pgp Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Google Groups Exit Policy Reject?
++ 24/02/13 23:08 + - Jonathan Baker-Bates: Yes, we did receive a similar request some time ago. We are not going to block whole Google Groups because of single/rare incidents. OK thanks Moritz - I'll ignore that then. Personaly, I would do this different: I'd explain what Tor, why it is important to have Tor around and how the complainer could block traffic from Tor exit nodes if really needed. Ignoring doesn't explain the importance - or, if it does, in an arogant way. -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail preferred . +31.6.39642738 . @rejozenger pgpq6zpmsGIdG.pgp Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bad exit
On 17 sep. 2012, at 10:44, Runa A. Sandvik wrote: Yep, I was seeing the same thing a few minutes ago (I believe the exit was 109C56AC68DB55D16E79F832E19313E6C3E47363, but someone should test and confirm). I cannot reproduce this issue. I have specified this exit node to be used as exit, verified based on IP-address and key. I was presented with a certificate I believe was valid. -- Rejo Zenger r...@zenger.nl| GPG: 0x21DBEFD4 https://rejo.zenger.nl/ +31 (0) 6 39 64 27 38 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Operating a sponsored relay II
On 31 aug. 2012, at 00:35, Dude wrote: So that leaves colo, but this gets expensive fast. This is very expensive outside the USA. Could I work as an agent of torservers.net? Is there a FAQ listing friendly ISPs? See: https://www.torservers.net/wiki/hoster/index -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail preferred . +31.6.39642738 . @rejozenger signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay info kit for Tor exits
On 24 aug. 2012, at 02:14, Roger Dingledine wrote: Also, my statement about RIPE uses something similar could use some fleshing out. You need a more descriptive text? I can provide that. Is it just a pointer you need, or do you want the text describing how to change the IP assignment registration itself? -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail preferred . +31.6.39642738 . @rejozenger signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay info kit for Tor exits at universities
On 12 aug. 2012, at 15:23, Moritz Bartl wrote: RIPE: I could not find a location that explains how to reassign IP space, but from what I know ISPs can do it via web interface. There are two ways of updating the RIPE database. There's a form on the website one can use, alternatively one can send updates by e-mail. -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail preferred . +31.6.39642738 . @rejozenger signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for discussion: turning funding into more exit relays
Hi, I am not in the position to comment on what would be good for the network, there are others more knowledgeable - like yourself. There's not much to add to your remarks. Having said that, I can comment on what I would change for me. I am currently providing a fast exit node on a colocated server I already was running. It's using spare traffic and bandwidth. Current limitations are based on the policy use anything that's left, as long as it doesn't cost me any bucks. I am more than happy to spend time and effort in running relays, but I don't have the budget to pay for more. 2) Should we fund existing relays or new ones? I would be able to help out with both. For me there would be at least three scenario's. 1) If there's reimbursement for (additional traffic on) existing relays, I would be able to add more traffic a month on my current relay. I would increase the limits on bandwidth and traffic. That way, an existing relay would be able to do more traffic. 2) If there's reimbursement for everything that is needed to run a relay, I would be able to add a new server. I would find other ISP's that sell VPS's or, when I would be able to get a new box, I could add another one at my current ISP. That way, a new relay would be added. 3) If there's reimbursement for even more, I would set up a non-proft foundation running multiple nodes. These nodes would ideally be spread amongst a couple of ISP's. That way, I would be able to add a couple of new relays. More generally, we need to consider sustainability. Our current exit relay funding is for a period of 12 months, and while there's reason to think we will find continued support, the Tor network must not end up addicted to external funding. So long as everybody is running an exit relay because they want to save the world, I think we should be fine. Given the above scenario's the sustainability largely depends on the scale. For example, when I would be reimbursed for the additional costs of the additional traffic, I can easily back down after 12 months. When running a foundation it would be more difficult to simply quit just because the sponsoring comes to a halt. On the other hand, a foundation would be run by multiple people, and as long as there is money to cover the costs of the relays, it would be a lot more stable than a number of smaller nodes. 7) How do we audit / track the sponsored relays? How should we check that your 100mbit relay is really working? What do we measure to confirm its capacity? To a first approximation I'm fine assuming that nobody is going to try to cheat (say, by colluding with an ISP to write legit-looking invoices but then just split the money). And what happens if there's doubt about the node someone is running? For a starter, maybe a solution would be: individuals are reimbursed a limited amount only, where larger amounts is available to legally registered foundations. -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail preferred . +31.6.39642738 . @rejozenger signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] running first Relay, low budget VPS on a Gigabit line
Hi Tim, Today iftop shows the VPS puts 35 MByte/s in both directions through the line. *Phew* The hosting plan includes 50GB per month so I'm a bit over the fair use. What would you do? Let it run? throttle down? do no harm? Check the comments and variables in the configuration file. The ones you are looking for are: RelayBandwidthRate RelayBandwidthBurst AccountingMax AccountingStart Any suggestions how to measure the traffic would be appreciated, must be roughly 12 TB the last 2 days. There are a number of approaches. I am running vnstat for this purpose. -- Rejo Zenger . r...@zenger.nl . 0x21DBEFD4 . https://rejo.zenger.nl GPG encrypted e-mail preferred . +31.6.39642738 . @rejozenger signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
