- tor-relays - lists.torproject.org

Exitmap module to count CloudFlare CAPTCHAs
by Philipp Winter 20 Mar '16

20 Mar '16

I wrote an exitmap module [0] that can tell us how many exit relays see a CloudFlare CAPTCHA when connecting to a given site. First, I ran the module for coreos.com because it uses CloudFlare, but the owner configured it to whitelist Tor. Indeed, only one out of 864 exit relays saw a CAPTCHA: <https://atlas.torproject.org/#details/7DD29A65C370B86B5BE706EA3B1417745714C…> Next, I ran the module for cloudflare.com, which does not seem to whitelist Tor. 638 (75%) exit relays saw a CAPTCHA and 211 (25%) didn't. [0] <https://gitweb.torproject.org/user/phw/exitmap.git/tree/src/modules/cloudfl…> Cheers, Philipp

3 3

GoDaddy null-routing Tor Exit IPs
by Dhalgren Tor 20 Mar '16

20 Mar '16

FYI Tor-Relays GoDaddy AS26496 is null-routing selected Tor Exits, presumably in response to abuse originating from them. Know of two thus far FE67A1BA4EF1D13A617AEFB416CB9E44331B223A 2016/01/26 ashtrayhat3 A0F06C2FADF88D3A39AA3072B406F09D7095AC9E 2016/03/16 Dhalgren though probably more exist. Appears to affect faster relays. Affected relays running 'unbound' for DNS may experience total DNS request freeze and should switch to 'named' to mitigate the failure. Null-route seems to be manual and persist for indeterminate time. Null-routed IPs will not be able to ping or connect to address listed in the report at http://www.cidr-report.org/cgi-bin/as-report?v=4&as=AS26496 Information on how this was discovered can be found at #18580: exit relay fails with 'unbound' DNS resolver when lots of requests time-out https://trac.torproject.org/projects/tor/ticket/18580

1 0

please send me the hosters you use
by harvie josh 20 Mar '16

20 Mar '16

Hello! I'm spending quite some time in finding new cost-efficient VPS hoster in "unpopular" countries (non-exit). The relay community would actually have a lot information to provide in that regard - I think. I would really appreciate if you can share any hoster that provides VPSes with the following properties: * cost efficiency: at least 4 MBit/s per $ / month (min 20MBit/s) * not located in NL, FR, DE, US, GB, AS16276, Digital Ocean ASes * KVM or Xen based (no OpenVZ) * unmetered or at least 7TB/month outbound * proper https for customer area (reboot functionality, console access, ...) * English customer area You can also help by adding hoster information to your contactinfo field: ISP:<url to hoster> so others can find that (sometimes it isn't easy to find the hoster based on IP/AS information). So far I made good experience with itldc.com + price + reliable + SSH pub key pre-polulated in VPS + custom ISO possible + greate CPU performance in UA DC - plaintext root password in email mixed experience with seflow.it - almost regular outages - poor support (response time and know-how) - unable to provide correct billing information for hourly billed VPSes (start-stop times) ~ CPU performance + price (especially memory) + root password not disclosed via plaintext email unusable hoster ----------------------- alexhost.md Unreliable; to many outages serverastra.com no https coolhousing.net no https server.ua no https prohoster.info OVH reseller layeronline.com OVH reseller vmline.pl polish interface only unixhost.pro poor CPU/network performance (<15MBit/s) www.hosteasy.eu passport copy required ablenet.jp passport copy required albahost.net simply failed to provide working VPS vinahost.vn international traffic limited to 10MBit/s www.infiumhost.com no proper https (self-signed cert) alphavps.bg metered <1TB/month xserver.ua customer area language vps.ua customer area language Rx-name.ua no reaction to email request If you can not suggest specific hoster but good sites to find new hoster that is also great, like: https://www.exoticvps.com/ https://www.lowendtalk.com/ https://www.webhostingtalk.com -- harvie josh

5 7

What IPs does Torbrowser need?
by Martin Kepplinger 19 Mar '16

19 Mar '16

