Re: [tor-relays] Become a Fallback Directory Mirror
Hi, If it is not too late, I would like to volunteer the relay 32828476F4F84E15C42B4C360A5CD8DE4C3C2BE7. Rhea On Sun, Jan 21, 2018 at 1:45 PM teor wrote: > Hi, > > > On 22 Jan 2018, at 05:01, Fabian A. Santiago > wrote: > > January 8, 2018 3:29 PM, "Spiros Andreou" wrote: > > Normalcitizen: E51620B90DCB310138ED89EDEDD0A5C361AAE24E > > > Original Message > > > Subject: [tor-relays] Become a Fallback Directory Mirror > > > Local Time: 21 December 2017 12:50 AM > > > UTC Time: 20 December 2017 23:50 > > > From: teor2...@gmail.com > > > To: tor-relays@lists.torproject.org > > > 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 > > > ___ > > > ___ > > > Hello, > > I've moved my relay to an unmetered provider, and intend to keep it up > long term. Here you are, if you can still use it: > > D122094E396DF8BA560843E7B983B0EA649B7DF9 > > > Thanks for running a relay! > > Yes, we can use your relay. > We will rebuild the list in 6-12 months. > > We are keeping track of opt-ins. Yours is here: > https://trac.torproject.org/projects/tor/ticket/24805#comment:8 > > T > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] debugging unbound on 'torexit' failing DNS queries (solved)
I can kinda answer that. I run an exit node that happily does 200-250mbit/s according to netdata accounting and my monitoring regularly pegs it at nearly 200k connections. Usually 100-150k. On Sun, Jan 21, 2018 at 4:06 PM, nusenu wrote: > > > Quintin: >> Ah, thats it. My conntrack entries are full and temporarily increasing it >> resolves the problem. > > I'm glad we found the problem and the solution. > > Your exit appears to be offline since 2018-01-20 20:00, expected downtime? > https://atlas.torproject.org/#details/92E3764D5485DC4AC01178271FB5A8A2D90DA9FF > >> What would be a reasonable conntrack limit for a tor exit? > > The amount of states depend on your consensus weight (and probably exit > policy), > do you require a stateful packet filter? > > > -- > https://mastodon.social/@nusenu > twitter: @nusenu_ > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Exit Flag Requires 80 and 443 (was: connlimit: better to use "DROP" or "REJECT --reject-with tcp-reset"?)
> On 21 Jan 2018, at 22:34, Toralf Förster wrote: > > On 01/11/2018 02:10 AM, teor wrote: >> So if you're going to do this, please set a much higher limit than 2. >> I would suggest at least 4, but 10 or more is better. >> >> You might be able to set it higher if you put a limit on repeated >> connection attempts. > > The simple approach (allowing 8 syn requests from an address at ORport and at > DirPort respectively) worked flawlessley for a while - just few > dozen/hundreds DROPs per hour. Since yesterday however I get > 100K DROPs per > hour. Your relays are now handling extra load, because they lost the exit flag and became guards. > Could a side effect of that traffic be that I lost the Exit flag ? No, the exit flag is determined by your exit policy, and the Tor version running on the majority of directory authorities. Recently, a majority of authorities upgraded to 0.3.2 or later. They require ports 80 and 443 for the Exit flag: https://trac.torproject.org/projects/tor/ticket/23637 Your exit policy does not include port 80, so your relays are not useful for clients to build general-purpose exit circuits. Please allow port 80 to regain the Exit flag. (The majority of Tor traffic is web traffic. Some of that traffic is unencrypted. This is bad, but enforcing port 443 on Tor clients would sacrifice usability and anonymity for security.) T -- Tim / teor PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Become a Fallback Directory Mirror
> On 22 Jan 2018, at 11:33, Rhea Tor wrote: > > If it is not too late, I would like to volunteer the relay > 32828476F4F84E15C42B4C360A5CD8DE4C3C2BE7. It's never too late - we rebuild the list every 6-12 months. We're tracking changes for the next list. Yours is here: https://trac.torproject.org/projects/tor/ticket/24805#comment:9 T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] kelihos infection
Hello fellow relay operators, I have received word from my ISP that they detected malicious traffic from my account. I'm running the exit node "cave" with reduced exit policy, https://atlas.torproject.org/#details/3875c9c843d33762fa733bcaf128f26a10bc75e7 The information received from my ISP was: infection => 'kelihos', subtype => 'kelihos.e', port => '52935', asn => '209', family => 'kelihos', sourceSummary => 'Drone Report' Typically they will also provide an IP address related to the infection, which is usually a sinkhole. The solution is to block the IP in my exit policy. However no IP was provided in this report and there is not one available, since my ISP is just relaying information they receive from a 3rd party detection agency. Furthermore, the port mentioned, 52935, is not allowed in my exit policy, so I'm guessing that port is somewhere else... Any ideas about this "infection" and how we could prevent it from using our exit nodes? Thanks ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] kelihos infection
This is like when I got the helpful notification saying that my exit relay was running Windows XP and I ought to upgrade it. You can, if you feel like it, write back explaining that your exit node happens to have been used to forward traffic on behalf of a computer that happens to be infected with Kelihos, and while it would be nice if you could notify the operator of that computer that they have an infection, by design of the Tor network this is not possible. Your exit relay will continue to pop up on future such scans and it would be best if they just ignored it. You apologize for the inconvenience. There isn't anything you can or should do about it configuration-wise. In particular, I am not finding mention of Kelihos using any specific port for its traffic, or any specific C&C servers, so there's no exit policy that you can set to prevent it. zw On Mon, Jan 22, 2018 at 3:50 PM, scar wrote: > Hello fellow relay operators, > > I have received word from my ISP that they detected malicious traffic from > my account. I'm running the exit node "cave" with reduced exit policy, > > https://atlas.torproject.org/#details/3875c9c843d33762fa733bcaf128f26a10bc75e7 > > The information received from my ISP was: > > infection => 'kelihos', subtype => 'kelihos.e', port => '52935', asn => > '209', family => 'kelihos', sourceSummary => 'Drone Report' > > Typically they will also provide an IP address related to the infection, > which is usually a sinkhole. The solution is to block the IP in my exit > policy. However no IP was provided in this report and there is not one > available, since my ISP is just relaying information they receive from a 3rd > party detection agency. Furthermore, the port mentioned, 52935, is not > allowed in my exit policy, so I'm guessing that port is somewhere else... > > Any ideas about this "infection" and how we could prevent it from using our > exit nodes? > > Thanks > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
