- tor-relays - lists.torproject.org

Raspberry Pi / Raspbian tor 0.2.4.17-rc binary .deb packages
by Gordon Morehouse 07 Sep '13

07 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello folks, I've built binary .deb packages for Raspbian, the Raspberry Pi flavor of armhf Debian built for the Pi's ARMv6 chip. You can get them here, or find instructions on how to build your own from source if you don't trust my build. https://github.com/gordon-morehouse/cipollini I haven't made any changes to the source itself - no Pi-specific optimizations - just built it on a Pi to get ARMv6 compatible executables; Debian wheezy armhf is targeted at ARMv7 and up, for those not familiar. Best, - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSKm1tAAoJED/jpRoe7/ujjO4H/RfvL2PbUV48lbzLyyD4vuxH FmQdGNSGLyI2u6E2rbugpr5Y2OUVLZDXdPmbypen5rGEgKy73vOSjaoOLLiSu3+w VhOtoKZl4NvHIXFlU+wGddK51gZneUIpiARUqBry9vjglYoMaRHvOEaHrQrUb00f ioBxCgNyP4bLESGECPwIgT5X6PaISATin9fghGTQHQ84F1Zh2Kt7aViMK2RGxJRS WJdZ/PxURHC30uaN5R+KBNgcKHoZHIYTRqAhuD0bfcJbhgEAxDAyxBHB2bSzQOsi fW8IyXLrBshsHAllJZdt6wgcDarRUsMX6G6Y7SuvvNEwG4zXSU+2RnZaWWDygfY= =qxGc -----END PGP SIGNATURE-----

2 1

RaspPi with -enable-ec_nistp_64_gcc_128
by Harold Naparst 06 Sep '13

06 Sep '13

Yesterday, Nick Mathewson wrote: One thing that you should try is seeing whether the latest 0.2.4.x release does any better for you. In particular, I'd recommend trying the just-released 0.2.4.16-rc, with openssl 1.0.1e, and make sure that openssl 1.0.1e was built with the -enable-ec_nistp_64_gcc_128 option if possible. (I see you're already using 1.0.1e, but it doesn't appear to have been built with that option.) When I try to build openssl with this option on my Raspian system, I get *ecp_nistp224.c:43:3: error: unknown type name ‘__uint128_t’ * It would be helpful for me to get some guidance from someone who has done this on Raspbian. Regards, Harold

3 2

how to start remote VPS gui
by I 06 Sep '13

06 Sep '13

2 1

Patch
by Niels Hesse 04 Sep '13

04 Sep '13

Hello. Please excuse my ignorance. I saw the mention of a patch in the recent tor blog post. https://blog.torproject.org/blog/tor-weekly-news-%E2%80%94-september-4th-20… How does one apply that? Thanks in advance.

3 3

MaxAdvertisedBandwidth, MaxOnionQueue and so on
by Thomas Themel 04 Sep '13

04 Sep '13

