October 2014 - tor-relays - lists.torproject.org

onionoo backend seems to be down.
by jason＠icetor.is 21 Apr '15

21 Apr '15

Hello All, Anyone else notice onionoo and the tools that rely on it (globe.torproject.org atlas.torproject.org) seem to be down? -Jason

5 4

boost CPU on a Tor relay
by s7r 28 Dec '14

28 Dec '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, A Tor relay currently going 33MB/s could go a lot faster but CPU is at 93% usage - this is the bottleneck. Here is the output of /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz stepping : 5 microcode : 0x11 cpu MHz : 3068.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid bogomips : 6132.24 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: it also goes down to processor 1 - processor 7 Any ideas how this could be boosted? OS is Debian wheezy. No aes-ni hardware acceleration, no openssl benchmarking or customization currently. advices? Thank you. - -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUDuRTAAoJEIN/pSyBJlsRLqYH/iSCtC9r/7/DBCG2qqUGPEgY TELvt+UMGyMP6ncNJH+vDEdHO4BBlSMzFQdj2sKyO3hOT5492cIOaT3gGokaDApL W913yqUkIfiUT6FUWJ6g4/LUt25pMG25Ednr/ZJJXR/pR+Ym3T3ytg+MSwRBmpEe +h26Q7qvd/p4f6VhTR0sEsxQfDLVXrEsj3kn0BL0rLklN5zH/bqmIsK2hio5Nl3H KBvbvyt+JbLhA/4+jygT6AygHDH9arpXWEh3ZcJVn7mE0OmPAvukdlLUj70K5F7r cCeMakcGBbSzit5tY7jUmSvkUewVBhAxAZmv1hgNnuCoSrGPtQZseCbM06cry+k= =TyKF -----END PGP SIGNATURE-----

6 10

Call for obfs4 bridges, and a brief discussion of obfs4proxy.
by Yawning Angel 18 Nov '14

18 Nov '14

Hello everyone, As people who have been following Tor Weekly News or other news sources, I have been working on a new pluggable transport in the obfs-line to better allow censored users to reach the Tor network. The result, obfs4 is what I would consider ready for general deployment[0], and as part of the process there needs to be bridges for the users. To entice people to run obfs4 bridges, I would like to talk briefly about obfs4 and obfs4proxy. I am also planning on doing a blog post about obfs4 some time after I regenerate my experimental TBB snapshots. On obfs4: obfs4 is the next up and coming pluggable transport in the obfs[2,3] line, though in terms of design, a better name would be "ScrambleSuit 2". The main difference is the switch from UniformDH to ntor-with-Elligator2 for the key exchange process, which means that clients strongly authenticate the identity of the bridge (The key exchange succeeding means that the bridge possesses a Curve25519 private key that is known only to the bridge). Additionally the ntor handshake (even with the Elligator2 transform in the picture) is considerably faster than UniformDH which should increase scalability. On obfs4proxy: obfs4proxy is the current obfs4 reference implementation, written in the Go programming language. The use of Go was primarily driven by the availability of an Elligator2 implementation at the time, though it also has other practical benefits over writing it as a component of the python obfsproxy code, for example, it is trivial to run bridges listening on ports < 1024 on modern Linux systems. obfs4proxy implements support for obfs[2,3,4], as a managed tor pluggable transport (no standalone mode currently). Note that obfs2 support is for backward compatibility purposes only and it is discouraged that new obfs2 bridges are run as the protocol is trivially broken by most adversaries. In terms of code stability, we have been running one of the Tor Browser's default obfs3 bridges on obfs4proxy for quite a while with no issues. Similar to ScrambleSuit, obfs4 bridges MUST be running tor-0.2.5.x, otherwise the bridge lines that are published will be useless[1], though people that wish to run obfs3 bridges with obfs4proxy naturally can do so with tor-0.2.4.x. Source: https://gitweb.torproject.org/pluggable-transports/obfs4.git Debian packages (Thanks Lunar!): https://packages.debian.org/sid/obfs4proxy Note: I just tagged/pushed obfs4proxy-0.0.2, but the only significant change is that it is easier to get an obfs4 bridge line to give out to people as the bridge operator. I expect packages to catch up as the wonderful packager has the time. Questions, comments, and bridges appreciated, -- Yawning Angel [0]: https://trac.torproject.org/projects/tor/ticket/12130 [1]: https://trac.torproject.org/projects/tor/ticket/13202