Hi Imagine a router that want to only whitelist the IP addresses that Torbrowser needs to work. What IPs would it need (for start up and browsing) ? * Guards * Authorities * HSDir flagged relays (?) and would such a whitelisting of IPs even work? At least I think DNS can be ignored as it is routed over Tor too. Any more thoughts? ps: please leave me in CC as I'm not on the tor-talk list. thanks!! martin

2 1

fast exits running 'unbound' should switch to 'named'
by Dhalgren Tor 19 Mar '16

19 Mar '16

Bug #18580: exit relay fails with 'unbound' DNS resolver when lots of requests time-out https://trac.torproject.org/projects/tor/ticket/18580

2 2

unbound bogs down strangely, degrading exit relay
by Dhalgren Tor 18 Mar '16

18 Mar '16

Hit a repeat of an earlier incident: https://lists.torproject.org/pipermail/tor-relays/2016-January/008621.html message from tor daemon is Resolved [scrubbed] which was already resolved; ignoring About 5400 of these messages over 37 hours, during which the relay dropped down to 30% of usual load and did not work for Tor Browser when the exit was specifically set. Unlike the earlier incident, DNSSEC was disabled. Probably the IP address for root-server H was incorrect because it changed in December and 'unbound' was built in September. Just installed and configured the current 'named.root' hints file. Both "iterator" and "validator" modules were loaded, though validation was disabled. Changed the config to load only "iterator". Unbound 1.5.4, tor 0.2.6.10. Running 164 days. If I see this again I'm planning to attempt purging the 'unbound' request queue with unbound-control dump_requestlist >reqlist.snap unbound-control flush_requestlist and if that doesn't work, bouncing 'unbound' without stopping the 'tor' daemon. Interesting stats were recorded, starting with the good pre-incident entries: Mar 11 05:53 notice: sendto failed: Invalid argument notice: remote address is 0.0.0.1 port 53 ...repeated 4 times Mar 15 17:45 server stats for thread: 1029423 queries, 415824 answers from cache, 613599 recursions, 0 prefetch server stats for thread: requestlist max 132 avg 22.5692 exceeded 0 jostled 0 average recursion processing time 4.070100 sec Mar 16 05:46 Resolved [scrubbed] which was already resolved; ignoring Mar 16 17:45 server stats for thread: 1162172 queries, 287662 answers from cache, 874510 recursions, 0 prefetch server stats for thread: requestlist max 421 avg 198.684 exceeded 0 jostled 0 average recursion processing time 25.833646 sec Mar 16 21:08 notice: sendto failed: Invalid argument notice: remote address is 0.0.0.1 port 53 ...repeated 4 times Mar 17 16:52 notice: sendto failed: Invalid argument notice: remote address is 0.0.0.1 port 53 ...repeated 4 times Mar 17 17:45 server stats for thread: 1078496 queries, 144557 answers from cache, 933939 recursions, 0 prefetch server stats for thread: requestlist max 459 avg 296.668 exceeded 0 jostled 0 average recursion processing time 40.621863 sec service stopped (unbound 1.5.4). Mar 17 19:28 server stats for thread: 53991 queries, 3455 answers from cache, 50536 recursions, 0 prefetch server stats for thread: requestlist max 342 avg 290.977 exceeded 0 jostled 0 average recursion processing time 35.947563 sec If anyone has seen this or knows anything please comment. Tried searching but came up with nothing but thread referenced above.

2 5

Re: [tor-relays] Bandwidth Fallen Off Drastically
by stealth＠nym.mixmin.net 15 Mar '16

