- tor-relays - lists.torproject.org

State of the art in NAT busting?
by Gordon Morehouse 20 Sep '13

20 Sep '13

I have a question which relates to my ongoing groundwork to build a Raspberry Pi (and hopefully Beagle and Cubie) friendly set of Debian packaged programs which can turn one of these small, low-power machines into a plug n' forget Tor relay. What is the start of the art in NAT hole punching if one does not have a UPnP or (other-standard-mumble) compliant router? If I'm behind such a router, what's the best I can do to help the Tor network if, for any reason, the user is unable to port forward? Sub-questions: 1. What's the best I can do without any outside help? 2. What's the best I can do with minimal outside help, e.g. STUN+ICE, TURN, etc? Does Tor itself support any of those? Could a Tor relay or bridge + not-yet-written scripts make use of those? 3. Are there any options I'm forgetting to consider, other than wholesale relaying of traffic (eg IP_A:portN -> hole-punched NATed Tor instance where IP_A is another machine handling some or all of the NATed relay's traffic)? Best, -Gordon M.

1 0

Re: [tor-relays] Reimbursement of Exit Operators
by tor＠t-3.net 20 Sep '13

20 Sep '13

Think bigger, say what? Certain of the world's biggest and most well-funded intelligence agencies hate personal privacy on the internet so much that they've been going to extreme efforts to destroy it. They are packet sniffing the NAPs and fiber backbones to pull out everything they can, they hacked/broke HTTPS, they are backdoored into the big content providers, they hacked the banking system, they are apparently 'in' some hardware crypto chips - the list goes on - They infiltrated the tech groups which were designing software and hardware and sabotaged their work, making their crypto be weaker/breakable and their systems easier to hack into. They use the vulnerabilities they created to their own ends. As of today, Tor appears to provide privacy, at least as far as the .onion sites goes. Maybe it even works for it's entire function of providing anonymous internet browsing. 'They' would definitely want to be IN this thing, because they either want to compromise it, or if that doesn't work well enough, destroy it. 'They' are known to infiltrate and be influential in getting what they want. Literally, they are professionals at this. 'Getting to know' the exit relay operators and identifying their bank accounts would help facilitate things when it came time for them to make their move. In the context of September 2013, this whole thing is scary. It was perhaps not scary in September of 2012, when we didn't know anything. Also. It makes me wonder things when, for example, you say "Think bigger" while pointing to a couple of potential dollars in someone's pocket. Safeguarding the operators of the exit relays is a bigger deal than chump change. I'm not making an honest accusation but, to the people who are the most vocal in approving of this - you don't work for the NSA, right? :) On Wednesday 18/09/2013 at 6:08 pm, Roger Dingledine wrote: > On Wed, Sep 18, 2013 at 08:10:25AM -0400, tor(a)t-3.net wrote: >> >> The Wau Holland Foundation can currently only >> reimburse via wire transfer. >> >> This seems to be end-of-story in terms of who, in the end, is >> ultimately getting liability/risk, and points to practically no >> chance at anonymity > > Think bigger --

8 9

Re: [tor-relays] Reimbursement of Exit Operators
by tor＠t-3.net 20 Sep '13

20 Sep '13

The OP I saw said: The Wau Holland Foundation can currently only reimburse via wire transfer. This seems to be end-of-story in terms of who, in the end, is ultimately getting liability/risk, and points to practically no chance at anonymity within our currently hacked banking system. It's not related to taxation or what organization may or may not be trusted. It's about what information is being gathered from the system by 3rd parties for possible use tomorrow. There's another perspective to this as well. Speaking objectively and without knowledge of the organization involved, and nothing personal intended. It may be worth noting that certain presumably-Tor-hostile and well-funded agencies are known to infiltrate the tech organizations/efforts which they wish to weaken, and influence them from the inside. In this context, seeing Tor's exit node operators being offered cash via bank transfer is waist-deep into creepy. On Wednesday 18/09/2013 at 7:38 am, Tom Ritter wrote: > create or work with a trusted organization who is willing to shoulder > liability, risk, and expense of investigating the legality and tax > consequences, and then actually executing, reimbursing people through > anonymous means.It's not easy. May not even be possible. But there is > a rigid but not inflexible framework of tax law that must be worked > within. > IMO, this is net gain. Excited to see it happen, and congrats to all > whose hard work has brought it here. > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

5 4

Re: [tor-relays] 0.2.4.17-rc on Pi, a couple weeks on
by Joshua Datko 20 Sep '13

20 Sep '13

Just for comparison sake, I'm running a relay on the BeagleBone Black, running Ubuntu (raring), and Tor 0.2.4.17-rc with the following log entries: Sep 19 16:16:40.000 [notice] Circuit handshake stats since last time: 16771/16781 TAP, 13/13 NTor. Sep 19 17:16:40.000 [notice] Circuit handshake stats since last time: 17229/17240 TAP, 14/14 NTor. Sep 19 18:16:40.000 [notice] Circuit handshake stats since last time: 17371/17385 TAP, 13/13 NTor. Sep 19 19:16:40.000 [notice] Circuit handshake stats since last time: 17084/17099 TAP, 17/17 NTor. Sep 19 20:16:40.000 [notice] Circuit handshake stats since last time: 16694/16702 TAP, 13/13 NTor. Sep 19 21:16:40.000 [notice] Circuit handshake stats since last time: 17380/17382 TAP, 20/20 NTor. Sep 19 21:16:45.000 [notice] Heartbeat: Tor's uptime is 11 days 18:00 hours, with 715 circuits open. I've sent 221.93 GB and received 225.81 GB. Sep 19 21:16:45.000 [notice] Average packaged cell fullness: 87.388% Sep 19 21:16:45.000 [notice] TLS write overhead: 8% I currently have the Fast, Guard, Named, Running, Stable and Valid flags. I initially had a "your computer is too slow" message and then I set MaxAdvertisedBandwidth to 200KB and it's be better since. CPU usage is about 70%. The BBB actually has an AES crypto accelerator, but I don't think it's being used and I'm trying to work through that at the moment. Lastly (an somewhat related), I submitted a workshop proposal to 30C3 called "Using the BeagleBone for Fun and Privacy" to talk about BeagleBone hacking and running Tor. I won't find out if it's accepted until November... Josh

1 0

0.2.4.17-rc on Pi, a couple weeks on
by Gordon Morehouse 19 Sep '13

