- tor-relays - lists.torproject.org

Re: [tor-relays] Optimizing TOR Relay
by Volker Mink 21 Oct '15

21 Oct '15

Its a Pi1, model B with 512MB RAM. RelayBandwidthRate 10000 KB # Throttle traffic to 1000KB/s (800Kbps) RelayBandwidthBurst 20000 KB # But allow bursts up to 2000KB/s (1600Kbps) MaxAdvertisedBandwidth 10000 KB (anything to change here?) I have a 60MBit Internet Connection at home with a static IP-Adress. Downstream about 65MBps, Upstream 5 MBps. Message: 1 Date: Tue, 20 Oct 2015 20:10:44 -0400 From: 12xBTM <12xbtm(a)gmail.com> To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Optimizing TOR Relay Message-ID: <5626D804.7070306(a)gmail.com> Content-Type: text/plain; charset=windows-1252 If this is a raspberry pi 2, set in Torrc: "NumCPUs 4" What is your advertised bandwidth? I can personally say that a RPi2 has no trouble moving 20Mbps, which would run you a ~50Mbps connection to get that kind of utilization. If you're talking about a RPi1, you don't have enough bandwidth dedicated to get the usage you want. On 20.10.15 8:08, Volker Mink wrote: > -now without HTML- > > Hi Folks. > > Some Stats: > fingerprint: E20FF09A9A800B16C1C7C16E8C0DF95F46F649B0 > cpu: 0.0% tor, 12.3% arm mem: 149 MB (34.4%) pid: 2200 > cpu: 20.0% tor, 10.2% arm mem: 149 MB (34.4%) pid: 2200 > > load average: 0,30, 0,36, 0,33 > %Cpu(s): 18,0 us, 3,1 sy, 0,0 ni, 75,3 id, 0,2 wa, 0,0 hi, 3,5 si, 0,0 st > KiB Mem: 445044 total, 349348 used, 95696 free, 79872 buffers > KiB Swap: 102396 total, 0 used, 102396 free, 119044 cached > > 2200 debian-t 20 0 168m 149m 42m R 23,4 34,5 940:35.09 tor > > This looks like my raspberry is more on idle than serving the TOR network. How can i improve this? > Bandwith limit is more than my internet connection can cover. > > Starting another tor-process? How to manage this? > Editing some Lines in the torrc-file to speed it up? > > Help is appreciated. > Kind regards, > volker > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

4 3

webiron requesting to block several /24 subnet
by Dhalgren Tor 21 Oct '15

21 Oct '15

>snake oil service like webiron A most excellent characterization! As a sales maneuver WebIron has been grandstanding for months saying that Tor operators are "unwilling to cleanup" when they know full-well that tor operators can not / should not filter traffic due to minor brute- force login attempts. For contrast, Fail2ban in 2012 was modified to silently block login attacks without spamming Tor operators in a reasonable gesture of politeness. SSH brute-force attacks have been a fact-of-life for 20 years. Hardly anyone thinks it worth the effort to spam abuse@ desks over it when a simple rate-limit does the job nicely. WebIron has become so obnoxious that Spamhaus placed their domain on the Domain Block List last Friday http://www.spamhaus.org/query/dbl?domain=webiron.com and in addition, the IP of their reporting system appears on the Spamhaus snow-shoe list and thereby on the big-bazooka Zen DNSBL. http://multirbl.valli.org/lookup/23.239.20.29.html Spamhaus is highly conservative, highly respected and only lists egregious unrepentant abusers. The only reason to comply is in deference to the overworked abuse-desk of your ISP if they do not have an automated system for dealing with this nonsense.

1 0

Optimizing TOR Relay
by Volker Mink 21 Oct '15

21 Oct '15