Hi, currently trying to set up a bog standard relay node that's supposed to generate about 20TB/month of outgoing traffic. I've thus set RelayBandwidthRate 7500 KB RelayBandwidthBurst 20000 KB but keep getting tons of these Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. Questions: - Is this log message still accurate? I've seen from e.g. ticket 9005 that apparently circuit creation is anyway already handled in parallel, and my machine is definitely not constantly overloaded on all 8 threads. - The node also crashes far too often, i.e. multiple times a week. Annoyingly, I can't seem to get core dumps for these crashes even though I've verified that the core ulimit is set to unlimited, but still the crashes themselves or a kill -SEGV $TORPID do not give me core files. Any ideas? I've also verified that the cwd is /var/lib/tor and that /var/lib/tor is writable :( - I've also set MaxOnionQueue 250, but that didn't change much. Any other suggestions? ciao, -- [*Thomas Themel*] I just want an EDitor!! Not a "viitor". Not a "emacsitor". [Albulastrasse 52] Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!! [ CH-8048 Zürich ] [*+41 78 9070988*] Paul J. LoPresti in <1991Jul11.031731.9260(a)athena.mit.edu>

4 4

obfsbridge operators: git master enables client statistics!
by George Kadianakis 04 Sep '13

04 Sep '13

Greetings obfsbridge operators, tl;dr, you might want to upgrade your tor to the latest git master. Trac tickets #4773 and #5040 have been merged to tor's git repository. This means that if you run the current git master, your obfsbridge will produce interesting statistics. Specifically, your bridge will count the number of its unique users like normal bridges do (but because of some complications it was not so easy for obfsbridges). It will also count the number of users per transport. Your bridge will then send these statistics to the bridge authority, and they will be published in metrics.torproject.org so that we can easily track the deployment of pluggable transports. You can experience the stats yourself by peaking at $DataDirectory/stats/bridge-stats. BTW, make sure that you are using the latest obfsproxy written in Python, and not the obsolete obfsproxy written in C. Cheers!

2 2

Status of UserspaceIOCPBuffers ??
by Gordon Morehouse 03 Sep '13

03 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So in the documentation: UserspaceIOCPBuffers 0|1 If IOCP is enabled (see DisableIOCP above), setting this option to 1 will tell Tor to disable kernel-space TCP buffers, in order to avoid needless copy operations and try not to run out of non-paged RAM. This feature is experimental; don’t use it yet unless you’re eager to help tracking down bugs. (Default: 0) Is this description still accurate, or is it better debugged nowadays? Would this be useful to set on machines with limited memory resources, e.g. the Raspberry Pi? Thanks much for any insight. - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSJMrDAAoJED/jpRoe7/ujZX8IALXnFOs6WEQsud4UChnjdDRC Cor6LScDdXjGBvRDodMxyrF6lX50SwIaBR+zu4I4Hw2ekit8UZdBdZafWSjQgq5W KdMW1XruYBEIN2OcWSjSoZ1K2DzuOr1O77JwBhCuRcJtqqIP5yfD2TcF6AmuxHWk 82is5XCppem1b3CVobduKIVvbC6vUu+3fau5jkwrRv0xVQGTEtSWRY9TDFP5hoxB cZN+N2yYAm0pZ9+X1fFOHteKOx9r8ENsHfSCeZfKJXbbeRmklxVnZ1k3AgU2BiET L2tVs/piMOkhOd/hGX59bRk/IyvxArmXxd5+Vq9ejLZa7nmKMuOfZYbKdGo+zlE= =b1Os -----END PGP SIGNATURE-----

2 1

Re: [tor-relays] Someone is trying to overrun the Network
by tor＠t-3.net 03 Sep '13

03 Sep '13

Here is what Top on our Tor relay is doing today: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 1163 _tor 20 0 628m 286m 34m R 106.3 15.3 4693:47 tor Logs filled with: Sep 03 04:12:20.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [5700 similar message(s) suppressed in last 60 seconds]

1 0

onionoo
by eliaz 03 Sep '13

03 Sep '13

Been having a devil fo a time keeping my bridge up this week. One question: With the bridge up & running, & the map showing it connecting to circuits, why is onionoo reporting "running":false, ? Should I worry about this discrepancy? Thanks, eliaz

4 10

Analysis of log file
by Carsten Larsen 02 Sep '13

02 Sep '13

Hi tor-relay list, I have been running a tor node for 133 days and Im starting to receive some weird messages in the log file. One of them look like this: Received http status code 504 ("Gateway Time-out") from server '154.35.32.5:80' while fetching "/tor/server/d/9169637E422C216BECD05C6CFE3AE..... I also have another one which appear regular: [warn] {NET} Failing because we have 991 connections already. Please raise your ulimit -n. First question is: any ideas how to get ride of these messages ? Second: Would it be possible to submit a log file for further analysis, and to whom should I send it ? The node is running on ARM debian box. I can of cause provide details if it necessary. Best regards Carsten Larsen Fingerprint: E1EE4FB010F28E55B7ACA2D046AB89F3B413F2A3

3 2

Re: [tor-relays] Pony C&C
by xorox 02 Sep '13

02 Sep '13

hi, xoroxDE2 176.9.122.78 *is listed * http://cbl.abuseat.org/lookup.cgi?ip=176.9.122.78&.pubmit=Lookup xoroxFR 5.135.167.214 *is listed * http://cbl.abuseat.org/lookup.cgi?ip=5.135.167.214&.pubmit=Lookup xoroxLU 94.242.252.225 *is listed * http://cbl.abuseat.org/lookup.cgi?ip=94.242.252.225&.pubmit=Lookup xoroxDE & xoroxLU2 are not listed ... :-) -- xorox5025(a)gmail.com +32/496.702.589

1 0

node list or moral discussion forum
by That Guy 02 Sep '13

02 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Other node operators, could you please try your IP address? Perhaps > this could explain the recent increase in connections? > within 2 days of setting up a node at a new IP it was added to the extortionists over at SORBS :-/ a suggestion: maybe a new tor-node-moralfag-mailinglist should be set-up as to remove this soap opera from a technical mailing list. _________________________________________________________________________ GnuPG Fingerprint: 7770 D186 A06E A329 2217 3161 63EB F269 37B8 8644 _________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJSJIVTAAoJEGPr8mk3uIZEJa0P/3nbn6UJyWCKPL1qi3KZ80fE T1OUYJVJKFAlN+u1Ur59CZWS2tsHJUhES4ovOj1gWF7TdrORS/knojQwM1JDyrWU 2b5Dw/jXnmf2BabliXKebk6BktEiN8I41UlVT/3MtZRnI3K1xCw0tvXy1Em3e1pJ V5EttYsylw6MXX00cO9L+LiQOHRATriTIYCUfdLmdamFkJyS27WZgEtVJ/zQGNpo dqUka2Wbns8gKPRr+4qdnA7JulM6P+gsS2hwOf+cSsTek0j9SU4UR3LLNJRXj6d/ ftCkBmp+9Bwc6FCfrT3msGDqIijei+yYjcD+ptoo9mdL/QI7GDCVbHpljowkBegS 0yvdub+WNHULjQ2bxumzi1m6DI91hAfTqwQTEUhhe8Co0/GLsjCelYdhDrTBdWIm ykH/2fqpkv2HsyK20qcUicJiijOjQODW5Ctxr7P3i9fMIi8vO/YCS7/kWwspQhXH fmdsbLzUnjpJuBU9OacuuVldOIw8Yit5URd8zLlF8Pai2a5eeedLKdG/84biKWsE 12iaJl1Ub+Wyg3FkG0/lXp1n2ANATfG3CZnAamnqwylk9N7a714LgK2jhFcRrMZE aHHIrzfEpYSceukFq8G8o6oL7zExC2i0xk8B+0pWCPkoRVw9pmXnRLvFs1HSV2f3 7b9fRFCfVB/EWq0fV9YC =d/kt -----END PGP SIGNATURE-----

4 3

Unsub me please?
by Susan Harbison 02 Sep '13

02 Sep '13

Thank you.

3 2

A bit more evidence on circuit creation storms
by Gordon Morehouse 02 Sep '13

02 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So, I started having "tubes clogged" problems this evening and realized, finally, that my Raspberry Pi powered relay had been weathering a circuit creation storm since about 18:11 my time. tl;dr main dev-related questions at bottom Aug 29 18:11:03.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. Aug 29 18:12:02.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [2692 similar message(s) suppressed in last 60 seconds] First off, I'm happy to note that the Pi is far, FAR more able to weather these storms running 0.2.4.x, even without the perfectly optimal OpenSSL (all jokes aside about that particular combination of three words)... Secondly, the number of messages escalated. Here is the worst: Aug 29 18:38:04.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [18258 similar message(s) suppressed in last 60 seconds] What on earth is causing so many circuit creation requests in such a short timespan? Again, a Pi-specific note - on 0.2.3.x, the Pi would have crashed or Tor been killed before this number ever reached five digits, so 0.2.4.x is better! I has a metric! However, note that whatever is going on starts plugging up the works in Tor itself: Aug 29 18:18:36.000 [notice] Tried for 129 seconds to get a connection to [scrubbed]:993. Giving up. (waiting for circuit) Aug 29 18:19:04.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [7190 similar message(s) suppressed in last 60 seconds] Aug 29 18:19:14.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 172 buildtimes. I assure you, my network connection speed didn't change. I still don't know how in the Tor protocol a circuit creation request is made, but maybe it was them gobbling bandwidth. Probably not, though? There was an increase in average TX/RX bandwidth during this incident, but not to levels that are in any way out of the ordinary for how I use my Internet connection. However, it's still causing trouble with my router (which is running Tomato). Check this out: Aug 29 18:56:14.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [13867 similar message(s) suppressed in last 60 seconds] Aug 29 18:56:40.000 [warn] eventdns: All nameservers have failed [snipped similar "too slow to handle" messages] Aug 29 19:05:19.000 [notice] eventdns: Nameserver 192.168.1.1:53 is back up My main question: How do circuit creation requests on one's Tor relay cause load on one's network infrastructure? Is it DNS requests? Is it TCP connection state entries? It's not bandwidth, we observed that above, and my router can handle far faster pipes than the one it's on currently. The DNS failing is a sign that the router is under severe stress. Back in the 0.2.3.x days, I often had to reboot the *router* after one of these storms, not just the Tor relay. And again - do we really know what is causing this? Something seems seriously wrong with the kind of numbers I'm seeing coming in to a node with MaxAdvertisedBandwidth 250KB. I think a bug should be opened about this, if there isn't one already. Regards, - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSIAT1AAoJED/jpRoe7/ujuK4H/06MxbDHlN2uHjae6XurDib1 3yxXhHAUXC5pcP8smLQgqqtazTweeQDfIOT78QS9I0MB5z7ZnAYYsjs1/tJ1AKhb GkHtYXnlaZCxuP/oHlZYVsEhKXGGRSrXQM+y9f4uoukCn7KyVlCPF9oz2wBtSLqE qCENCZydn7nPUL6mRxveCoUvVXcGfBvm9uk17SmfuV2e6eDr5NMM4x2IxsZAYzLq hfYOUs8xLMqldsFqIaIV5J8sKwurI040P+TpZNVe7anB1ZF7uNRPfiyGrG7/JgTq aiGTyPArEdLnqYcRwGW+HbXBhQBjqF5yLt5Jj+kXXG5qBvaLQ3h/7IT7CJFr8GI= =eaXx -----END PGP SIGNATURE-----

6 9

Re: [tor-relays] Pony C&C
by Pierre Dennert 02 Sep '13

02 Sep '13

Ich checked both of my Exit nodes: IP Address 91.219.238.107 is listed in the CBL. It appears to be infected with a spam sending trojan, proxy or some other form of botnet. <- uptime ~16 days IP Address 84.201.38.234 is not listed in the CBL. <-- New node, uptime < 24hrs > This was detected by observing this IP attempting to make contact to a > s_patcher Command and Control server, with contents unique to s_patcher C&C > command protocols. Not cool at all, let's see how the new node works out. > I have been running a Tor exit node for only 2 days on a fresh IP address. > However, that IP address is now blocked by spamhaus because it apparently > tried to contact the Command and Control server of the "pony" malware: > > http://cbl.abuseat.org/lookup.cgi?ip=5.79.81.200 > > Other node operators, could you please try your IP address? Perhaps this could > explain the recent increase in connections? >

1 0

Re: [tor-relays] new relays
by tor＠t-3.net 02 Sep '13

02 Sep '13

I feel like you are SO missing the point. Making Tor block morally horrible things does not involve telling exit notes to block traffic to known porn sites. The porn sites with the boobies that someone might hit on port 80 on the public internet represent the Catholic Church of porn, metaphorically-speaking. The truly terrible stuff is hidden to where you as an exit node operator would never be able to simply block it by IP address or domain name. It seems clear that it would require designing into Tor the ability to inspect the content of its packets in the unencrypted form, plus be able to be configured to identify and reject files with certain identifiable signatures. This capability would have to be implemented in all nodes, in order to detect the reject-files should they come from the .onion sites. That kind of capability would damage Tor's anonymity at the technical level (</understate>). If someone believes that making a G-rated Tor is a good idea, they must not be considering the wisdom behind why it was designed the way it was, with each node not knowing the nature of the data it passes. The same technical characteristics which protect the investigators and whistleblowers and "rights of humanity" will also by their nature protect the boobie-watchers. Think about this, understand this. It is not about the concept of anonymity and privacy, it's about the technical requirements necessary to provide it in the face of the hostile environment we have now. On Sunday 01/09/2013 at 5:48 pm, Jon Gardner wrote: > > On Aug 28, 2013, at 5:09 PM, Roger Dingledine <arma(a)mit.edu> wrote: > >> >> On Tue, Aug 27, 2013 at 11:12:01PM +0200, Tor Exit wrote: >>> >>> Why is it so bad if a Tor exit operator tries to match the use of >>> their node with their own moral beliefs? >> >> I really would like to support this if I could. > > I appreciate your kind and well-reasoned response, Roger. > > For those others who, through (unkind, often poorly spelled, and > logically flawed) mockery and name-calling, hypocritically demanded > censorship of the very idea that individual liberty necessarily > involves individual moral responsibility, I have composed a poem. > > A few puerile punks would use Tor > To browse for big boobs, nothing more > "Rights of humanity" > Was just false piety > So bit by bit all the web closed the door. > > If you want to use Tor for immoral things, go ahead--it will obviously > accommodate you--but please stop pretending to speak for those of us > who run Tor nodes because we actually care about human rights and > liberty, and aren't just using those nice catch-phrases as a cover for > licentiousness and mindless self-gratification. You're a large part of > the reason that Tor is "technology non grata" in so many places, to so > many people that would otherwise fully support its mission. > > Hugs, > Jon > > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

1 0

Re: [tor-relays] Someone is trying to overrun the Network
by tor＠t-3.net 02 Sep '13

02 Sep '13

That tool is claiming this about our relay: "This IP is infected with, or is NATting for a machine infected with s_ddos_dirtjumper". Says the problem connection was an attempt to connect to port 80 on a "s_ddos_dirtjumper Command and Control server with contents unique to s_ddos_dirtjumper". Behavior last seen 14 hours ago. Read a little about it - wondering if it requires a malicious Tor user to cause a machine to make this kind of traffic flow through Tor, or if an infected victim using Tor would be enough. Seems exit node operators may be able to stop this particular thing if they knew the IP addresses of the described botnet "Command and Control Domains". One could drop that traffic outbound by IP. The abuseat.org site only seems to know its honeypot/sinkhole address though and that's not the one to block. On Sunday 01/09/2013 at 4:53 am, elrippo wrote: > Hy Folks :D > > Today i got this warning from rkhunter. > > "Warning: Network TCP port 60922 is being used by /usr/sbin/tor. > Possible > rootkit: zaRwT.KiT > Use the 'lsof -i' or 'netstat -an' command to check > this." > > I guess this is a false positive in conjucntion to the massive raid of > traffic > increase in the past 3 weeks, were Tor opens these Ports to manage the > massive > circuit building requests. > > I didn't find anything suspiciouson this relay. > -- > We don't bubble you, we don't spoof you ;) > Keep your data encrypted! > Log you soon, > your Admin > elrippo(a)elrippoisland.net > > -----BEGIN PGP PUBLIC KEY BLOCK----- > Version: GnuPG v1.4.11 (GNU/Linux) > > mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd > BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb > UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ > B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 > Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R > 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs > e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 > jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h > q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z > +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI > KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB > tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs > cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL > BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 > uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd > U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW > oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s > IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb > BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI > kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ > axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM > XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi > dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ > qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU > 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY > s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz > f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc > ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich > O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt > 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 > KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB > FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN > LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv > 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ > MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos > UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC > AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo > N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L > WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs > 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj > 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW > r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU > 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T > An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr > 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN > OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF > Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN > /VaCiLbP4Z3xEw/9EbAJJkhmmx1Qw3ueoqc4h1MmhUtIdxSZ/oA9SjwlnY++zvaZ > 6w1wTS4P+OUkETNDtItdpxXMJ9qfSy9voAQc2K43WMZCCmpPJYSdqaZZNPFj+Ne8 > 6FNtNKuUkXREybpHwlVAXnHzInmFOOM9RAmF70r3zEmKt77W1ztBLo2o9X79gPgL > u9ThgrH6Oc2k46n+9nc3joccr7miiX/bp976DNWcWdOYThiSSOCb8Zw9/Zs935i1 > wUVkYTj24tmBH4H5ov9ib7RPmU21ru458RbUKG0ONAqBtAHNyXHzUnXsrke+D4VW > MI06YcXSk8YeYgQ8GxgHQc+W2bb8LIbKN1hEYJ0wzM62vKR2/Oiwuf8lXutIKTuz > +v7Vj1PQd66DGHsxtWRaWnr1c54JTL2wICHJYKFH4grp7864+GL/uQ1O/Z/XxVku > E1JQ/AnwBGU1M1S6otwWGWVRjzEzQtxsfcCEPvV/9td3FIFQAbGTPb+48XFU+TY9 > 8AlcXBlDzXq7c5f8Evn/oSIsZDt63K4HNTmMGqOTl/p1aA0e4eyX76LczY06rDP5 > GMSNs+AHmYgZiS4RYhRUIvS9uLXMnnDAMYst0SDl2orDUUeHBTzu0rchyknBZMGP > p5wQuWQ9CFlV+dj3UYbrBwC1lTkAMXRG2vlhA0V0TZqos7A5D4VHgSUQQjE= > =otlL > -----END PGP PUBLIC KEY BLOCK----- > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