15 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 14 Mar 2016 19:29:58 +0000, you wrote: > > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Bandwidth Fallen Off Drastically (stealth(a)nym.mixmin.net) > 2. Re: Bandwidth Fallen Off Drastically (Daryl Styrk) > 3. Re: Bandwidth Fallen Off Drastically (s7r) > 4. Re: Bandwidth Fallen Off Drastically (Sebastian Niehaus) > 5. Re: Running 5000 relays... (Brian 'redbeard' Harrington) > > > ---------------------------------------------------------------------- > > Message: 3 > Date: Mon, 14 Mar 2016 19:45:06 +0200 > From: s7r <s7r(a)sky-ip.org> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Bandwidth Fallen Off Drastically > Message-ID: <56E6F8A2.5030903(a)sky-ip.org> > Content-Type: text/plain; charset="windows-1252" > > Hello, > > Your relay seams fine on atlas: > > http://atlas777hhh7mcs7.onion/#details/A290A9E71ADFC2FB1C80E64EF851A4B90545… > > > It has an observed bandwidth of 582.23 KB/s > Advertised bandwidth of 512 KB/s > and burst 716.8 KB/s > > Which is exactly as per your configuration. > > The consensus weight is 613, which is totally normal for this value of > observed bandwidth. > > Tip: if you are on a limited bandwidth plan, better set AccountingMax > and do not cap the speed via RelayBandwidthRate / RelayBandwidthBurst. > Instead let it run at its maximum speed for less than an entire month > rather than capping it to few KB/s to ensure maximum n GB/TB are > consumed within a month. > In a previous post someone recommended that I try to reduce my bandwidth to allow my relay to stay active 24/7 x 31 days. This is why I removed the AccountingMax setting and reduced my RelayBandwidthRate to 500kb/s and RelayBandwidthBurst to 700kb/s. What concerns me is that while running arm in graph mode, I rarely see the bandwidth rate steadily flow around 500kb/s. With a 3tb bandwidth limit per month, following your recommendations, would you recommend that my AccountingMax be set to 55gb per day up and down and turn off RelayBandwidthRate and RelayBandwidthBurst? This will probably mean that the bandwidth will be used up within the first 10-12 hours of each day and my relay will be in hibernation for the remaining portion of that 24 hours. This hibernation period appears to affect the uptime statistics, which means my middle consensus numbers will drop as a consequence. I'm trying to figure out what's the secret sauce here to keep the relay running 24/7 and stay within my 3tb bandwidth limitation. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) iQIcBAEBAgAGBQJW5yi+AAoJEH1gNwhiMDZubTgQAJuj6EdfLZsyPsLxfeiLA2nh w52jJLO3yXg+InJ4IzoSaHzbXsqdUuSmj7RxOsgTr9K1xflX3XkdNmlWYkhs005F JNMGyglnOb3LlSbJ9fxspZH1KOhwJwy9ZJrHGRqVRXrAC7VBMpJ016TEcFNL3daL J98LhZuyN5Iecm0k9LhuxoZ0YfnCc03qpkUJDMiM0khsXfoesFWd+Zdss/Igj2aC mVcE+BMKvO8gHATdVytvHvqqZ07unIAV6mRkw/c/NBqRh07xX6qEJwoDANCEvfS6 7NGQZpgEVWw2lT2GPj5T4WGmEPN6CAfCJTE7fJG1IA1j4iLNgHwRM7kKxQpFWpVa CAwE8wgc9BxFYCVg8Kzjr/PDJO7mNLFRH3yXXJ9dTo6qS+GRxdZEYTH6FaNc9ERP W9/hnv18bo0IuQ+o8+sMtzDbAbyyPXDeSbx2qHOzxuTJkzLPkq2t8W2HX5kiurZ8 MIkdkJH+bc71EwV1YBzb/Ca4/kdqTRqEMJzXFtn8wq6fa1uRxDC1S7Su374y4fTy C1OmTfURhKhK39yVFVJrKqINsgE1GQnKikE2DCMlbrp+IFaItrDOg+gx81mO7WkK /KbpxnKJotLxIxBX12j0T6CYyGKQio6SSTbI0iObsXJNpEkQCX+jPp3GDDcWPzlK p/XtNor8MXQS1u96hpwP =z+T6 -----END PGP SIGNATURE-----

2 2

Bandwidth Fallen Off Drastically
by stealth＠nym.mixmin.net 14 Mar '16

