- tor-relays - lists.torproject.org

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

minimal specifications for a non-exit relay?
by René Ladan 29 Oct '14

29 Oct '14

Hi, I was running a non-exit relay from my 50/5 Mb/s (more like 35/4 in practice) home connection on a Raspberry Pi B (496 MB RAM, 700 MHz) running FreeBSD using the following configuration: Tor 0.2.4.24 % cat /usr/local/etc/tor/torrc SocksPort 0 Log notice file /var/log/tor ORPort 9001 ORPort [2001:980:d7ed:1:ba27:ebff:fe96:9eb2]:9001 Nickname ymkeo RelayBandwidthRate 500 KB RelayBandwidthBurst 500 KB ContactInfo Rene <r.c.ladan(a)gmail.com> DirPort 9030 ExitPolicy reject *:* ExitPolicy reject6 *:* This seemed to be fine until last night the socket connection pull ran over, so I increased the value from 128 to 32768 (kern.ipc.somaxconn) Things mostly seemed to be fine again until the kernel ran out of resources later last night: ==> /var/log/tor <== [warn] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 148 buildtimes. ... Oct 29 00:28:44.000 [notice] Performing bandwidth self-test...done. ==> /var/log/messages <== Oct 29 01:15:35 raspberry-pi kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached Oct 29 01:15:35 raspberry-pi kernel: smsc0: warning: failed to create new mbuf Oct 29 01:16:30 raspberry-pi last message repeated 36 times Oct 29 01:18:31 raspberry-pi last message repeated 1094 times Oct 29 01:19:30 raspberry-pi last message repeated 450 times Oct 29 01:19:30 raspberry-pi kernel: smsc0: warning: Failed to write register 0x114 Oct 29 01:19:35 raspberry-pi kernel: smsc0: warning: failed to create new mbuf Oct 29 01:20:07 raspberry-pi last message repeated 157 times Oct 29 01:20:50 raspberry-pi last message repeated 234 times Oct 29 01:20:50 raspberry-pi kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached Oct 29 01:20:52 raspberry-pi kernel: smsc0: warning: failed to create new mbuf Oct 29 01:21:37 raspberry-pi last message repeated 216 times Oct 29 01:22:31 raspberry-pi last message repeated 558 times Oct 29 01:22:31 raspberry-pi kernel: smsc0: warning: Failed to read register 0x114 Oct 29 01:22:31 raspberry-pi kernel: smsc0: warning: MII is busy Oct 29 01:22:31 raspberry-pi kernel: smsc0: warning: failed to create new mbuf ==> /var/log/tor <== Oct 29 01:22:32.000 [warn] Your system clock just jumped 332 seconds forward; assuming established circuits no longer work. Oct 29 01:22:32.000 [warn] Your system clock just jumped 332 seconds forward; assuming established circuits no longer work. ==> /var/log/messages <== Oct 29 01:23:12 raspberry-pi last message repeated 10 times Oct 29 01:25:13 raspberry-pi last message repeated 855 times Oct 29 01:25:51 raspberry-pi last message repeated 123 times Oct 29 01:25:51 raspberry-pi kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached Oct 29 01:25:51 raspberry-pi kernel: smsc0: warning: failed to create new mbuf Oct 29 01:26:21 raspberry-pi last message repeated 222 times Oct 29 01:28:21 raspberry-pi last message repeated 279 times Write failed: Broken pipe <-- local SSH connection dropped It might be a matter of further tuning as ticket #9708 and the new doc/TUNING suggest, once I log in at its console. But if a Raspberry Pi is structurally underpowered (I don't imagine relaying at fiber speed on them ;) ) shouldn't there be something on the homepage or FAQ about this? I have seen at least one blog from someone running a relay on a Raspberry Pi with Debian Linux. Regards, René

1 0

RPM for Tor 0.2.5.10 updated with Curve25519 reenabled
by Ondrej Mikle 28 Oct '14

28 Oct '14