5 12

Re: [tor-relays] BBC and UK Lottery blocking ip addresses running Tor
by Dan Hanley 13 Nov '14

13 Nov '14

Looks like the BBC have changed their rules. I am still running a relay, but can now access www.bbc.co.uk in a normal fashion. Still blocked by national lottery, but I'm hopeful that they both use the same third party ip checker, and that the next lottery update will fix the issue. On Thu, Sep 18, 2014 at 10:41 PM, <tor-relays-request(a)lists.torproject.org> 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. RELAY_EARLY tor network update status (CVE-2014-5117) (Nusenu) > 2. Re: BBC and UK Lottery blocking ip addresses running relay > (Ross Petrie) > 3. Re: BBC and UK Lottery blocking ip addresses running relay > (Chris Whittleston) > > > ---------- Forwarded message ---------- > From: Nusenu <BM-2D8wMEVgGVY76je1WXNPfo8SrpZt5yGHES(a)bitmessage.ch> > To: tor-relays(a)lists.torproject.org > Cc: markus(a)mdfnet.se, info(a)enn.lu, torpids(a)yahoo.com, nick(a)calyx.com > Date: Thu, 18 Sep 2014 21:00:41 +0000 > Subject: [tor-relays] RELAY_EARLY tor network update status (CVE-2014-5117) > (if you are on the CC list of this email you are probably one of the tor > relay operators running one of the 10 fastest vulnerable [CVE-2014-5117] > relays on the tor network. Please upgrade your tor relay) > > > The tor network is currently at 64% of the bandwidth being served by > > relays running a recommended version according to torstatus.blutmagie.de > . > > I updated a previous metrics feature request so we might see nice > > graphs about patching progress in the future [2]. > > Since we are seeing active RELAY_EARLY attacks again (or new buggy tor > implemantations) I was wondering what the current update stats look like. > > ~85%* of the tor network's bandwidth is provided by patched relays. > (~66% 0.2.4.23, ~11% 0.2.5.6-alpha, ~7% 0.2.5.7-rc) > > *) according to data from torstatus.blutmagie.de > > > 10 fastest relays still running a vulnerable version: > > > https://atlas.torproject.org/#details/EC98311F9EC02BEAA183651CE8402249CD036… > > https://atlas.torproject.org/#details/D1271A1E15C568DA709D3A1E68188EEAE8DDB… > > https://atlas.torproject.org/#details/12AD30E5D25AA67F519780E2111E611A455FD… > > https://atlas.torproject.org/#details/1B9FACF25E17D26E307EA7CFA7D455B144B03… > > https://atlas.torproject.org/#details/2F57987F3942BA0BBD706D623F1FF86A89684… > > https://atlas.torproject.org/#details/379FB450010D17078B3766C2273303C358C3A… > > https://atlas.torproject.org/#details/935BABE2564F82016C19AEF63C0C40B5753BA… > > https://atlas.torproject.org/#details/B83DC1558F0D34353BB992EF93AFEAFDB226A… > > https://atlas.torproject.org/#details/104A9453FD93BDBEAE9E2024898266AD2051A… > > https://atlas.torproject.org/#details/C11650E31F83E149C855D574B3171CC9CF9BE… > > > > > ---------- Forwarded message ---------- > From: Ross Petrie <ross.petrie(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Thu, 18 Sep 2014 22:18:05 +0100 > Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses running > relay > > Hi all, > > I've just reported this same issue this week, no reply yet. > > I can still watch catch up BBC TV through my sky box though. > On 18 Sep 2014 21:40, "Dan Hanley" <hanley.dan(a)gmail.com> wrote: > >> >>> I have just received a slightly more positive reply: >> >> "At present, our GeoIP data provider classes Tor nodes as proxies, >> regardless of whether or not they're an exit node. We understand that there >> is room for improvement in this model, since non-exit relays do not present >> traffic on behalf of other users. We have asked our provider to give us a >> way of differentiating Tor exit nodes from non-exit relays, to allow us to >> block exit nodes only." >> >> So perhaps they will make a change... certainly reporting the issue seems >> to raise its importance :-) >> >> atb >> >> Dan >> >> >> >>> >> >> 5. Re: BBC and UK Lottery blocking ip addresses running relay >>> nodes (Chris Whittleston) >>> ---------- Forwarded message ---------- >>> From: Chris Whittleston <csw34(a)cam.ac.uk> >>> To: tor-relays(a)lists.torproject.org >>> Cc: >>> Date: Thu, 18 Sep 2014 01:40:31 +0100 >>> Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses >>> running relay nodes >>> Yeah ouch - maybe I just got someone a bit more helpful. I'm with Matt >>> though, it seems like they still don't get the difference between using Tor >>> as a client and running a relay, so this isn't the end of the road there. >>> You are going to have to rely on them wanting to actually think about it >>> though. >>> >>> If all else fails, you could always try to simply report the issue again >>> using the form I linked before, but this time just don't mention Tor at all >>> and see if you get a different customer service person... >>> >>> http://iplayerhelp.external.bbc.co.uk/tv/incorrect_location_may2014 >>> >>> I suspect you'll end up having to explain that you're running a relay in >>> the end anyway, but you never know. >>> >>> Chris >>> >>> On 17 September 2014 21:48, Matt Puckey <matt(a)puckey.org> wrote: >>> >>>> Stephen Mollett: >>>> > [...] >>>> > "Thank you for contacting the BBC iPlayer support team. >>>> > >>>> > "I understand you’re experiencing problems accessing BBC iPlayer as >>>> > you’re told that you are outside of the UK. >>>> > >>>> > "Please note that if you run TOR, then I’m afraid as per our >>>> development >>>> > team’s confirmation you’ll not be able to access BBC iPlayer. If you >>>> > continue to use TOR then your IP address may be blacklisted against UK >>>> > only services across bbc.co.uk." >>>> > >>>> > I made a point of stating explicitly in my original case filing that I >>>> > run a middle relay and that no traffic exits from my node to the BBC's >>>> > website or to anywhere else, along with a link to my node's stats on >>>> > blutmagie confirming the (non-)exit policy. >>>> > [...] >>>> >>>> Hi Stephen, >>>> >>>> I'm not sure whether I'm surprised at the BBC or not! >>>> >>>> It is a shame if they seem to be doing blanket blocking of Tor relay IP >>>> addresses. I suppose this >>>> ( >>>> https://blog.torproject.org/blog/call-arms-helping-internet-services-accept… >>>> ) >>>> has /some/ relevance. >>>> >>>> The problem is obviously convincing a organisation like the BBC to treat >>>> individual IP addresses different from other Tor relay IP addresses (and >>>> whether they should be doing that at all). Although it seems Chris >>>> Whittleston obviously managed it! Maybe you simply got 'the wrong person >>>> at the other end'. Personally, I would continue to pursue this with >>>> them! >>>> >>>> --Matt >>>> >>>> >>>> >>>> _______________________________________________ >>>> tor-relays mailing list >>>> tor-relays(a)lists.torproject.org >>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>>> >>> >>> >>> >>> -- >>> *Dr Chris Whittleston 栗主* >>> Department of Chemistry >>> University of Cambridge >>> Lensfield Road, Cambridge, CB2 1EW >>> Email: csw34(a)cam.ac.uk >>> Tel: +44 (0)1223 336423 >>> >>> _______________________________________________ >>> tor-relays mailing list >>> tor-relays(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >>> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> > > ---------- Forwarded message ---------- > From: Chris Whittleston <csw34(a)cam.ac.uk> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Thu, 18 Sep 2014 22:41:04 +0100 > Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses running > relay > > That's great news Dan, keep us posted! > > Chris > On 18 Sep 2014 21:40, "Dan Hanley" <hanley.dan(a)gmail.com> wrote: > >> >>> I have just received a slightly more positive reply: >> >> "At present, our GeoIP data provider classes Tor nodes as proxies, >> regardless of whether or not they're an exit node. We understand that there >> is room for improvement in this model, since non-exit relays do not present >> traffic on behalf of other users. We have asked our provider to give us a >> way of differentiating Tor exit nodes from non-exit relays, to allow us to >> block exit nodes only." >> >> So perhaps they will make a change... certainly reporting the issue seems >> to raise its importance :-) >> >> atb >> >> Dan >> >> >> >>> >> >> 5. Re: BBC and UK Lottery blocking ip addresses running relay >>> nodes (Chris Whittleston) >>> ---------- Forwarded message ---------- >>> From: Chris Whittleston <csw34(a)cam.ac.uk> >>> To: tor-relays(a)lists.torproject.org >>> Cc: >>> Date: Thu, 18 Sep 2014 01:40:31 +0100 >>> Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses >>> running relay nodes >>> Yeah ouch - maybe I just got someone a bit more helpful. I'm with Matt >>> though, it seems like they still don't get the difference between using Tor >>> as a client and running a relay, so this isn't the end of the road there. >>> You are going to have to rely on them wanting to actually think about it >>> though. >>> >>> If all else fails, you could always try to simply report the issue again >>> using the form I linked before, but this time just don't mention Tor at all >>> and see if you get a different customer service person... >>> >>> http://iplayerhelp.external.bbc.co.uk/tv/incorrect_location_may2014 >>> >>> I suspect you'll end up having to explain that you're running a relay in >>> the end anyway, but you never know. >>> >>> Chris >>> >>> On 17 September 2014 21:48, Matt Puckey <matt(a)puckey.org> wrote: >>> >>>> Stephen Mollett: >>>> > [...] >>>> > "Thank you for contacting the BBC iPlayer support team. >>>> > >>>> > "I understand you’re experiencing problems accessing BBC iPlayer as >>>> > you’re told that you are outside of the UK. >>>> > >>>> > "Please note that if you run TOR, then I’m afraid as per our >>>> development >>>> > team’s confirmation you’ll not be able to access BBC iPlayer. If you >>>> > continue to use TOR then your IP address may be blacklisted against UK >>>> > only services across bbc.co.uk." >>>> > >>>> > I made a point of stating explicitly in my original case filing that I >>>> > run a middle relay and that no traffic exits from my node to the BBC's >>>> > website or to anywhere else, along with a link to my node's stats on >>>> > blutmagie confirming the (non-)exit policy. >>>> > [...] >>>> >>>> Hi Stephen, >>>> >>>> I'm not sure whether I'm surprised at the BBC or not! >>>> >>>> It is a shame if they seem to be doing blanket blocking of Tor relay IP >>>> addresses. I suppose this >>>> ( >>>> https://blog.torproject.org/blog/call-arms-helping-internet-services-accept… >>>> ) >>>> has /some/ relevance. >>>> >>>> The problem is obviously convincing a organisation like the BBC to treat >>>> individual IP addresses different from other Tor relay IP addresses (and >>>> whether they should be doing that at all). Although it seems Chris >>>> Whittleston obviously managed it! Maybe you simply got 'the wrong person >>>> at the other end'. Personally, I would continue to pursue this with >>>> them! >>>> >>>> --Matt >>>> >>>> >>>> >>>> _______________________________________________ >>>> tor-relays mailing list >>>> tor-relays(a)lists.torproject.org >>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>>> >>> >>> >>> >>> -- >>> *Dr Chris Whittleston 栗主* >>> Department of Chemistry >>> University of Cambridge >>> Lensfield Road, Cambridge, CB2 1EW >>> Email: csw34(a)cam.ac.uk >>> Tel: +44 (0)1223 336423 >>> >>> _______________________________________________ >>> tor-relays mailing list >>> tor-relays(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >>> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >

