- tor-relays - lists.torproject.org

Jump in brute force complaints
by Kura 05 Jan '15

05 Jan '15

I've noticed a rather large jump in abuse emails from admits about brute force attempts coming from my exit nodes. I've had a handful of these in past, as you'd expect but now they are arriving multiple times a day, some automated emails, some not. Has anyone else noticed a jump in abuse complaints? Curious as to whether it's a spike in the network being used for abuse, more admits reading logs or just my luck. -- Kura t: @kuramanga [https://twitter.com/kuramanga] w: https://kura.io/ [https://kura.io/] g: @kura [http://git.io/kura]

7 7

Re: [tor-relays] tor-relays Digest, Vol 48, Issue 12
by bigbudtor＠Safe-mail.net 05 Jan '15

05 Jan '15

-------- Original Message -------- On January 4, 2015 11:14:17 PM bigbudtor at Safe-mail.net wrote: > Hi, > > No dirservers reachable sounds like a pretty good reason why your not > getting anything anymore. Did you try to reach any of them manually ? That > sounds to me like there is either something wrong with the connectivity or > it is massive blocking. I can resolve the hostnames and then connect to the dir port on each of the directory authority servers manually using netcat. The relay is clearly still up and holding connections (down to around 80 inbound now, a few outbound and a small number of exit connections).

1 0

Re: [tor-relays] Help - My relay consensus has been stripped back to 20
by Sebastian Urbach 04 Jan '15

04 Jan '15

On January 4, 2015 11:14:17 PM bigbudtor(a)Safe-mail.net wrote: Hi, > > > > Message: 3 > > Date: Sat, 03 Jan 2015 02:30:55 +0100 > > From: Sebastian Urbach <sebastian(a)urbach.org> > > To: <tor-relays(a)lists.torproject.org> > > Subject: Re: [tor-relays] Help - My relay consensus has been stripped > > backto 20 > > Message-ID: > > <14aad6973e8.27ae.e04ee758f2dadc1889b5b423dda555f9(a)urbach.org> > > Content-Type: text/plain; charset="UTF-8"; format=flowed > > > > On January 3, 2015 2:03:33 AM bigbudtor(a)Safe-mail.net wrote: > > > > Hi, > > > > > > As i recall there was a mail from Giovanny a few days ago and he reported > > his relay being down. But he had log file entries like: > > > > [warn] http status 400 ("Authdir is rejecting routers in this range.") > > response from dirserver '128.31.0.39:9131'. > > > > Any of those in your log ? > > > > No I don't see anything resembling that, although I am seeing these events > messages in the logs every couple of hours: > > Dec 30 07:52:28.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 30 09:55:29.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 30 11:52:24.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 30 13:53:23.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 30 15:52:20.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 30 16:06:34.000 [info] router_upload_dir_desc_to_dirservers(): > Uploading relay descriptor to directory authorities > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 16:06:34.000 [info] directory_post_to_dirservers(): Uploading an > extrainfo too (length 3891) > Dec 30 17:52:19.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 30 19:53:18.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 30 21:39:02.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 30 23:33:58.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 31 01:32:55.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 31 02:52:13.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > Dec 31 05:05:32.000 [info] router_pick_dirserver_generic(): No dirservers > are reachable. Trying them all again. > > I don't appear to have any routing issues, resolution issues or similar but > don't have logs old enough to see if this is an unusual log event or not, > it may be completely unrelated. > > As it stands I am afraid that there doesn't seem to be any real alternative > other than decommissioning this exit relay. It is costing money and doing > nobody any good right now. No dirservers reachable sounds like a pretty good reason why your not getting anything anymore. Did you try to reach any of them manually ? That sounds to me like there is either something wrong with the connectivity or it is massive blocking. > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Sincerely yours / Sincères salutations Sebastian Urbach ----------------------------------------- Definition of Tor: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

1 0

odd list of connections
by TOR Zone 04 Jan '15

04 Jan '15

1 0

Someone broke the tor-relay speed record?
by Justaguy 04 Jan '15

04 Jan '15

https://globe.thecthulhu.com/#/relay/F528DED21EACD2E4E9301EC0AABD370EDCAD2C… Someone just got 149.08 MB/s on a non-exit relay. This is amazing! Would you mind saying what kind of hardware you use for this? Ipredator used https://ipredator.se/guide/torserver to get to 101MB/s. So your setup should be even more extreme. -- PGP fingerprint: 8516 5FFC 011A 6465 D042 6AC1 D719 1F41 B7CE EDFF OTR fingerprint OFTC: FF6D1AC2 13F38B15 EDB21522 D3530A6F 6EE01996 OTR fingerprint freenode: 293FAFD3 1155A465 C5B77015 B65E8AEC 63A1AF21 Full PGP public key: https://justaguy.pw

6 11

Location of Tor relays being incorrectly reported in Atlas
by Joshua Lee Tucker 04 Jan '15

04 Jan '15

Hi guys, Two of my Tor relays are being reported as being located within the USA within Atlas; these nodes are actually located within London, UK - the location is correctly identified when using an IP->Location service. I’m just wondering why this would occur? The two IP addresses are: 178.62.75.82 178.62.77.54 Thanks guys, Joshua Lee Tucker

7 6

Re: [tor-relays] HardwareAccel: Current proper use???
by Sebastian Urbach 03 Jan '15

03 Jan '15

On January 3, 2015 10:41:42 AM usprey <usprey(a)gmail.com> wrote: Hi usprey, > Summary: > The documentation is still somewhat vague on the best use of the > "HardwareAccel" option. > > > *HardwareAccel* *0*|*1* The docu is not exactly a high-performance howto :-) > > > > If non-zero, try to use built-in (static) crypto hardware acceleration > > when available. (Default: 0) > > > I could not find a definitive answer in the archives or in > https://gitweb.torproject.org/tor.git/log/?qt=grep&q=hardwareaccel&showmsg=1 > . > > https://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration claims > no intervention is needed in regards of aes-ni accelaration, but I would > like to add an explanation or source to this recommendation. > > Question_1: > If my CPU supports and have loaded aesni_intel on linux with OpenSSL is > 1.0.1.j-1, should I leave HardwareAccel off or explicitly enable it? You don't have to change anything with 1.0.1.j-1, leave the default. > > Question_2: > What does "*built-in (static) crypto hardware acceleration*" refer to? > Dedicated hardware, CPU-support or...? It specifically means that you have the aes_ni cpu capabilities / flag. I have seen this flag on dedicated systems and also on vps systems as well. If the cpu / bios provides the flag and all other requirements are met (as stated in the torservers.net docu) you can use that feature on any system. I would very much appreciate it if you would switch to text mail format, thanks. Thank you very much for running a relay ! > > Best regards > > > > ---------- > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Sincerely yours / Sincères salutations Sebastian Urbach ----------------------------------------- Definition of Tor: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

