- tor-relays - lists.torproject.org

Re: [tor-relays] Adding relays with a click
by Nan 04 Nov '14

04 Nov '14

SiNA Thank you -- that looks like the script we need. Even though it was written for Ubuntu it should work just as well on debian. We probably can simplify it because every GoodCrypto server is already a tor proxy. Thanks again, Nan ----- On Nov 4, 2014, at 17:41:37, SiNA Rabbani sina(a)redteam.net wrote: > You mind find this script interesting: > > https://gitweb.torproject.org/tor-cloud.git/blob/ce98487e1174bff3a76c1f9f03… > > --SiNA GoodCrypto warning: Anyone could have read this message. Use encryption, it works.

1 0

Adding relays with a click
by Nan 04 Nov '14

04 Nov '14

We're considering trying to make it a single click for a sysadmin to add their GoodCrypto server to tor as a bridge or non-exit relay. Any experience with anything like this, especially responses from sysadmins? Nan GoodCrypto warning: Anyone could have read this message. Use encryption, it works.

2 1

CMU exit node IP address will change
by Zack Weinberg 02 Nov '14

02 Nov '14

CMU network operations has decided to move the Tor exit node that my group operates (tor-exit.cylab.cmu.edu) to an isolated subnet in order to minimize consequences for the rest of the campus network. For instance, apparently there have been several cases where third parties blacklisted the entire CMU IP space in response to malicious traffic from the exit node. This is currently scheduled to happen Tuesday (Nov. 4). The new IP address will be 204.194.29.4. I'm sending this message primarily as an assertion that nothing nefarious is going on, but also because I haven't had to change the IP address of a running node before and I would like to ask if there's anything in particular that should be done to minimize downtime. Thanks, zw

1 0

Unexpected sendme cell from...
by Kurt Besig 01 Nov '14

01 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I this was discussed awhile back through the mailing list and online to some extent, however I never grasped the solutions or any real resolution to the issue. My relay is getting fairly hammered daily and I'd appreciate any input regarding the, "[WARN] Unexpected sendme cell from client. Closing circ (window 1000)." error message. Horizons3 Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUVSJWAAoJEJQqkaGlFNDPKbcH/jZ1H4IAmNZ0PHUHIEvisBJJ oSHPQ6fgmtAHwdo6uJakc5L+f4aeIZrOfCKWQ+cQ/LxkcWmZs7H/0N4w/PV8mJWV xN0lPAso9VZLulLuHhLbIJrq6G2XJ1zmBbkmLrEGhT1ZAvFhjcFtwsVTsB0h52EO da2NWvMpNFESkznkvPZSVa7zIRk4nM4YIdb0jrMa1Jw+Z/JdhfE4IJZ2sCgf9HRu 1fX0318uL1AEN9KKYU4yxwZnboEoyluGALy42e7oGxHryctOHmez0MjXglA2j0BA 4VakJJfF8A4BTkGEzMhi4laDDh1glkRal8nJRONsBlTCulzqEMCCNSLml+Cw6Po= =PQab -----END PGP SIGNATURE----- --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

1 0

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

31 Oct '14

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

1 0

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

31 Oct '14

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

3 2

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

29 Oct '14

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

3 2

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

29 Oct '14

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

15 29

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

29 Oct '14

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

3 3

exit relay not utilising full capacity (even after months)
by Rejo Zenger 29 Oct '14

29 Oct '14

Hi, I am running an exit-relay and noticed a couple of odd things: 1. Last months, the node seems to be slow in using the full capacity. - Back in April, I changed the relay's configuration to allow the relay to use all the bandwidth it could take. As a result, within a week or two the bandwidth consumption went up to 50 Mbps. In the months of May to July, I had to limit the capacity of the node again. Mid-July I reverted to the same configuration from April. However, the node was a lot slower to pick up the full capacity. [1] - So, the question is: why is it so much slower maximising the full bandwidth? The configuration from mid-July onwards is identical to the one in April. The only thing that has changed is in mid-August, when I moved to relay into a LXC container. However, that doesn't explain the slow pickup in mid-July to mid-August. - And yes, I am aware of the Roger's blogpost. That does explain why the node may be slow to pick up traffic, but it doesn't explain why it was a lot faster in doing so in April then in mid-July. 2. Since Friday there is a considerable drop in the traffic. - Last Friday, around 23:00 hours CET the traffic dropped to about a third of it's usage the days before. Since then, there have been some increase from time to time, but the average is still half or even less than before Friday. There was no change in configuration. I don't have the time to investigate these issues myself. However, if someone wants to look into this, let me know and I am more than happy to provide the details needed. [1] https://rejo.zenger.nl/tmp/94.142.240.243_10-year.png [1] https://rejo.zenger.nl/tmp/94.142.240.243_10-week.png -- Rejo Zenger E rejo(a)zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J rejo(a)zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF

2 2