19 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hey folks, Here are my reports. First the good news: it's WAY more stable. Then the bad news: it still gets OOM-killed once in a while, possibly preventably. THE GOOD (notes from September 14): Here's my Pi relay since compilation of 0.2.4.17-rc: Sep 14 11:50:59.000 [notice] Circuit handshake stats since last time: 13308/13324 TAP, 22/22 NTor. Sep 14 11:51:51.000 [notice] Heartbeat: Tor's uptime is 7 days 18:00 hours, with 434 circuits open. I've sent 42.85 GB and received 34.05 GB. Sep 14 11:51:51.000 [notice] Average packaged cell fullness: 98.369% Sep 14 11:51:51.000 [notice] TLS write overhead: 9% That low NTor number is depressing. That high TAP number is scary. TAP is the old way and the way the botnet is using. NTor is post-0.2.4.8, I think. The replay has settled into a fairly steady state (after losing its flags except Named) of sending 5-10KB more per sec than it gets. I have a feeling this is literally due to the TAP replies being bigger than the TAP requests. It's handling tens of thousands every 6 hours. Load average is steadyish at 0.7. Unlike its predecessor, though, it's not yet crashed under the new network conditions. ...By last night (18 Sept) it had settled in to no Stable flag, but forwarding an essentially random amount of traffic that looked similar minute-to-minute. Load was between 0.9 and 1.1 with tor, top, and nload being really the only active processes. There is still room for tuning with the Pi given that this load was attained relaying about 2Mbps when I looked. THE BAD: This morning: Sep 18 04:50:59.000 [notice] Circuit handshake stats since last time: 34818/41100 TAP, 50/52 NTor. Sep 18 05:30:43.000 [warn] Your system clock just jumped 101 seconds forward; assuming established circuits no longer work. The system clock thing is a Pi thing. I'm pretty sure I need to get much more aggressive with ntpd. (Pis have no battery backup and tend to have pretty bad clock drift.) But then, 2 minutes later: Sep 18 05:32:20 tulameen kernel: [2188444.188460] Out of memory: Kill process 7544 (tor) score 148 or sacrifice child Sep 18 05:32:20 tulameen kernel: [2188444.188475] Killed process 7544 (tor) total-vm:153352kB, anon-rss:115156kB, file-rss:36712kB Coincidence? Bug? Smells like the latter. Shouldn't Tor be shedding memory if it closes all its circuits, not acquiring more? Best, - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSOa+yAAoJED/jpRoe7/ujs4UH/iXK4+hAAk06nYUptKChGRyx boZxDxpNum4uEzkJNZlUdvUILuVLX2DXytN7kNJUKDYKGzwCwBhhcQ7tOyBFucz+ muVcbwgyjM8zDhMFexWX8wVh7lauJRpjcNxzE+5hVRkzMFrbGy7FLXZbTiNGT5Ez cSfZAziu0Au3OKhxLQMUdYiZtfi/b/ReMIx72Xz4pBX4hPiagORG5NPgKpNzeBij C+khy5up1WuE7qxGX8+zG1T6K0whAW6MFYKdIT63GlwVWzYAP7tZDbbQd3kB46Yd e5I+ySBGL7VnOzH6CQl+2l1enu87JDyZ1Hw6zkZp3GQ6u8ThiHQQvmNQx9N3rxQ= =sx6s -----END PGP SIGNATURE-----

4 8

Tor Relay getting "Failed to terminate process with PID" messages
by Michael Gorbach 19 Sep '13

19 Sep '13

Hi, I started up a Tor relay several days ago, and the usage seems to be ramping up nicely. However, I am seeing some unexpected messages like this, in ARM and in the tor log files: 17:21:56 [NOTICE] Failed to terminate process with PID ‘29778' They seem to be showing up, reliably, every 5 minutes or so. Each has a different PID. What’s strange is that these PIDs don’t exist by the time I see the message, i.e. I guess whatever process had that PID is now dead. Anyone know what could be causing this? Should I be concerned, or is this some kind of artifact of my setup or software? The machine is a modern Gentoo linux install running a 3.10 kernel and Tor 0.2.3.25 (running inside VMWare). Thanks in advance for your help. Yours, ~ M.

2 4

Too little traffic on my #2 non-exit relay
by Christian Dietrich 19 Sep '13

19 Sep '13