14 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have been watching my middle relay for the past four days and I can't figure out why my bandwidth has gone to hell. I have RelayBandwidthRate at 500 KB and RelayBandwidthBurst at 700 KB, but my bandwidth has fallen almost down to zero. I have removed the AccountingMax setting so it should be available for service, but it appears to be sitting idle. fingerprint is 'stealth A290A9E71ADFC2FB1C80E64EF851A4B905450105' Tor Version 0.2.7.6 Debian 7.0 1 Meg of Memory on VPS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) iQIcBAEBAgAGBQJW5t3wAAoJEH1gNwhiMDZuSasQAKQ0PQrNqqVl2x0nhKUPvZTz xCffMMmDeE+xU3QvMhGDxuliIJVgxuP0jqtXzZ6Vrxr9QQ4f7XwuK057O8PD9nnq B5UsYXjoV/2VsDgv0n+mOv3LmQB2CJv/GJzSnl4/ZYaW8k76P0FavS6HHpZKnM6T g5ybxnscpiSbP6GO1ZuK3cRxDfTFtoh80HsShgDG7VAOHPzyFNz4diKQJ3J5LQe5 1QDvFB6l4VUZTCN9++2NvwLkvIGS9xMeX4TOOVwwV9lZDmU+aE0zH3EkIJrnhjv4 tToyypxCCTLkgTN6BkFTF7Ug07H4oqs0J09SWkLT6XUsvm+QSf7dL2Nzujp1KkYl yuZLqkpxgtgUPde3Ejcdgzy9Zv3y+j89f+JavAWy5VAQ5779V8nKonYclINROpcX 2PlOuE4GvrOrurUQzQJJfvSkWEF3NNJjvrAZGyM6X79v/F6/zod1QV5a0/ASUY5g vNUbLQfjGHExf86UZRak1un1x4/yzESnddZPHWALcNR/JHQHgra7+283RHqVNxeX 7zggM+HNxIxKYngC4B4V+9hZnuXE8Ty2444ykXNrZibQSDiFf5RIBBffmbRtJxzJ K/Jrdw9VyajNPx4AnV+gnh611+bgNw9Rpo1WKHd0KOdeLhKUC8js1ZvZpiPpqojR CPkUwxBAh8Ydt4HEp3Mw =jZnl -----END PGP SIGNATURE-----

4 3

Re: [tor-relays] tor-relays Digest, Vol 62, Issue 13
by stealth＠nym.mixmin.net 09 Mar '16

09 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 09 Mar 2016 01:16:18 +0000, you wrote: > > Message: 3 > Date: Wed, 9 Mar 2016 12:08:31 +1100 > From: Tim Wilson-Brown - teor <teor2345(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Hibernation Expectations > Message-ID: <6449D528-F52E-49E6-8331-0F3276365348(a)gmail.com> > Content-Type: text/plain; charset="us-ascii" > > > > On 9 Mar 2016, at 05:29, stealth(a)nym.mixmin.net wrote: > > > > Signed PGP part > > I am allocating 100gb of bandwidth up and down every day. When my > > middle relay goes into hibernation, should I expect my stats to go > > to hell? Should I also expect my flags my stable and guard flags to > > be removed? > > Yes, but they'll come back eventually. > > > > > If I reach my bandwidth restrictions 10 hours before it is reset, > > is this the reason why the relay would lose guard and stable flags? > > I may need to restrict my bandwidth to 60gb up and down as I only > > have 3tb of bandwidth to donate on a monthly basis. > > This is another question we see frequently. > Until we get a FAQ or wiki entry for it, I'd encourage you to search the list archives for previous answers. > > There are good reasons to run a relay that's always on. > Then again, there are also good reasons to run a fast relay. > If you're very close to your bandwidth cutoff, why not decrease it slightly, and run all the time? > > Tim I have changed my AccountingMax to 60gb and my RelayBandwidthRate to 5mb and my RelayBandwidthBurst to 10mb. I will monitor these settings for the next couple of days to see, if I reach my AccountingMax number. If I do reach the AccountingMax number then I will reduce the RelayBandwidthRate and RelaybandwidthBurst down until my server can run 24/7. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) iQIcBAEBAgAGBQJW4G4MAAoJEH1gNwhiMDZu8bsP/3j4GYhUKZMZbnm2+i+7XJ5C vGWxQgHC/7bMe5zuQY7CjHuPZRjqNImbQTy8FPLb1NGKuutVS1RcQafDvTVBUJiL a64dTCAAbf12AScSxCzhqgBpWQ1nW2mKRPTeGUOrkeCPgx3o/Cqby5U3fL0Hcy3R lhrTWOlca3waJDnpNzlslMgXVLhoR+cspflKoi+NzFoanHDveipkcZEr65cIBoWJ QlYcfH0CE1070W68DatwtNzyQW7Mm9bMULX8aWJQpjMIvd/GKZ6OGGysXjgLDbDN x2b7/VcHuxNXaVJSbhdenoA2GoF1h02Sl9K1QUMVo46LqVfsJiZduSmvB4EJz9VA KsMmTc3C51Mp3EgdH538gP9lfNA/PhT/1KrHFz9ILnC0sy9E8zxHzpk9+Lt7652/ PTaeVE0+1epAVG3namxaMLiK36gOUD4xuGi3UP18U2s7UzlaesEusSie6j+wHZid /D3pQTE50Mj7eb4yxLziBU/DS3UB4FwhRphCKqnB/ZdJWbMZ88hAfwfcgxmTjvB0 7fZ6wtZDsdAqWPOTzRlkEVifS1ZcS0WgT2FGSmzBbUH7/hT9YTuKdHelUNrYBJy+ 3b5A+6/kMCBUV0bJjiUirINATG0XJDGoYmSjFm/Z7ac/vfOh+TXzTwiG+yITJ1cA FuaKL42rov2Ier2nWnYu =BnNF -----END PGP SIGNATURE-----