3 4

High speed exit question
by Kura 03 Jan '15

03 Jan '15

Hey guys, I recently decided to get myself an 8 core, 16 GB RAM machine to use for running an exit relay and was wondering, Tor only works on one core, even setting NumCPUs to 2 doesn't do a whole lot so, how is it even possible to get more than maybe, 300Mbps or so from one relay? Maybe I'm missing something but, running multiple Tor processes is just going to have multiple relays with different OR and Dir ports for each, right? -- Kura t: @kuramanga [https://twitter.com/kuramanga] w: https://kura.io/ [https://kura.io/] g: @kura [http://git.io/kura]

6 8

HardwareAccel: Current proper use???
by usprey 03 Jan '15

03 Jan '15

Summary: The documentation is still somewhat vague on the best use of the "HardwareAccel" option. > *HardwareAccel* *0*|*1* > > If non-zero, try to use built-in (static) crypto hardware acceleration > when available. (Default: 0) > I could not find a definitive answer in the archives or in https://gitweb.torproject.org/tor.git/log/?qt=grep&q=hardwareaccel&showmsg=1 . https://www.torservers.net/wiki/setup/server#aes-ni_crypto_acceleration claims no intervention is needed in regards of aes-ni accelaration, but I would like to add an explanation or source to this recommendation. Question_1: If my CPU supports and have loaded aesni_intel on linux with OpenSSL is 1.0.1.j-1, should I leave HardwareAccel off or explicitly enable it? Question_2: What does "*built-in (static) crypto hardware acceleration*" refer to? Dedicated hardware, CPU-support or...? Best regards

2 2

Re: [tor-relays] Reduced number of HSDir's
by SiNA Rabbani 03 Jan '15

03 Jan '15

There was a new line added to authority director configs, which was a response to the recent Sybil attack [1]: MinUptimeHidServDirectoryV2 96 hours That's only 4 days, I wonder if anything else has changed. --SiNA [1] https://lists.torproject.org/pipermail/tor-consensus-health/2014-December/0… "Be the change that you wish to see in the world." - Mahatma Gandhi ----- On Jan 2, 2015, at 2:51 PM, Sebastian G. <bastik.tor> bastik.tor(a)googlemail.com wrote: > 02.01.2015, 19:47 Kura: >> I think something must have happened, I restarted half a dozen or so >> of my relays over a week ago and none of them have been given the >> HSDir flag, which if I remember rightly is a 21 hour flag? I may be >> mistaken but, I would have expected that flag to be back with over a >> week of uptime. > > It used to be a 25 hour flag. 1 day plus an additional hour. > > I think (yes, that says I don't know) the period being longer than 24 > hours had something to do with an attack to get relays under adversary > control in the right position to become a HSDir for some > hidden-services. If one pays for a relays by days an additional hour is > an additional day for an attacker. > > I may have missed something, but maybe it was raised. > > I do remember that changes to Guards took place, like requiring them to > have more bandwidth and to reducing the number of Guards clients would > use. This was due to research. > > Regards, > Sebastian > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0