-now without HTML- Hi Folks. Some Stats: fingerprint: E20FF09A9A800B16C1C7C16E8C0DF95F46F649B0 cpu: 0.0% tor, 12.3% arm mem: 149 MB (34.4%) pid: 2200 cpu: 20.0% tor, 10.2% arm mem: 149 MB (34.4%) pid: 2200 load average: 0,30, 0,36, 0,33 %Cpu(s): 18,0 us, 3,1 sy, 0,0 ni, 75,3 id, 0,2 wa, 0,0 hi, 3,5 si, 0,0 st KiB Mem: 445044 total, 349348 used, 95696 free, 79872 buffers KiB Swap: 102396 total, 0 used, 102396 free, 119044 cached 2200 debian-t 20 0 168m 149m 42m R 23,4 34,5 940:35.09 tor This looks like my raspberry is more on idle than serving the TOR network. How can i improve this? Bandwith limit is more than my internet connection can cover. Starting another tor-process? How to manage this? Editing some Lines in the torrc-file to speed it up? Help is appreciated. Kind regards, volker

3 2

Re: [tor-relays] Exit policy reject fails
by spiros_spiros＠freemail.gr 20 Oct '15

20 Oct '15

Hi Josef, I think you must put any reject entries above the accept because the rules read from top to bottom. Also, I don't know if this make any difference at all, but I also put port in my torrc like this : ExitPolicy reject 195.113.0.0/16:* #comment here S On 19 Oct 2015, at 22:03, Josef Stautner <hello(a)veloc1ty.de> wrote: Hello @all, I have a probleme with an reject rule which seems to fail. Due to an message from WebIron against my exit relay I wanted to block a subnet. My exit policy looks like this: ExitPolicy accept *:53 # DNS ExitPolicy accept *:80 # HTTP ExitPolicy accept *:8080 # HTTP 2 ExitPolicy accept *:443 # HTTPS ExitPolicy reject 5.133.182.0/24 # WebIron report ExitPolicy reject *:* After I added the reject rule I reloaded tor and thought the case is done. But WebIron keeps sending me messages because of "ongoing attacks" against a host in that subnet. Of course I trusted the reject rule and ignored them. After the 6th mail I got suspicious and added an iptables ACCEPT rule in my OUTPUT chain to have a look if there is really a traffic flow. I just received another mail and checked the packet counter: Chain OUTPUT (policy ACCEPT 116M packets, 159G bytes) num pkts bytes target prot opt in out source destination 2 142 8304 ACCEPT all -- * * 31.220.45.6/32 5.133.182.0/24 /* WebIron Block check */ There is traffic flowing from my relay IP 31.220.45.6 to the subnet. Can somebody please hint me what I'm doing wrong? Link to the relay in case you need more information: https://atlas.torproject.org/#details/29E3D95332812F81F67FF31B3B1B842683D1C… Thanks in advance, ~Josef _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

3 2

Optimizing TOR-Relay
by Volker Mink 20 Oct '15

20 Oct '15

1 0

Exit policy reject fails
by Josef Stautner 19 Oct '15

19 Oct '15

Hello @all, I have a probleme with an reject rule which seems to fail. Due to an message from WebIron against my exit relay I wanted to block a subnet. My exit policy looks like this: ExitPolicy accept *:53 # DNS ExitPolicy accept *:80 # HTTP ExitPolicy accept *:8080 # HTTP 2 ExitPolicy accept *:443 # HTTPS ExitPolicy reject 5.133.182.0/24 # WebIron report ExitPolicy reject *:* After I added the reject rule I reloaded tor and thought the case is done. But WebIron keeps sending me messages because of "ongoing attacks" against a host in that subnet. Of course I trusted the reject rule and ignored them. After the 6th mail I got suspicious and added an iptables ACCEPT rule in my OUTPUT chain to have a look if there is really a traffic flow. I just received another mail and checked the packet counter: Chain OUTPUT (policy ACCEPT 116M packets, 159G bytes) num pkts bytes target prot opt in out source destination 2 142 8304 ACCEPT all -- * * 31.220.45.6/32 5.133.182.0/24 /* WebIron Block check */ There is traffic flowing from my relay IP 31.220.45.6 to the subnet. Can somebody please hint me what I'm doing wrong? Link to the relay in case you need more information: https://atlas.torproject.org/#details/29E3D95332812F81F67FF31B3B1B842683D1C… Thanks in advance, ~Josef

2 2

TCP: too many orphaned sockets
by fatal 19 Oct '15

19 Oct '15