1 0

Hibernation Expectations
by stealth＠nym.mixmin.net 08 Mar '16

08 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am allocating 100gb of bandwidth up and down every day. When my middle relay goes into hibernation, should I expect my stats to go to hell? Should I also expect my flags my stable and guard flags to be removed? If I reach my bandwidth restrictions 10 hours before it is reset, is this the reason why the relay would lose guard and stable flags? I may need to restrict my bandwidth to 60gb up and down as I only have 3tb of bandwidth to donate on a monthly basis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) iQIcBAEBAgAGBQJW3w91AAoJEH1gNwhiMDZuPo0P/2jKTt3DAX6pFIU70nTl55IE RxgP45KZnv7RmqLPN5T4UAKl7BmuhWLDY7uIRzfoagersXNXbWrcvRZrpGR8Eycf OS4jNjw0WPX3AgzmU0XeIkPypu2vJ1Qdz3dfRsNiguwUPwPHvGE9d6yKp/3DztYs rtBcWQ0yiCn3vDLgEHSjyUop35lJla9Rg1l7DWgfJEKc+6zqOMsLod5Ie0ZVETOY b8gmP0Ct9Bqyzj9zHlXbEgk0M9t7f2g/cOkX1G3ABBQVMe83rcssNPodDy8xFpYm AA0K6LmUzz94kxhmu/wzph48PRsm5cdr4mAXbDkKkVlQxszHCGZqbMR2Zdff6txh GGSb8AdXX7eTzsIAJ8eDN2ZsWsneuKiofvXY2oSyuOpgl+jeHxivXJoYunXvEQER rikVhoZkn0X4hotNzIAWdEQgifmfxhGXuphytHNphCFkCY5I6UY+HNLjcZTl+9OH vytFYvpy/zc5zEjHhrM6FWxXYSgBCL34jo0L9Hr6dqDYD4pPBf/Td2CiBXdNEliK tD+JYlH9gFQ/TmNePef9za1vWF0t+8QlpsZYqTZ3xuHYN24Znjdnklr+nbIlrUTp 9tpibQ4MisX781wadp0OCqePmxZjyiwnZEHxHNlW6KcrvP37kXTmIFdybUZV6eYx equ2uTmOQ9EzuJidfxO4 =zOMH -----END PGP SIGNATURE-----

3 2