Hey there, I'm currently running two tor (non-exit) relays on one host machine. "000000000000myTOR1" and "000000000000myTOR2". Now my problem is that tor relay #2 generates almost no traffic. https://atlas.torproject.org/#search/000000000000myTOR Log Relay #1: Circuit handshake stats since last time: 1566234/14743525 TAP, 10428/10433 NTor. Heartbeat: Tor's uptime is 7 days 6:00 hours, with 56008 circuits open. I've sent 2167.46 GB and received 1567.97 GB. Log Relay #2: Circuit handshake stats since last time: 63/63 TAP, 1/1 NTor. Heartbeat: Tor's uptime is 7 days 6:00 hours, with 4 circuits open. I've sent 1.58 GB and received 844.66 MB. Both have the same binary and configuration (except incoming/outgoing IPv4). I've also tried to switch from "fully self compiled debian, with custom kernel, and own tor binary" to "Out of the Box Ubuntu LTS, with torproject tor package" .. without any improvement. Both relays works as expected. OT: for my opinion avg 150 mbit/s (99% done by node #1) is too less for an Ivy-Bridge Based Xeon Quad Core (/w HT) on an unshared gigabit line. Apart from the fact that multithread support is really missing. Can anyone give me a hint, or am i just too stupid? Thanks ;)

4 8

Re: [tor-relays] Reimbursement of Exit Operators
by tor＠t-3.net 18 Sep '13

18 Sep '13

It's a little old. Posted July 24, 2012 We knew a lot less on that date. On Wednesday 18/09/2013 at 3:08 pm, Andrew Lewman wrote: > On Wed, 18 Sep 2013 13:36:39 -0400 > Rick <rerushg(a)gmail.com> wrote: > >> >> Nope, I don't think so. Perhaps it's the timing. In this post-Snowden >> period most everything is a little bit creepy. There's plenty of FUD >> to go around. A position paper from Torproject on this and other >> recent issues would be handy about now. > > Does this qualify as a position paper? > https://blog.torproject.org/blog/turning-funding-more-exit-relays > > -- > Andrew > http://tpo.is/contact > pgp 0x6B4D6475 > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Reimbursement of Exit Operators
by Moritz Bartl 18 Sep '13

18 Sep '13

Hi, tl;dr: We want to start reimbursing exit operators end of this month. Partner orgs, please sign the contract! Everyone else, consider becoming a partner. --- In July last year, Roger announced that BBG was interested in funding fast exits. [1] The initial discussion on the mailing list continued into August. If you're interested, you should consult the archive for the various points raised. Since then, we've been discussing that topic on and off. It matched with my plans to turn torservers.net into a platform for many organizations, instead of just one single entity that runs too many exit relays, so I agreed to take the lead. I posted a status report of some sort on this list in April this year. [2] The Wau Holland Foundation agreed to be one of the organizations willing to handle the money and pass it on to other entities, be it single operators or organizations. Both Torproject and Wau Holland Foundation checked with their lawyers to see if this turns into a problem about liability, and it looks like it does not. We're open for more organizations to join in to manage the reimbursement process, but this is what we've got for now. In parallel, we've seen a growing number of organizations that were created to turn donations into exit bandwidth. [3] Two issues with reimbursements, that were also mentioned in Roger's initial posting, are that (1) you don't want to drive away all the volunteers, and (2) you don't want to become dependent on (a single or a handful of) sponsors. These are difficult issues, and I want to strongly encourage everyone to keep contributing to the network. We really need you, and we need more of you! The second issue, dependence on funders, is on the one hand a harder one, but on the other hand (in my opinion) a less relevant one. If structures die and nodes have to be shut down because a funder backs off, so be it. We hopefully don't change the picture too much in comparison to the "unfunded times of today". The reimbursement process does not guarantee a money stream, and the amounts are set on a month-to-month basis, to encourage recipients to plan only short-term, and only make contracts based on the money they have, disregarding what they may or may not receive in the future. The current "bucket" is the one-time BBG money, and it currently does not look like they will restock it. It might sound scary, but to satisfy the tax authorities (and to show that it is a [hopefully] fair and transparent process), the Wau Holland Foundation needs to have partners sign a contract. The contract does not limit the partners abilities or restrict what they do, it only defines the reimbursement process. The way we want to start doing it now is not set in stone, and hopefully now that we finally start handing out money it will encourage further discussion around it. We want to refine the process over time, but it looks like we just have to try with what we have now and learn from our mistakes. Please don't be too hard with your criticism or you will emotionally hurt me. I'm all ears. :-) We want to reimburse based on the throughput per exit relay and organization. To strengthen network diversity, we came up with the plan to also factor in the location of the relays. There is a maximum amount any entity can receive so we hopefully don't grow big monsters. The contract [4] specifies that there is a monthly amount, currently set to $3500, split amongst all recipients (whom I started calling "torservers partners"). The recipient share is calculated from the throughput per relay * country factor, and the maximum amount per month per partner is 500 Euro. The Wau Holland Foundation can currently only reimburse via wire transfer. The country factors can change over time, and are currently derived from the total exit probability of that country. We can and should refine this. Changes of these factors do not require new contracts. Note that since the total amount of $3500 will be handed out every month, as long as we have less than 6 entities signing the contract, each entity will receive their maximum share of 500 Euro. I don't really like the idea of a fixed monthly total handed out like that, but that's what the lawyers and tax authorities signed off for Wau Holland Foundation. It seems to be costly to re-evaluate such contracts, so this is what we will stick to for now via WHF. Technically, the monthly shares and the country factors are calculated using a tool written by Lunar^^ (big thanks!). [5] You can find an example report at [6] (not the correct numbers, but you'll get the idea). This monthly report will be sent to all partners, and once they signed the contract they will simply get their monthly share. As stated at the top, we want to start reimbursing this month. Please let me know if you have any questions. We have a mailing list that is public and read-only where we send important announcements, and require every participant to be on and actually read. We have another mailing list that is also read-only for the public, but people of the participating organizations can post and discuss everything around Torservers.net and reimbursements. [7] The process to become a "partner" for now requires that I "know you". So, if you're interested in becoming a partner, start social interaction with me. I see that as a bad bottleneck, and I hope we can somehow get rid of it in the future. I generally prefer "organizations" over single persons, because (1) in most countries it seems to be really inexpensive and easy to set up organizations and (2) the process of setting up such entities includes that you gather enough people around you, so chances are you will continue even if one of you drops out. If you want to discuss, I prefer the tor-relays mailing list and our IRC channel, #torservers on irc.oftc.net. I also explicitly want to invite every partner to join that channel. --Moritz [1] https://lists.torproject.org/pipermail/tor-relays/2012-July/001433.html [2] https://lists.torproject.org/pipermail/tor-relays/2013-April/001996.html [3] http://www.torservers.net/partners.html [4] [fill out + send back via pgp-encrypted and signed mail to me] plain: https://www.torservers.net/misc/2013-07-19_TorExit_en.txt fancy: https://www.torservers.net/misc/2013-07-19_TorExit_en.ott german: https://www.torservers.net/misc/2013-07-19_TorExit_de.ott [5] git clone https://people.torproject.org/~lunar/exit-funding.git [6] https://www.torservers.net/misc/reimburse-output-2013-07.txt (set encoding to Unicode) [7] https://lists.torproject.org/pipermail/tor-relays/2013-May/002138.html

6 6

Traffic shaping on exit nodes (appeasing automated network monitoring systems)
by Philip Paeps 17 Sep '13

17 Sep '13

I had a less-than-amusing conversation with my ISP this week about how my Tor exit node was performing "network scans". As far as I can tell, their definition of "network scan" comprises anything from "knocking on the same port on every machine in a /8" to "creating lots of legitimate connections to the same port in a /8". Obviously, their network monitoring system is too trigger-happy, but there is nothing I can do about that. Do other relay operators have traffic-shaping solutions that make legitimate (and not-so-legitimate) Tor traffic look less like network abuse? I've reconfigured my exit to be a non-exit for the time being. I'm more than happy to be an exit (and field genuine abuse complaints), but I'd prefer not to trigger automated network abuse monitoring systems (too often). Any tips? My node is running FreeBSD with ipfw and dummynet, if someone happens to have ready to copy/paste settings. ;-) Philip -- Philip Paeps Senior Reality Engineer Ministry of Information

1 0

Creating circuits to myself?
by Niles Rogoff 16 Sep '13

16 Sep '13

I was using arm when I noticed this line: 173.79.154.243 --> 173.79.154.243 (us) Purpose: Ags=is_internal,need_capacity, Circuit ID: 5 4.0m (CIRCUIT) That's my IP, and it showed the exit node as the same as my node. There are currently three circuits both originating *and* exiting at my node. I am using Tor 0.2.3.25 (recommended) on Windows 7. My fingerprint is 1E598CDB9BBC751D753146D880B326952886D73B

2 2

tor bridge
by 封添 15 Sep '13

15 Sep '13

i'm tian.please give me list of tor bridge .

2 1

Appropriate bandwidth limits for my home relay
by Nick 15 Sep '13

15 Sep '13

Hi all, After running my relay for a bit on my home connection I found that Tor would happily consume all the bandwidth available, which (coupled with the number of connections overwhelming my home router, I suspect) caused my internet connection to be unusable for other things. So I set the RelayBandwidthRate and RelayBandwidthBurst values to 20 KBytes, as 20KBytes/s is a reasonable amount of bandwidth I can spare (total upload bandwidth on the connection is around 50KBytes/s). However now atlas.torproject.org shows an average of only around 0.5 - 1.5 Kbytes/s usage, and says the advertised bandwidth is 10 Kbytes/s. Should I increase the RelayBandwidthRate value to more than I can comfortably provide, on the basis that it isn't likely to all be used? Or should I just relax and let the network use my relay as little as it likes? Sometime quite soon my home internet connection will get much faster; I'm aware the relay is of questionable value at present bandwidth levels, but they should increase in not too long. Thanks, Nick

2 2

Relay
by Jonathan W 15 Sep '13

15 Sep '13

I am about to run a relay, but I don't want it using more than 1000GB a month. I prefer to manage this using the *BandwidthRate** *but I don't know the math* *to constrain it over a 1000GB a month. * * I also want to relay the directory. Is there a way to also use vidalia to interface? I'll be relaying on a linux (ubuntu) server remotly, and I'm using a windows system to set it all up. I'll be using SSH to shell in, but I'd love to use vidalia. Thanks, Jon

4 7

How to add the MyFamily line.
by Ignoramus Americanus 14 Sep '13

14 Sep '13

Would someone spell out how to include the MyFamily comment in the torrc file, please? What is needed more? Exits, bridges, non-exit relays or hidden bridges? -- Ignoramus Americanus ignoramus(a)operamail.com -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again

4 4

Re: [tor-relays] tor-relays Digest, Vol 32, Issue 29
by rotpoison throngnet 14 Sep '13

14 Sep '13

Hey guys - I have been tracking the clickfraud botnet that is hitting exposed Privoxy service on Tor exit nodes since early this year. I call it Rotpoi$on, and recently I have been working with at least one of the security teams for the advertisement networks being leveraged for the clickfraud, as my time allows. You can read more about some collective findings on Rotpoi$on here: https://b.kentbackman.com/tag/rotpoion FYI, LUDICROUS2U is my Tor exit node. I started purposely running Tinyproxy on port 8118, configured such that it will forward directly to the advertiser networks with a specific markup indicating fraud as well as the original client IP in the X-header. Now, if every exit relay operator that has a Tor-injecting Privoxy service open instead replaced it with a similar "tainted" proxy on port 8118, it might quickly reduce the attractiveness of exit relays for "fraud service" by the Rotpoi$on throngnet. Recently I changed my exit relay IP address and for a week now Rotpoi$on hasn't hit. I have changed my IP address at least a dozen times over the last year. The time that it takes for my exit relay to again be hit on port 8118 (at times additionally 3128--Squid port) has varied considerably. This makes me think that the perpetrators are more or less manually adding the list of exit relays into their click fraud operation (script?). For a while I was under the presumption that the massive uptick of Tor clients as recently announced by the Tor Project was sign that the Rotpoi$on perpetrators were starting to inject their fraudulent clicks into Tor the "legitimate" way, meaning with a Tor client. This corresponded with a reduction in port 8118 hits to my exit relay. But alas, communication with one of the advertisement network security reps does not suggest a massive corresponding increase in click fraud originating from Tor exit relays in general. So I am at a loss how to explain exactly what is going on, other than the fact that the perpetrators are still paying for a lot of leased Windows servers whose actual effectiveness at generating a significant clickfraud revenue streams seems limited and even silly, according to some other researcher's comments. On Sat, Sep 14, 2013 at 2:00 AM, <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. Tor 0.2.4.17-rc on arch armv6 (Lukas Erlacher) > 2. Re: Sent open privoxy port warning (Luther Blissett) > 3. Re: Sent open privoxy port warning (Luther Blissett) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 13 Sep 2013 15:13:18 +0200 > From: Lukas Erlacher <l.erlacher(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] Tor 0.2.4.17-rc on arch armv6 > Message-ID: > <CAJWOhv-pxwHnqy6-bLojr66cGWg=0ee=HhO_WuNb9N= > PAw5mtw(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello to everyone with arm hardware and arch linux, > > I just set up Tor 0.2.4.17-rc on a raspberry pi and I want to share > what I did just to create a piece of documentation that might be > helpful for others. > I got tor-git from the AUR[1], modified it to fetch 0.2.4.17-release > instead of master, and built it according to the aur[2] and > pkgbuild[3] instructions. > > Here is what I did: > > 1) Backup torrc, fingerprint, and private key of my tor node > 2) Read up on AUR and PKGBUILD > 3) pacman -R tor tor-socks > 4) pacman -s base-devel > 5) Download and extract the AUR > 6) Carefully inspect the AUR package, especially PKGBUILD and tor.install > 7) Modify the PKGBUILD file with _branch=release-0.2.4 and > pkgver=0.2.4.17.rc.0 > 8) makepkg -s > 9) pacman -U tor-git-0.2.4.17.rc.0-1-armv6h.pkg.tar.xz > 10) mv /etc/tor/torrc /etc/tor/torrc.tor-git.sample > 11) mv /etc/tor/torrc.pacsave /etc/tor/torrc > 12) systemctl tor start > > That's it. Run "tor --version" and it should tell you that it's a git > build of 0.2.4.17-rc. > > You will have to rebuild the package for every update you want to get! > > As per The Arch Way, Please familiarize yourself with pacman, the AUR, > and PKGBUILD before attempting this! > > Absolutely no warranties given. The AUR can seriously damage your system! > > Best Regards, > Luke > > [1] https://aur.archlinux.org/packages/tor-git/ > [2] https://wiki.archlinux.org/index.php/AUR > [3] https://wiki.archlinux.org/index.php/PKGBUILD > > > ------------------------------ > > Message: 2 > Date: Fri, 13 Sep 2013 12:52:35 -0300 > From: Luther Blissett <lblissett(a)paranoici.org> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Sent open privoxy port warning > Message-ID: <1379087555.555.10.camel@tagesuhu-pc> > Content-Type: text/plain; charset="utf-8" > > On Wed, 2013-09-11 at 12:35 -0700, Aaron Hopkins wrote: > > I sent the following warning to the listed e-mail address of 14 of the 19 > > Tor nodes I found that accepted connections on port 8118, some of which > > bounced. > > > > If any of you run or know how to get in touch with the operators of the > > nodes DaJoker, FawkesSwissBlade, LUDICROUS2U, RaspberryPI, pangu, > > mouseHouse, tornonym, or 75.137.122.118, I'd appreciate if you could pass > > this along. > > > > Thanks! > > > > -- Aaron > > > > --- > > > > I noticed your Tor node _ with an IP of _ is one of 19 nodes that accepts > > connections publicly on TCP port 8118, which is the default port for > > Privoxy. I suspect this might be a configuration mistake. > > > > I'm investigating this because my tor node "tordienet" has received > millions > > of HTTP proxy requests to port 8118 per day for months. The requests > appear > > to come from a botnet running on roughly 1500 IPs, and seem to be > > advertising click-fraud related. From the discussion in July on the > > tor-relays(a)lists.torproject.org mailing list (archive at > > https://lists.torproject.org/pipermail/tor-relays/) this appears to be > true > > of many nodes. > > > > Port 8118 is the default port for Privoxy, which comes bundled with Tor > but > > is meant to provide an HTTP proxy for you and your local users to browse > > through and is not designed to be offered as a public service. If you > don't > > use Privoxy, would you mind shutting it down? Or if you do, can you > move it > > to a different port and/or only allow your own IPs to connect to it? > > > > I'd be happy to provide more information or help you with the > configuration > > changes if I can. > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > Hello Aron, > > Sometime ago I noticed similar behavior from a series of IP numbers > which mostly were inside limestonenetworks IP range and searched for > polipo (port 8123). I sent an email alert to its admins, but received no > answer whatsoever. I also sent to this malling list and some others, but > since my mail wasn't registered I think it bounced. I'm copying it > bellow. In case this is of any help. > > Also, wouldn't this be the case for a "routine security alert" on tor > blogs? > > ************************** > > Hello dear companions, > > Two days ago one of my tor exit nodes experienced something I'm now > calling "limestonenetworks DDoS on polipo" ( $WAN_IP:8123 ), since all > packets in the storm were flowing from a range of 514 different IP > addresses, all of them inside limestonenetworks IP range and targeting > port 8123 on my tor exit node WAN IP. > > Before the packet storm, I could observe a huge increase on attempts to > access my WAN domain through tor. I couldn't relate IP addresses from > this first raise to those responsible for the actual packet storm nor > could I identify some useful pattern there, but they were all coming > from port 9001 and increased just some hours before the storm, so I'm > guessing they are related somehow. > > Also, throughout the storm, one of my log files got corrupted with some > unreadable bin garbage. I do not know if it was intended/targeted > exploit, but I'm reworking secrets and trying to figure out what is this > binary. > > Here is a sample line of a WAN attempt: > > Aug 13 16:50:22 $USER user.warn kernel: [DROP INVALID WAN] : IN=vlan2 > OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx > SRC=77.56.151.190 DST=xxx.xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=43 > ID=38787 DF PROTO=TCP SPT=40888 DPT=9001 SEQ=289854459 ACK=41163 > > Here is a sample line of packet storm: > > Aug 13 20:39:14 $USER user.warn kernel: [hammer] : IN=vlan2 OUT= > MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx > SRC=74.63.216.60 DST=xxx.xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=48 > ID=20269 DF PROTO=TCP SPT=1757 DPT=8123 WINDOW=65535 RES=0x00 SYN URGP=0 > OP > > The attack persisted for at least three hours and left this binary (hex > represented): > > 0000000 0000 0000 0000 0000 0000 0000 0000 0000 > * > 0000b90 0000 0000 0000 0000 0000 0000 2067 3331 > 0000ba0 3220 3a30 3135 303a 2034 6174 6567 7573 > 0000bb0 7568 7520 6573 2e72 6177 6e72 6b20 7265 > 0000bc0 656e 3a6c 5b20 6168 6d6d 7265 205d 203a > 0000bd0 4e49 763d 616c 326e 4f20 5455 203d 414d > 0000be0 3d43 3030 323a 3a31 3732 663a 3a61 6464 > 0000bf0 343a 3a34 3030 313a 3a35 3966 323a 3a61 > 0000c00 6639 643a 3a39 3830 303a 3a30 3534 303a > 0000c10 3a30 3030 333a 2034 5253 3d43 3132 2e36 > 0000c20 3432 2e35 3232 2e31 3031 2037 5344 3d54 > 0000c30 3831 2e39 3833 322e 3533 322e 3035 4c20 > 0000c40 4e45 353d 2032 4f54 3d53 7830 3030 5020 > 0000c50 4552 3d43 7830 3030 5420 4c54 343d 2038 > 0000c60 4449 313d 3335 3431 4420 2046 5250 544f > 0000c70 3d4f 4354 2050 5053 3d54 3932 3635 4420 > 0000c80 5450 383d 3231 2033 4957 444e 574f 363d > 0000c90 3535 3533 5220 5345 303d 3078 2030 5953 > 0000ca0 204e 5255 5047 303d 000a > 0000ca9 > > Attached is the list of participating IP addresses, line by line, with > the count of packets received. The attacker started sending something > like 4 packets per second and increased to over than 9000!!! - just > kidding, over 30 per second. > > JSYK, I welcome any comments. >

1 0

Sent open privoxy port warning
by Aaron Hopkins 13 Sep '13

13 Sep '13

I sent the following warning to the listed e-mail address of 14 of the 19 Tor nodes I found that accepted connections on port 8118, some of which bounced. If any of you run or know how to get in touch with the operators of the nodes DaJoker, FawkesSwissBlade, LUDICROUS2U, RaspberryPI, pangu, mouseHouse, tornonym, or 75.137.122.118, I'd appreciate if you could pass this along. Thanks! -- Aaron --- I noticed your Tor node _ with an IP of _ is one of 19 nodes that accepts connections publicly on TCP port 8118, which is the default port for Privoxy. I suspect this might be a configuration mistake. I'm investigating this because my tor node "tordienet" has received millions of HTTP proxy requests to port 8118 per day for months. The requests appear to come from a botnet running on roughly 1500 IPs, and seem to be advertising click-fraud related. From the discussion in July on the tor-relays(a)lists.torproject.org mailing list (archive at https://lists.torproject.org/pipermail/tor-relays/) this appears to be true of many nodes. Port 8118 is the default port for Privoxy, which comes bundled with Tor but is meant to provide an HTTP proxy for you and your local users to browse through and is not designed to be offered as a public service. If you don't use Privoxy, would you mind shutting it down? Or if you do, can you move it to a different port and/or only allow your own IPs to connect to it? I'd be happy to provide more information or help you with the configuration changes if I can.

2 2

Tor 0.2.4.17-rc on arch armv6
by Lukas Erlacher 13 Sep '13

13 Sep '13

Hello to everyone with arm hardware and arch linux, I just set up Tor 0.2.4.17-rc on a raspberry pi and I want to share what I did just to create a piece of documentation that might be helpful for others. I got tor-git from the AUR[1], modified it to fetch 0.2.4.17-release instead of master, and built it according to the aur[2] and pkgbuild[3] instructions. Here is what I did: 1) Backup torrc, fingerprint, and private key of my tor node 2) Read up on AUR and PKGBUILD 3) pacman -R tor tor-socks 4) pacman -s base-devel 5) Download and extract the AUR 6) Carefully inspect the AUR package, especially PKGBUILD and tor.install 7) Modify the PKGBUILD file with _branch=release-0.2.4 and pkgver=0.2.4.17.rc.0 8) makepkg -s 9) pacman -U tor-git-0.2.4.17.rc.0-1-armv6h.pkg.tar.xz 10) mv /etc/tor/torrc /etc/tor/torrc.tor-git.sample 11) mv /etc/tor/torrc.pacsave /etc/tor/torrc 12) systemctl tor start That's it. Run "tor --version" and it should tell you that it's a git build of 0.2.4.17-rc. You will have to rebuild the package for every update you want to get! As per The Arch Way, Please familiarize yourself with pacman, the AUR, and PKGBUILD before attempting this! Absolutely no warranties given. The AUR can seriously damage your system! Best Regards, Luke [1] https://aur.archlinux.org/packages/tor-git/ [2] https://wiki.archlinux.org/index.php/AUR [3] https://wiki.archlinux.org/index.php/PKGBUILD