Hi, when switching RPMs from 0.2.4.x to 0.2.5.x branch I forgot to merge re-enabling of Curve25519 (it was a historic artifact of EL5 workarounds). RPM packages of 0.2.5.10 with Curve25519 reenabled are now uploaded and should get to you shortly. Ondrej

2 2

How many IOERRORs are common ?
by Toralf Förster 28 Oct '14

28 Oct '14

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>) │ 19:22:17 [ORCONN] STATUS: CONNECTED ENDPOINT: $822E5F038D5FE387FC0CDE5DF209ABBD947FD485~Ololosha │ 19:22:17 [ORCONN] STATUS: CLOSED ENDPOINT: $C29E64C8988A06B4CF67673C7A4B94F5392F03F5~default REASON: IOERROR │ 19:22:17 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:49631 │ 19:22:17 [ORCONN] STATUS: CLOSED ENDPOINT: $6B939266A97973428AA9224CCFD2F6A38AB49745~BaboxTelecom REASON: IOERROR │ 19:22:17 [ORCONN] STATUS: CONNECTED ENDPOINT: $99B72A7C0980DEAA922B4E3BA576E95E03F558EB~RiotRelay │ 19:22:17 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:57447 │ 19:22:16 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:55347 │ 19:22:16 [ORCONN] STATUS: CLOSED ENDPOINT: $8260ADE00B93448C9CE35780BDBA742AC5E91256~McBoobies REASON: IOERROR │ 19:22:16 [ORCONN] STATUS: CLOSED ENDPOINT: $702491F10EFBE6412F6E93E883F1F586839996F8~1tornetpw REASON: IOERROR │ 19:22:15 [ORCONN] STATUS: CONNECTED ENDPOINT: $A4F3A9B0C54EAB665EA00406CEFBCBE7CB9A0138~bygkjynfyn │ 19:22:14 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:47531 │ 19:22:14 [ORCONN] STATUS: CLOSED ENDPOINT: $1337C0053C46F16F6344426029F58870017B24F9~Unnamed REASON: IOERROR │ 19:22:13 [ORCONN] STATUS: CONNECTED ENDPOINT: <XXXXXX>:55608 │ 19:22:13 [ORCONN] STATUS: CLOSED ENDPOINT: $D90B107A1907302E43A6A4E6C851A3AA0B42F094~digitaldoge REASON: IOERROR │ 19:22:13 [ORCONN] STATUS: CLOSED ENDPOINT: $72534C95CFB55F91B764421A1EFFEB421519DE2F~allyourbase REASON: IOERROR │ 19:22:13 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:55608 │ 19:22:13 [ORCONN] STATUS: CLOSED ENDPOINT: $BD0D574F70708E96618492E31F516037E857FC39~wazong REASON: IOERROR │ 19:22:13 [ORCONN] STATUS: CLOSED ENDPOINT: $D369D86310CBC8FFBE064940B55458C754F1B03C~Kyat1 REASON: IOERROR │ 19:22:13 [ORCONN] STATUS: CONNECTED ENDPOINT: $039003C320D9980E0A740F107A1A9C13C99C5FE3~ry4an │ 19:22:13 [ORCONN] STATUS: CONNECTED ENDPOINT: $5E184FEA02B7C54172BBC757636F501047CF9691~pook0oow │ 19:22:12 [ORCONN] STATUS: LAUNCHED ENDPOINT: $5E184FEA02B7C54172BBC757636F501047CF9691~pook0oow │ 19:22:12 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:35274 │ 19:22:12 [ORCONN] STATUS: CLOSED ENDPOINT: $64186650FFE4469EBBE52B644AE543864D32F43C~PsychoOnion3 REASON: DONE ─┘ -- Toralf pgp key: 0076 E94E

1 0

My VPS relay has just been hacked
by Nick Sheppard 27 Oct '14

27 Oct '14

