September 2013 - tor-relays - lists.torproject.org

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 01 Sep '13

01 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 01 Sep '13

01 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