4 4

Windows Tor Server Guide
by Rafael Rodriguez 10 Nov '14

10 Nov '14

Hello fellows, Where can we contribute (post a guide) to deploy Tor in Windows without the extras unneeded stuff? I was looking for a Tor Server installation guide on Windows to run Tor as a service. I did not wanted to install all the extra browser stuff but a plain "Tor server" service and secure it by giving the service its own limited account and write permissions just to the datadir. Since I couldn't find information online to help me out, I ended up using the latest Tor Browser package and removing everything except Tor itself and deployed it in two Windows servers as services. I would like to post somewhere in the Top project about the process for others to benefit from it.

4 6

Re: [tor-relays] upgrade tor bridge raspberry-pi
by jchase 31 Oct '14

31 Oct '14

> On Thu, Oct 30, 2014 at 08:30:31PM +0000, jchase wrote: >> On hearing the news that tor 0.2.5.10 was available, I upgraded my >> raspberry-pi tor (obfuscated bridge) to 0.2.4.something. The upgrade >> restarted the tor daemon automatically. I would have rather done it >> myself using a restart. When I used arm to look at my new traffic, I >> noticed that I had been magically turned into an exit relay (besides >> staying a bridge). My torrc was still intact and clearly stated: >> ExitPolicy reject *:* >> I restarted tor by hand and got the same result. I am not interested in >> having an exit relay. So I turned off the bridge and am waiting for >> advice from you. >> rasptorholland > > Is it possible you are being bitten by this arm bug? > > https://trac.torproject.org/projects/tor/ticket/12956 > https://trac.torproject.org/projects/tor/ticket/6430 > > --Roger Thanks! I will assume I was bitten by an arm bug and turn everything on again until the police come to look for me. -rasptorholland