1 0

Which clock is out of sync on VPS non-exit relay?
by I 02 Sep '13

02 Sep '13

4 4

Pony C&C
by Yoriz 02 Sep '13

02 Sep '13

I have been running a Tor exit node for only 2 days on a fresh IP address. However, that IP address is now blocked by spamhaus because it apparently tried to contact the Command and Control server of the "pony" malware: http://cbl.abuseat.org/lookup.cgi?ip=5.79.81.200 Other node operators, could you please try your IP address? Perhaps this could explain the recent increase in connections?

2 1

Being flooded.........
by Allan Moon 02 Sep '13

02 Sep '13

....................by virusessince starting relay. I run several anti viral and malware routines daily and ever since deciding to start relaying, they are all being stretched to their capacity. Let me know when the sys is cleaned up. Maybe include an anti viral with the relay setup and update it thru the software. Make it so no one can connect to Tor unless they are certified clean.

12 12

Someone is trying to overrun the Network
by elrippo 01 Sep '13

01 Sep '13

Hy Folks :D Today i got this warning from rkhunter. "Warning: Network TCP port 60922 is being used by /usr/sbin/tor. Possible rootkit: zaRwT.KiT Use the 'lsof -i' or 'netstat -an' command to check this." I guess this is a false positive in conjucntion to the massive raid of traffic increase in the past 3 weeks, were Tor opens these Ports to manage the massive circuit building requests. I didn't find anything suspiciouson this relay. -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elrippo(a)elrippoisland.net -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.11 (GNU/Linux) mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN /VaCiLbP4Z3xEw/9EbAJJkhmmx1Qw3ueoqc4h1MmhUtIdxSZ/oA9SjwlnY++zvaZ 6w1wTS4P+OUkETNDtItdpxXMJ9qfSy9voAQc2K43WMZCCmpPJYSdqaZZNPFj+Ne8 6FNtNKuUkXREybpHwlVAXnHzInmFOOM9RAmF70r3zEmKt77W1ztBLo2o9X79gPgL u9ThgrH6Oc2k46n+9nc3joccr7miiX/bp976DNWcWdOYThiSSOCb8Zw9/Zs935i1 wUVkYTj24tmBH4H5ov9ib7RPmU21ru458RbUKG0ONAqBtAHNyXHzUnXsrke+D4VW MI06YcXSk8YeYgQ8GxgHQc+W2bb8LIbKN1hEYJ0wzM62vKR2/Oiwuf8lXutIKTuz +v7Vj1PQd66DGHsxtWRaWnr1c54JTL2wICHJYKFH4grp7864+GL/uQ1O/Z/XxVku E1JQ/AnwBGU1M1S6otwWGWVRjzEzQtxsfcCEPvV/9td3FIFQAbGTPb+48XFU+TY9 8AlcXBlDzXq7c5f8Evn/oSIsZDt63K4HNTmMGqOTl/p1aA0e4eyX76LczY06rDP5 GMSNs+AHmYgZiS4RYhRUIvS9uLXMnnDAMYst0SDl2orDUUeHBTzu0rchyknBZMGP p5wQuWQ9CFlV+dj3UYbrBwC1lTkAMXRG2vlhA0V0TZqos7A5D4VHgSUQQjE= =otlL -----END PGP PUBLIC KEY BLOCK-----