Hello, I had to move my exit relay to another VPS due to the provider getting annoyed by the abuse mails. The new VPS has exactly the same software setup but only 512 instead of 1024 Mb RAM. Traffic was/is around 45 Mbit/s on both. On the new VPS I get the following message (from time to time lots of them): "kernel: [XXXXXX.XXXXXX] TCP: too many orphaned sockets" which I've never seen on the old VPS. Memory consumption is as follows: total used free shared buffers cached Mem: 492560 465600 26960 348 9852 74476 -/+ buffers/cache: 381272 111288 Swap: 1998844 40956 1957888 I'm unsure if I should limit the maxbandwidth in torrc or try to tune the kernel settings (like /proc/sys/net/ipv4/tcp_max_orphans /proc/sys/net/ipv4/tcp_mem) and which of them? Ordering 1024 Gb of RAM would double the cost and could be an option after I got more experience with the new provider and abuse mails. Thanks for any advice!

3 3

Re: [tor-relays] Tools for managing multiple relays
by starlight.2015q3＠binnacle.cx 19 Oct '15

19 Oct '15

>None of the above :) > >I run these three relays[1][2][3]. > >ccrelaycc [1] has acquired the guard flag in the >last few days (don't know when, last time I >checked it did not have it). This relay is rated near the boundary of minimum Guard rating and goes in and out of the state. >A thing that is bothering me is that ccrelaycc and >inara ([1] and [2] respectively) are both on >DigitalOcean, they are in two different regions >(AMS and SIN) *but*, notwithstanding that they >have an identical configuration, ccrelaycc has >been experiencing 2 TB traffic per month in the >last 3 or 4 months while inara has barely reached >100 GB per month over same period (I use vnstat >and arm for these stats), that is a 20x >difference. I would like to understand this >difference. With a VPS a tremendous number of variables are at work. How heavily loaded is the physical server with other VPS clients? What kind of NICs are present? What type of server, etc? Is not surprising at all that the QOS varies wildly. >It should be noted that both are the smallest VPS >available on DigitalOCean and that comes with 1 TB >of traffic per month but it seems that >DigitalOcean is liberal about using more bandwidth >(I have read a similar comment on this list about >DO). > >jaine is much more recent and it is on Aruba.it in >Italy. I expect that they are much less liberal >about using more bandwidth than what is allotted >so I set lower limits for the RelayBandwidhtRate >parameter. > >For ccrelaycc and inara I have set: >--- >RelayBandwidthRate 1600 KB >RelayBandwidthBurst 3200 KB >--- >and for jaine: >--- >RelayBandwidthRate 800 KB >RelayBandwidthBurst 1600 KB If you have the ability to use 'tc' instead of BandwidthRate (per posts earlier this month) you should do that. RelayBandwidth* are not intended for limiting bandwidth in dedicated relays. Replace them with BandwidthRate and BandwidthBurst if you can't use 'tc'. >--- >What I see in the end are three quite different >behaviors. Given that jaine is at the beginning of >its lifecycle I would give it some more time >before drawing any conclusions, but I would really >like to understand why ccrelaycc and inara are >behaving so differently. I would appreciate any >input on this. Per above, huge number of variables easily explain it. On top of the variability of the VPS, the networks could have dramatically different quality, reachability, loading and congestion. You can look at the individual BWauth ratings for a more complete picture. Found https://collector.torproject.org/recent/relay-descriptors/votes/ where # gabelmoo ED03BB6... Erlangen, Bavaria-DE # maatuska 49015F7... Belgium # Faravahar EFCBE72... ? # longclaw 23D15D9... Seattle, WA-US # moria1 D586D18... Cambridge, MA-US here's Blutmagie (actual bandwidth) _gfs_ ccrelaycc NL 942 98 4.27 L 95.85.8.226 443 80 95.85.8.226 __fs_ jaine IT 216 13 4.27 L 5.249.145.164 443 80 ... .aruba.it __fs_ inara SG 38 98 4.27 L 128.199.148.243 443 80 128.199.148.243 and rueckgr.at (max self-measure / advertised) _gfsh ccrelaycc NL 1987 __fsh jaine IT 999 __fsh inara GB 823 Suggest installing and running 0.2.6.10 in instead of 0.2.4.27. The Aruba dedicated Atom server discussed earlier could make a nice relay, or perhaps the next-up one for 20 euros. Perhaps try running the existing Aruba node as an exit for a month first to see how they respond. With the "reduced" exit policy the worst-case is a pile of automated complaints about WordPress brute-force login attacks. Very minor but how they respond will be telling. The exit policy can be turned off if they freak. LeaseWeb has 49 euro 100TB servers available in the Netherlands--killer exit boxes that will rate high and pull 15000 per Blutmagie. OVH has good offerings as well, including the Kimsufi subsidiary. Despite 'tor-relays' claims to the contrary, Kimsufi apparently will tolerate (at least one) exit nodes: e_fs_ Kiss208 FR 703 10 6.10 L 5.135.152.208 443 444 ks3296627.kimsufi.com e_fsh Kiss208 FR 1503 The above has been an exit for 14 months. Here's the fastest Kimsufi though this is probably a Pentium or Xeon: _gfs_ Unnamed FR 9865 61 6.10 L 91.121.82.25 443 80 ks26969.kimsufi.com _gfsh Unnamed FR 10947 ===== But an Aruba exit is perhaps a more diverse addition.

5 4

Re: [tor-relays] Tools for managing multiple relays
by starlight.2015q3＠binnacle.cx 16 Oct '15

16 Oct '15

On Thu, Oct 15, 2015 at 20:20:13 -0000, nusenu <nusenu(a)openmailbox.org> wrote: >>> LeaseWeb has 49 euro 100TB servers available >>> in the Netherlands--killer exit boxes that will >>> rate high and pull 15000 per Blutmagie. OVH has >>> good offerings as well >> >>Please consider diversity when adding relays. >> >>OVH (AS) and NL (CC) are among the worst places >>to add relays from a (simplified) diversity >>point of view. Problem is costs in Asia are like ten times costs in Europe. US is double or triple. Other locales still cost more. So is it better to run a 100TB server for $60/month in Germany or the Netherlands where privacy is a major priority, or a 1TB VPS in Singapore for $25/month? Both are presumed easily collectable by five-eyes agencies. The former provides substantial incremental usability while the cost/benefit of the latter is far less compelling. Russia, Ukraine, etc might be better in theory except they surveille too, are less constrained by law and harbor obviously dubious actors (not saying don't consider it). That many independent operators contribute is terrific for diversity in itself --perhaps the most important factor. Choices are not simple.

2 1

Re: [tor-relays] Tools for managing multiple relays
by starlight.2015q3＠binnacle.cx 15 Oct '15

15 Oct '15

_gfs_ ccrelaycc NL 942 98 4.27 L 95.85.8.226 443 80 95.85.8.226 __fs_ jaine IT 216 13 4.27 L 5.249.145.164 443 80 ... .aruba.it __fs_ inara SG 38 98 4.27 L 128.199.148.243 443 80 128.199.148.243 One likely contributor to the relatively high rating of 'ccrelaycc' is residence in the Netherlands. Central Europe Internet is the best in the world for affordable high-quality high-capacity bandwidth. This is why so many fast relays are found in the region. ----- Pulled the BWauth ratings for you. The median value is selected for the consensus weight. Results look sane. ccrelaycc 2015-10-15 17:00:00 gablemoo--w Bandwidth=1638 Measured=2930 Faravahar-w Bandwidth=1638 Measured=3010 longclaw--w Bandwidth=1638 Measured=3410 median moria1----w Bandwidth=1638 Measured=3490 maatuska--w Bandwidth=1638 Measured=3580 jaine 2015-10-15 17:00:00 maatuska--w Bandwidth=819 Measured=505 Faravahar-w Bandwidth=819 Measured=543 gablemoo--w Bandwidth=819 Measured=544 median longclaw--w Bandwidth=819 Measured=740 moria1----w Bandwidth=819 Measured=767 inara 2015-10-15 17:00:00 gablemoo--w Bandwidth=843 Measured=235 longclaw--w Bandwidth=843 Measured=330 maatuska--w Bandwidth=843 Measured=336 median moria1----w Bandwidth=843 Measured=336 Faravahar-w Bandwidth=843 Measured=1580

3 2