1 0

upgrade tor bridge raspberry-pi
by jchase 31 Oct '14

31 Oct '14

Hello, On hearing the news that tor 0.2.5.10 was available, I upgraded my raspberry-pi tor (obfuscated bridge) to 0.2.4.something. The upgrade restarted the tor daemon automatically. I would have rather done it myself using a restart. When I used arm to look at my new traffic, I noticed that I had been magically turned into an exit relay (besides staying a bridge). My torrc was still intact and clearly stated: ExitPolicy reject *:* I restarted tor by hand and got the same result. I am not interested in having an exit relay. So I turned off the bridge and am waiting for advice from you. rasptorholland

3 2

Choosing to run vanilla or obfuscated bridge
by eliaz 29 Oct '14

29 Oct '14

I know that vanilla bridges cannot carry obfsproxy traffic. But can obfsproxied bridges carry vanilla traffic? If not, are there criteria to help me decide which bridge configuration is useful at any particular time? - eliaz

3 2

exit node experience: abuse over HTTP, stealrat infection
by Kees Goossens 29 Oct '14

29 Oct '14

Dear all, I’ve been running tor non-exit relay freshhumbug at torrelay.nl <http://torrelay.nl/> for about 3 months now. Recently, I tried running it as an exit relay for a week, with following interesting results. Set up: - Ubuntu 14.04 running as VPS with transip.nl <http://transip.nl/>, latest release version of Tor - bandwidth rate set to between 1 MB/s and 2 MB/s - VERY reduced exit policy (listed below) Part 1: Abuse over HTTP. Within one week of being an exit, my provider forwarded the following abuse notification to me (XXXX is the abused Russian website, ZZZZ is me): ==== Greetings, XXXX abuse team like to inform you, that we have had mass bruteforce attempts to the Joomla / WordPress control panel on the our shared-hosting server XXXX from your network, from IP address ZZZZ During the last 30 minutes we recorded 333 attempts like this: XXXX - [14/Oct/2014:14:17:49 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:49 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:51 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:51 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-“ XXXX - [14/Oct/2014:14:17:54 +0400] "POST /administrator/index.php HTTP/1.1" 499 0 "-" "-" ==== Lesson (for me at least): since HTTP was used, even a very reduced exit policy is does not make one immune to abuse problems. At this point I reverted back to being a non-exit relay, as I have no interest in having to deal with this. Part 2: Stealrat infection. As part of being an exit relay, I set reverse DNS to this-is-a-tor-exit.torrelay.nl <http://this-is-a-tor-exit.torrelay.nl/>, and I displayed the this-is-a-tor-exit-node.html web page on port 80, using the DirPortFrontPage option. A few days after having shut down my exit, I received notification from my provider that they have been told that my IP address was infected with Stealrat. It hosted a Stealrat PHP file, used to send spam. - http://blog.trendmicro.com/trendlabs-security-intelligence/compromised-site… <http://blog.trendmicro.com/trendlabs-security-intelligence/compromised-site…> - http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white… <http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white…> However, the only thing I do with my VPS is run tor. I don’t run a web site, and don’t have apache or whatever installed. I didn’t investigate much further, but my hypothesis is that when publishing the tor-exit notice on port 80 either tor internally uses a web server or enables a web server that’s present in the system. Either way, that webserver was hacked through a PHP hack. (Note that I received the Stealrat notification only after stopping my exit node. I’m not sure if the Stealrat hack was still active or not. I couldn’t find relevant PHP files on my system.) Since I didn’t want to spend time or effort (figuring out how to) clean my system, I reinstalled ubuntu & tor (only ~40 min work anyway). Lesson (for me): using the DirPortFrontPage option opens up an unexpected web server vulnerability. Perhaps this information is useful for others. With best regards, Kees Relevant parts of the torrc: ORPort 9001 # port used for relaying traffic DirPort 80 # port used for mirroring directory information - not used, since have accountingmax SocksPort 0 # prevents tor from being used as a client RelayBandwidthRate 1000 KB # limit for the bandwidth we'll use to relay RelayBandwidthBurst 10 MB # maximum rate when relaying bursts of traffic BandwidthRate 1000 KB # same as RelayBandwidthRate BandwidthBurst 10 M # same as RelayBandwidthBurst DirPortFrontPage /home/administrator/.arm/this-is-a-tor-exit.html ExitPolicy accept *:20-23 # FTP, SSH, telnet ExitPolicy accept *:43 # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79-81 # finger, HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # kpasswd ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy accept *:563 # NNTP over SSL ExitPolicy accept *:636 # LDAP over SSL ExitPolicy accept *:749 # kerberos ExitPolicy accept *:981 # Remote HTTPS management for firewall ExitPolicy accept *:989-995 # FTP over SSL, Netnews Administration System, telnets, IMAP over SSL, ircs, POP3 over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept *:1293 # PKT-KRB-IPSec ExitPolicy accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy accept *:5222-5223 # XMPP, XMPP over SSL ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC SSL ExitPolicy accept *:8008 # HTTP alternate ExitPolicy accept *:8080 # HTTP Proxies ExitPolicy accept *:8082 # HTTPS Electrum Bitcoin port ExitPolicy accept *:8332-8333 # Bitcoin ExitPolicy accept *:8443 # PCsync HTTPS ExitPolicy accept *:8888 # HTTP Proxies, NewsEDGE ExitPolicy accept *:9418 # git ExitPolicy accept *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept *:50002 # Electrum Bitcoin SSL ExitPolicy reject *:*

15 29

Re: [tor-relays] How many IOERRORs are common ?
by Mike Patton 29 Oct '14

29 Oct '14

On 29/10/2014 5:23 am, =?ISO-8859-1?Q?Toralf_F=F6rster?= <toralf.foerster(a)gmx.de> wrote: > > Watching the status of a tor-relay (4 MB bandwith, guard + exit, having more than open 1000 connections) with arm shows a rather high frequent amount of connection errors. Nearly every seconds or so a connection can't be established. > > /me just wonders if this is common (replaced ip addresses with <XXXXXX>) > My exit isn't the size of yours but at times has supported quite a bit of traffic and I haven't ever seen one of these errors. Rgds, M.

3 3