3 2

Re: [tor-relays] huge increase in relay traffic
by Jeroen Massar 01 Sep '13

01 Sep '13

On 2013-08-30 20:39, Yoriz wrote: [..] > Aug 29 23:19:59.000 [warn] Received http status code 504 ("Gateway > Time-out") from server '154.x.x.x:80' while fetching > "/tor/server/d/54BDF368367470FCBF015...067.z". I'll try again soon. > Aug 30 00:14:52.000 [warn] http status 504 ("Gateway Time-out") reason > unexpected while uploading descriptor to server '154.x.x.x:80'). That likely is the following ticket: https://trac.torproject.org/projects/tor/ticket/8458 Greets, Jeroen

3 4

Node specialization
by Pascal 01 Sep '13

01 Sep '13

http://torstatus.blutmagie.de indicates that only 21.4% of Tor nodes are exit nodes. Are we wasting this precious resource by running non-exit traffic through these nodes? -Pascal

5 4

Re: [tor-relays] new relays
by tor＠t-3.net 01 Sep '13

01 Sep '13

This thread did go goofy and bad (and off-topic, given the subject in the emails). It seems clear that there are important reasons Tor could never begin examining/taking direct responsibility for/filtering the content that flows through it (as opposed with disallowing specific ports, which is different). Asking for this seems naive. On Saturday 31/08/2013 at 8:54 am, Steve Snyder wrote: > > > On 08/30/2013 08:05 PM, Andrea Shepard wrote: > [snip] >> >> If I were going to work on filtering by technical means, it'd be >> filters to >> keep neo-Puritans like you out of my life, thanks. > > Well said. This whole thread is example 87653478965432 of the > "censorship is A-OK if I don't like it" mindset. > > Maybe we need a competitor to Tor, a privacy network that only allows > pictures of cute kittens and puppies as traffic. > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Overload data for Exit vs Non-Exit (and Guard vs Middle)?
by Mike Perry 31 Aug '13

31 Aug '13

To try to get to the bottom of the recent influx of clients to the Tor network, it might be useful to compare load characteristics since 8/19 for nodes with different types of flags. People with Munin setups: it would be especially useful if you could post links/graph images for connection counts, bandwidth, and CPU load since 8/19. I'm particularly interested if people with just the Exit flag (w/o Guard) are seeing increased connection counts that aren't explained by uptime or ramp-up. So far the only datapoint I have for this is https://www.torservers.net/munin/torservers.net/psilotorlu.torservers.net/i… but it looks like that node just rebooted and possibly rekeyed, so it's connection increase could just be due to that. It would also be interesting to see if Guard+Exits are seeing a greater increase in connection counts than just Guards. I'm also wondering if any aspects of the load has any other relation to node flags. -- Mike Perry

5 5