1 0

Re: [tor-relays] Getting max bandwidth out of a relay
by Jesse Victors 12 Sep '13

12 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > As I am trying to avoid using too many IPs (IPv4 is constrainted, IPv6 > is not, but the latter won't get much traffic), I'll try if I can get my > tcp-balancer idea setup in the run of next week (low on spare cycles at > the moment) and then forcing each Tor instance to use a specific core. Right, you can only get two Tor instances per IP, at least on IPv4. The third won't get any significant bandwidth. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQF8BAEBCgBmBQJSMcSWXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yA0psH/35+GsdqKtZxG1bC9pjaFeGr mySy8AQ4DTj/FPhQhCtSwlh35ZFrTnagTuK49XChLcepMV830qFon56A29aL3QI/ 9Je5PX5sILxNlMN4ubR5578PfZLTtkWm2j7l58VALFFTkozMVMbkmVsQp63+3AQN MLt6VKb7p1Oob/PGaZsk+9c9gqxDl4LnT6awzcn1caRyUcchsP98BUURtNNdiIqg 7Yb03t3toVDZnkESyqo5n10dxG5OE7EN+ldrJ5jYrZoWmcHlHG6Ln/5pdLL6u/93 4yAxO6DYijzBIXbzzG2TU1Z1t+8s5WGa5ov0s6EdssxqszfK23KgZmBWIESnP9A= =ctNz -----END PGP SIGNATURE-----

1 0

Getting max bandwidth out of a relay
by Jeroen Massar 12 Sep '13

12 Sep '13

TLDR: what do people to do get the max throughput through their boxes? Hi, This might be more tor-dev related (due to the Tor internals, eg why it does not use multiple CPU cores effectively etc), but is likely a bit more appropriate here as there are people who are able to get a lot of performance out of their boxes. I've been playing a bit with setting up a few relays and letting them push as much traffic as possible following amongst others the items at: https://www.torservers.net/wiki/setup/server Thus making sure it is using AES-NI (which turned off and then on made a bit of a difference but primarily in CPU load), and doing some TCP stack and other kernel tweaks. I am running the current-git Tor on them, thus self-compiled and except for the install path no special configure options (any tips there?). The boxes are 2-cpu 6-core E5645 @ 2.40Ghz, with HT thus 24 cores visible. Tor is using about 170% CPU (thus effectively 2 cores) on average along with 3G of mem, the box has 70G of mem thus that is not a problem. A little snapshot from 'arm' from one of the boxes: Bandwidth (limit: 3.9 Gb/s, burst: 3.9 Gb/s, measured: 353.9 Kb/s) Download (45.7 Mb/sec - avg: 27.2 Mb/sec, total: 302.2 GB) Upload (52.5 Mb/sec - avg: 27.9 Mb/sec, total: 308.4 GB): Down/Up varies upto 70mbit, the box has full GE and between them can push easily a single-stream 900mbit flow (tested with iperf/wgets/scp) next to the running Tor process. Thus there seem to be some significant issue in the Tor portion of things (though tuning might affect it as there are more flows etc). There is no connection tracking on the box, as that would just slow things down See also the munged torrc below, in case there are options to be set there. What else is there to tune except for maybe running multiple Tor nodes on the same box? Which would require it to use multiple IPs right as one can only run 2 nodes on the same IP I understand. Would there maybe be a way to run multiple Tor processes with the same key/identity but with a TCP load-balancer in front of it which distributes the incoming connections to the processes? The only thing then is that only one of them should report their details to the authorities and the others should not publish; would that be possible or would it mess up for instance performance stats? Greets, Jeroen -- torrc used: ----- NickName <nick> ContactInfo <contact> MyFamily $<othernode> ControlPort 9051 HashedControlPassword 16:<pass> CookieAuthentication 1 DirPort <ip>:<port> DirPortFrontPage /usr/local/tor/etc/tor/tordirport.html ORPort <ip>:<port> RelayBandwidthRate 600 MB RelayBandwidthBurst 606 MB SocksListenAddress 127.0.0.1 SocksPort 1080 ExitPolicy reject *:* #Log debug file /usr/local/tor/var/log/tor/debug.log Log notice file /usr/local/tor/var/log/tor/notices.log DataDirectory /usr/local/tor/var/lib/tor RunAsDaemon 1 DisableDebuggerAttachment 0 CellStatistics 1 DirReqStatistics 1 EntryStatistics 1 ExitPortStatistics 1 ExtraInfoStatistics 1 ----- /etc/sysctl.d/tor.conf net.ipv4.tcp_syncookies=1 net.ipv4.tcp_synack_retries=2 net.ipv4.tcp_syn_retries=2 net.core.rmem_max=33554432 net.core.wmem_max=33554432 net.ipv4.tcp_rmem=4096 87380 33554432 net.ipv4.tcp_wmem=4096 65536 33554432 net.core.netdev_max_backlog=262144 net.ipv4.tcp_no_metrics_save=1 net.ipv4.tcp_moderate_rcvbuf=1 net.ipv4.tcp_tw_recycle=1 net.ipv4.tcp_max_orphans=262144 net.ipv4.tcp_max_syn_backlog=262144 net.ipv4.tcp_fin_timeout=4 vm.min_free_kbytes=65536 net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_intvl=10 net.ipv4.tcp_keepalive_probes=3 net.ipv4.ip_local_port_range=1025 65530 net.core.somaxconn=20480 net.ipv4.tcp_max_tw_buckets=2000000 net.ipv4.tcp_timestamps=0

4 5

A bit more evidence on circuit creation storms
by Dan Staples 12 Sep '13

12 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Just to add my experiences to the mix: I started running a RPi relay back in January. It ran fine for several months, until I started to get these circuit creation storms periodically. It would come at random times, maybe once a week, and would sometimes last for enough hours that it would knock down the Pi and I'd have to reboot it. While it was clearly CPU bound during the storms (90%+ shown by top), my bandwidth was also completely saturated. I was seeing 3 Mb/s traffic, as shown by ntop (great for monitoring bandwidth over time). Shutting down Tor during the storms would reduce the traffic to < 100kb/s...so clearly the circuit storms eat bandwidth too. Gordon, perhaps you had an upstream router that was preventing the traffic flood during the circuit storms? I asked Roger Dingledine about it at PETS a couple months ago, and he suggested it might be a case where there is a nearby popular hidden service that picked my relay as a guard node, and all of a sudden I get flooded by requests for the hidden service. No idea how to test the accuracy of this hypothesis. Finally, I noticed that bandwidth-related config options had no effect on the 3 Mb/s traffic flood during the circuit creation storms. I had: RelayBandwidthRate 200 KB RelayBandwidthBurst 200 KB MaxAdvertisedBandwidth 200KB ...yet, still 3 Mb/s traffic floods. Even MaxOnionsPending 250, NumCPU 1, and AvoidDiskWrites 1 made no difference in my RPi's ability to weather the storms. I eventually had to use QoS on my DD-WRT router to set limits on the traffic it would pass to the Pi. I will try your builds of 0.2.4 to see if that makes a difference. cheers, Dan > Since I originally started keeping an eye on these on my Raspberry > Pi relay (read: slow, resource-limited), I've got to wonder if the > circuit creation storms I was seeing months ago weren't normal > network phenomena but some kind of test run. > > We are talking going from 50-250 circuits to thousands of requests > per *second* out of nowhere, and then if the machine survived it, > the storm disappearing as suddenly as it came. This was happening > months ago, but less frequently and only on lower-end hardware. > Now it's happening everywhere. > > Even if the previous case *were* "normal" Tor network operation, > I'd say it's a bug, but I'm suspicious that it was whatever is > going on now in its test phase. > > tor at t-3.net: >> Also see a repeat of the odd log message with the 154.x net >> address someone else described with the huge hexidecimal string >> (40 hex chars, + sign, 40 more, on and on). > > Here as well. I believe this is the sign of an overloaded Tor > directory server. > >>> Over roughly the same time frame I received an incredibly high >>> number of spam e-mails in one e-mail account that normally >>> gets 20 or so a day on quiet days. Perhaps this is another >>> example of mal-ware in action. > > Funny, one of the dropped connections during my storm last night > was to port 993... :P > > Best, - -Gordon M. - -- http://disman.tl OpenPGP key: http://disman.tl/pgp.asc Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSKInBAAoJEPZwdO29hkOpDZ4QAIjZqi9kXrcubZUg6v0nH6mP V9LT4j2Md0MqE74JcyEIgIBYKMWbun+n417LMMkb9uLu2mld6Lf/YIU9iO57JqQJ 8dM1uX0LJb51MbOj6ZTZEwMgHI8pX/ZeLj4zQscAz2C2oBwapnOpxqKTbg76CM1G DrP39iai9TpN+YfUY0FkxwdYTM46ADUvk/hbu/34CLXklOvrqWkK/Ta/nZ9zTebt HkB/KJn1P0I5L87x2VmIhIH5JKK6lszDlZg+k96PRC8oK9a1icECCGsnFJpqwVrv UyIsutezQHjT7HT4zJCNBxacHuK8VKbwayX6P/MSPpAGaobqEzSvWJmHdYRrIv2h glM5qIIzB3RmJxvHW8hCF47T8n9B6fo+J5PZly3xtwLGzCATjehnnhGTzigIw8ro WkQwMQr/3F5yQ0YS2YKh+KsQDhe2d1fYbrGtSPAG/z1RMuk2i5tmgyhAFJ8HvIfw GozzAaxcy1dCdEvQIyv/j1LCtUUpCrPVGd51grDI+GB9b5HuIEsPoQCvisshVEpu 1vLKyP7VLv+fOnvVb7MCwiWnU1Q5uw3yC3kdig9tTuAWGiMgbGoWpkGiy5MNVVQA Z2Q7uLnd7j6scTbpWgaa0Fx0HQ2euAXMwC+zS8g0PQXOEslGnnPs2Kqz5YTimtuh LWLcZ3WMZvlShurfNLse =mqNB -----END PGP SIGNATURE-----

2 1

Upgrade your relay to 0.2.4.17-rc?
by Roger Dingledine 12 Sep '13

12 Sep '13

Hi folks, I just released 0.2.4.17-rc. Hopefully there will be debs of it soon. It comes with a new feature: - Relays now process the new "NTor" circuit-level handshake requests with higher priority than the old "TAP" circuit-level handshake requests. We still process some TAP requests to not totally starve 0.2.3 clients when NTor becomes popular. A new consensus parameter "NumNTorsPerTAP" lets us tune the balance later if we need to. Implements ticket 9574. So the more relays that upgrade to 0.2.4.17-rc, the more stable and fast Tor will be for 0.2.4 users, despite the huge circuit overload that the network is seeing. Please consider upgrading. If you do, though, please also keep an eye on it -- it's possible we introduced some new bugs and the network will start dissolving once more relays move to the new version. In my spare time I'm also working on a blog post to explain what's going on and what measures we're taking to keep things afloat. Aren't distributed systems fun, --Roger

13 24

Why is my fast relay so slow to gain popularity?
by Jesse Victors 11 Sep '13

11 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello everyone, newcomer here. I'm behind very fast connection (11.5 MB/sec down, 7.5 MB/sec up) and I thought that the Tor network could benefit from my connection, especially since it's apparently been under high load recently. Per the latest blog posts, I downloaded the beta TBB and configured it as a relay under Linux. It's been up for almost two days now, yet it's still being utilized at a very, very small fraction of it's potential. In the network map, I see that my relay has an advertised speed which is again much slower than it actually can be. To my knowledge, a web server can be put under full load right away, and distributing computing projects use the most of your computer right off the bat. Why doesn't Tor run computational and/or bandwidth tests and advertise my relay at a much more actual speed? I don't see why a fast relay has to start at the very bottom of the barrel to begin with. I can see the logic in slowly ramping up connections in testing for stability and scalability, but the progress is slow because it's continually fighting against that existing average. I can set my requested average and burst bandwidth, but AFAIK I can't affect my advertised bandwidth. Why are things this way, and is there anything I can do to speed up the utilization growth? Thanks in advance for any help you can provide, Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQF8BAEBCgBmBQJSMJg3XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yAAekH/i2rHzwbGZMiL4g31d2JEkQR ZjOaDCe6aNkK/ORf5MhxW7B6L772BczjPkjuO0H1Oe41bSkglO78gCbLC+YQ1r68 0nc45dcztNDkQPhZVrkj7RconNrmfLXFozFLKY1Nr2mLy6RTg0a1yQ/WhpFa/qah cUmVnGtvIoDnDAhuCPIEu7SuGba0I4TkBph1atKAC/gQYyOSp9CpCqxy0J3Qaa3Y pcCkGC7oWW2I9g8UJOx0UKg1auiYMZ1QrwpJ6HdHhvhFSWnhWeggkvaOCDewC2pZ dQg7Odk/ISfkpdeCgd8hg2IQBh3kpI1kRVUvX0sJgbYCbizT45bwKCLf/XzMQHE= =gfnB -----END PGP SIGNATURE-----

4 4

Exit flag given to nodes with nearly-all-reject?
by Jeroen Massar 11 Sep '13

11 Sep '13

Hi, Is the 'exit' flag given to a Tor node which only allows exit to a certain prefix? If yes, what kind of effect does that have on path selection, will it only be chosen for exit'ing to that prefix and not be used as a relay? Greets, Jeroen

2 1

Tor crashes frequently on fast relay
by Random Tor Node Operator 11 Sep '13

11 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everybody, since this botnet started flooding Tor, my Tor relay Bazinga ($196832C61F30E9D6D179393C9AED4E47FD29796B) has been experiencing some issues. Previously, it was relaying 100 Mbit/s for a few months without problem. When the botnet came along, at first the throughput dropped to about 30 Mbit/s and Tor kept spamming "Your CPU is too slow" and crashed every hour or so. I set RelayBandwidthRate to 20 Mbit/s which reduced the crash frequency. Then, 0.2.4.17-rc was released and I lifted RelayBandwidthRate back to 100 Mbit/s. At first it was running fine, but then the crashes came back. This is from yesterday and the day before: $ sudo grep -i interrupt /var/log/tor/log.1 Sep 10 08:59:40.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 10:01:45.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 11:04:50.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 12:49:56.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 13:51:01.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 15:22:18.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 16:07:27.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 10 18:56:03.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. $ sudo zcat /var/log/tor/log.2.gz|grep -i interrupt Sep 09 06:51:20.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 07:54:30.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 08:48:36.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 09:51:56.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 10:20:01.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 10:49:06.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 13:03:26.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 13:26:40.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 13:50:47.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 14:02:54.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 14:26:06.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 14:42:11.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 14:52:17.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 15:08:31.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 15:21:37.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 15:31:27.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 15:44:32.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 15:53:38.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:02:45.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:08:50.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:16:56.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:24:04.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:34:10.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:48:20.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 16:55:25.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 17:02:30.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 17:21:39.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 17:35:45.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 18:51:51.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 19:14:02.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 19:30:10.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 19:50:16.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 20:06:23.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 20:49:52.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 21:13:00.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 21:51:06.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 09 22:54:22.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. It is a VPS on a Xen hypervisor with 3x Intel(R) Xeon(R) CPU L5630 @ 2.13GHz and 2 GB RAM According to htop, tor currently uses about 105% CPU and 350 MB RAM. It was around the same CPU and RAM consumption while it was happily relaying 100 Mbit/s. At first I was suspecting the hoster to have reduced CPU resources or so, but they said they didn't change anything, including no virtualization parameters. Any help would be appreciated. - --RTNO -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMCRbAAoJEJe61A/xrcOQmfcP/Rq2XmtQk8e4orMWe1rPHnKX 6CMMmrI5TIAW/XQ+Qulr2ElEKh0M85XSagF8ZeziQVL348z3FoI36HwUMbzLnkI3 uELx8kq1xTGlLOmtSEdyD9xH2dwCxarlogexVb3uHUVEUQM99GMQd/A4bSzLPgTW 6fnwvDWNNZ4x1PKXxElejGhoHiq2oW5f5JoSijw4LUWJBI2SrXx4aWFHm4SofVti Cncaf+UVM2f4loBn9gUh5LWmbeWviDXsk9p5DeNAAaJ8BwK8dp4MyAoH731dcbpw svJ2b1R0TtmgyO6g/WLJcJX3s9u6iKq2QzQgLavynsAaazn6Rr4nRqPD02TFM7rw nyP9H6r08P/7gumOF3G4JSXe3Px6GMipdcGNl0fBjr6R67sB7ZeMwT00O53m0f5l InUbCCghG/ukcEtbly0CZfu7qOISlz9cxUFShmYWOLv3EpMboh9lyMNC3DbyAYH2 3kMfffyVLS21HgNA57l0N+aZl++jz+EIwFK8r+L9xZEOUBQKcXrfm0jXneV6j8uA J9NuXYyKHWltxU+EO2ccyN2Zco/3KA044dwSnTo1BXCHnt95DjyylLcQj5+7+KYW QIsviYsONp4FSz0aQUFOnLk5KAhZtieQ28Iav1S4Gb3QiL4pY2rR9r27dBZ/E1wg +C9uvwcJz4ei14ZR9A19 =BoPn -----END PGP SIGNATURE-----

3 6