For the last month I've been running a middle relay (no guard flag yet) on a 512 MB VPS provided by Edis.at in Switzerland (4.99 euro per month). The software is Tor 0.2.5.8-rc with obfsproxy 2 and 3 running on up-to-date Debian Wheezy 7.6. I left the iptables at their defaults. Last night Edis suspended my VPS because of a suspected outgoing DDoS attack, and emailed me. I rang their (very helpful) phone support in London and they de-suspended the VPS so I could ssh into it and investigate. ( I told them it was running a tor non-exit relay - that wasn't a problem.) Sure enough the Solus control panel traffic graphs show the tor relay traffic stopping abruptly last night, followed about 40 minutes later by an exponentially increasing spike of outgoing traffic, soon cut off when the VPS was suspended. I ssh'd into the VPS ("last login" showed my own last login, so no problem there) and looked at logs and top. notices.log simply cut off when the tor traffic stopped, but showed nothing unusual before that. The Solus control panel traffic graph started showing (a very small amount of) outgoing traffic as soon as the VPS was de-suspended, so I assumed the malware was still active, and used top. This is typical of what I found. 1 root 20 0 10604 832 700 S ... 0:00.10 init 2 root 20 0 0 0 0 S ... 0:00.00 kthreadd/3277 3 root 20 0 0 0 0 S ... 0:00.00 khelper/3277 1370 root 20 0 36976 660 492 S ... 0:00.38 hxyqbutesc 1400 root 20 0 109m 1616 1188 S ... 0:00.00 rsyslogd 1446 root 20 0 18836 884 680 S ... 0:00.00 cron 1473 root 20 0 49888 1212 608 S ... 0:00.00 sshd 3187 root 20 0 27556 744 504 S ... 0:00.00 vzctl 3188 root 20 0 17808 1968 1500 S ... 0:00.00 bash 5374 root 20 0 21584 1416 1072 R ... 0:00.00 top 5440 root 20 0 6244 536 296 S ... 0:00.00 akcviaxtbl 5443 root 20 0 6244 532 296 S ... 0:00.00 akcviaxtbl 5446 root 20 0 6244 532 296 S ... 0:00.00 akcviaxtbl 5448 root 20 0 6244 536 300 S ... 0:00.00 akcviaxtbl 5449 root 20 0 6244 532 296 S ... 0:00.00 akcviaxtbl There is a strange line near the top for process "hxyqbutesc", which didn't change; and a strange block of lines at the bottom, which changed every second or two. Sometimes it was five similar lines, as above; sometimes it was several block of lines, eg this: 5276 root 20 0 6244 528 292 S 0.0 0.1 0:00.00 qscntoweqb 5277 root 20 0 6244 536 300 S 0.0 0.1 0:00.00 qscntoweqb 5280 root 20 0 6244 532 296 S 0.0 0.1 0:00.00 qscntoweqb 5282 root 20 0 6244 536 300 S 0.0 0.1 0:00.00 qscntoweqb 5283 root 20 0 6244 528 292 S 0.0 0.1 0:00.00 qscntoweqb 5290 root 20 0 6244 532 296 S 0.0 0.1 0:00.00 saqizxaihz 5294 root 20 0 6244 528 300 S 0.0 0.1 0:00.00 saqizxaihz 5295 root 20 0 6244 532 296 S 0.0 0.1 0:00.00 saqizxaihz 5296 root 20 0 6244 524 296 S 0.0 0.1 0:00.00 saqizxaihz 5298 root 20 0 6244 528 296 S 0.0 0.1 0:00.00 saqizxaihz Each block is always 5 lines, and the names (always 10 lower-case letters) seem to be different every time. The blocks change fairly regularly every second or two. I shut the VPS down to stop it doing any more harm, but I didn't delete anything; I can restart it and ssh in again for further investigation if necessary. Eventually I'll have to reinstall everything from scratch, straightforward enough, but what can I do to make sure it doesn't happen again? Would hardening my iptables work? Has anyone else seen this? Nick Sheppard

6 7

tor-relays set on nokia n900
by Franklin 27 Oct '14

27 Oct '14

Hey all My issu not responds?

1 0