- tor-relays - lists.torproject.org

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 30 Oct '14

30 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

Tor 0.2.5.10 is released!
by Nick Mathewson 27 Oct '14

27 Oct '14

Hi, all! I just sent a release announcement to the tor-announce mailing list. If you're not on that mailing list, you should subscribe; it is very low-volume. https://lists.torproject.org/pipermail/tor-announce/2014-October/000096.html Synopsis: There is a new stable out. Some packages are up-to-date, more packages should be up-to-date over the next week. Usually I don't announce a stable till there are packages, but people have been asking me about this one, and I'd rather have an official release announcement than a series of weird rumors. yrs, -- Nick

8 9

Relays alongside firewall
by Jan Nielsen 26 Oct '14

26 Oct '14

Hello. I recently enabled UFW on my relays. I have allowed in all necessary ports that my relay uses. I was looking at the logs and there are plenty of blocked incoming TCP connections. These connections are being blocked because they are attempting connection on ports that I have not opened e.g. 9001. However, the traffic appears to be relay traffic. Is ufw interfering with my relay? Are there additional steps to take when running a relay alongside a firewall? Here is a redacted snippet from my ufw log: Oct 26 15:10:29 [UFW BLOCK] IN=eth0 OUT= MAC=04:01:26:15:5a:01:xx:8a:xx:64:xx:f0:xx:xx SRC=202.108.xxx.xx DST=178.62.xxx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=46331 DF PROTO=TCP SPT=49892 DPT=34449 WINDOW=5840 RES=0x00 SYN URGP=0 Oct 26 15:10:32 [UFW BLOCK] IN=eth0 OUT= MAC=04:01:26:15:5a:01:28:8a:1c:64:cb:xx:xx:xx SRC=202.108.xxx.xx DST=178.62.xxx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=46332 DF PROTO=TCP SPT=49892 DPT=34449 WINDOW=5840 RES=0x00 SYN URGP=0 Oct 26 15:15:12 [UFW BLOCK] IN=eth0 OUT= MAC=04:01:26:15:5a:01:28:8a:1c:64:cf:xx:xx:xx SRC=60.186.xx1.xx DST=178.62.xxx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=19751 DF PROTO=TCP SPT=52502 DPT=34449 WINDOW=5840 RES=0x00 SYN URGP=0

1 0

Iptables dump
by Sebastian Urbach 26 Oct '14

26 Oct '14

Dear list members, I want to offer my iptables dump so that everybody who's interested can use it to fill up the firewall with the "usual suspects". My system basically runs just TOR and SSH, so it's not a big surprise that the file contains almost only ip's which attacked SSH. Iptables is fed by fail2ban and then dumped every hour iptables-save so that this collection is automatically loaded via iptables-persistent after a reboot. I will publish this file just once so that this list is not stressed too much. If there is a certain amount of interest i'm willing to offer the file for download permanently. Please contact me if you are interested in that. -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

1 0

Re: [tor-relays] BBC and UK Lottery blocking ip addresses running Tor
by Dan Hanley 26 Oct '14

26 Oct '14

Hi Matt I was in the unusual position where www.bbc.co.uk decided I was not UK resident (I am) and redirected me to www.bbc.com - where none of the links worked for me as that site decided I was UK resident. The BBC did make it clear that they understand Tor relays should not be an issue for them, but that they consider exits to violate their terms of service. It would seem they have stopped discriminating against relays, I doubt they'll ever be exit friendly :-( Dan > > ---------- Forwarded message ---------- > From: Matt Puckey <matt(a)puckey.org> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 25 Oct 2014 18:19:21 +0000 > Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses running > Tor > Dan Hanley: > > Looks like the BBC have changed their rules. I am still running a relay, > > but can now access www.bbc.co.uk in a normal fashion. > > > > Still blocked by national lottery, but I'm hopeful that they both use the > > same third party ip checker, and that the next lottery update will fix > the > > issue. > > Progress! > > I cried a little inside when I read, "We have asked our provider to give > us a way of differentiating Tor exit nodes from non-exit relays, to > allow us to block exit nodes only." > > Ugh. > > Did you have trouble reaching www.bbc.co.uk as well as iPlayer? That > would be strange. I haven't seen them block Tor relays & exits simply > getting to www.bbc.co.uk. > > --Matt > > > >

1 0

Re: [tor-relays] My VPS relay has just been hacked
by Libertas 26 Oct '14

26 Oct '14

For what it's worth, there's an operational security document on the Tor wiki: https://trac.torproject.org/projects/tor/wiki/doc/OperationalSecurity However, that document covers more advanced techniques mostly intended for serious attackers such as government agencies. Others have already mentioned to you the simplest options, which should keep you safe from automated botnet hackers. These include: allow only public key authentication on SSH, use fail2ban or sshguard, update frequently, and don't run anything unnecessary (a torrent client, an HTTP/FTP server). Some relevant links: https://help.ubuntu.com/community/SSH/OpenSSH/Keys (if you're only going to read/do one thing, make it this) https://www.debian.org/doc/manuals/securing-debian-howto/index.en.html#cont… -Libertas

1 0

Note: 0.2.3 is deprecated
by Nick Mathewson 25 Oct '14

25 Oct '14

And please forgive me or sending one more email, please let me call your attention to these bits of the Tor 0.2.5.10 release notes: This release marks end-of-life for Tor 0.2.3.x; those Tor versions have accumulated many known flaws; everyone should upgrade. o Deprecated versions: - Tor 0.2.3.x has reached end-of-life; it has received no patches or attention for some while. If you're still running Tor 0.2.3 on a relay, I'd strongly suggest you upgrade to 0.2.4, or to 0.2.5 as soon as it's available for your operating system. If there's some issue that prevents you from running a more recent version of Tor, please let us know soon so that we can try to address it before 0.2.3 becomes totally obsolete and gets rejected from the network. best wishes, and thanks for running relays! -- Nick

1 0

Oniontip
by Sebastian Urbach 24 Oct '14

24 Oct '14

Dear list members, Since i was the One who asked to put Oniontip on the tor-website (donate section), what is the current discussion status ? -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

1 0

Re: [tor-relays] Unstable router
by humbletoruser＠Safe-mail.net 23 Oct '14

23 Oct '14

Hello, thank you all for your suggestions. From: Julien ROBIN <julien.robin28(a)free.fr> > Take another well known product from well known trademarks > Linksys, D-Link, Netgear, Sitecom, TP-Link, or something compatible with OpenWRT for example. Okay, I'm going to try a new router. I don't use VoIP or TV-Services. Just a Tor Node and a hidden Service.

1 0

If you've ever run one of the Tor Browser default bridges...
by isis 21 Oct '14

21 Oct '14

...then please have a look at #13504: https://bugs.torproject.org/13504 Thanks! -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

Advisory: remote DoS when using Tor with recent OpenSSL versions built with the "no-ssl3" option.
by Nick Mathewson 21 Oct '14

21 Oct '14

Hello, relay operators! There's one important bugfix in the 0.2.5.9-rc release that relay operators should know about. If you have a version of OpenSSL that came out last week (like 1.0.1j, 1.0.0, ) and if your version of openssl is built with the "no-ssl3" flag, then it's possible to crash your Tor relay remotely if you don't upgrade to 0.2.5.9-rc or to 0.2.4.25 (when that's out). This appears to be an OpenSSL bug. The Tor releases in question contain a workaround for it. To tell if your version of openssl was built with 'no-ssl3': run "openssl s_client -ssl3 -connect www.torproject.org:443". If it gives you an output beginning with something like: CONNECTED(00000003) 140632971298688:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40 140632971298688:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596: then you're fine and you don't need to upgrade Tor on your relay. But if it says something that starts like: unknown option -ssl3 usage: s_client args then you need to upgrade your Tor. === Some questions and answers: Q: Does this affect clients? A: No. Only relays. Q: Does this affect me if I'm running a version of OpenSSL other than 1.0.1j, 1.0.0o, or 0.9.8zc? A: No. Only those versions. Q: Does this affect me if I'm running a version of OpenSSL configured without the "no-ssl3" option? A: No. Only versions that were built with the "no-ssl3" option are affected. Q: Does the openssl team know? A: Yes. Have a look at this thread. http://marc.info/?l=openssl-dev&m=141357408522028&w=2 . Also, before I saw that thread, I informed them the other day. Q: Does this affect Tor packages? A: I don't think that we shipped any packages where we used the "no-ssl3" flag to diable ssl3. So only if you're using OpenSSL from another source (say, your operating system) will you be affected. Q: What can I do to remediate this problem? A: You can upgrade to the most recent Tor, or you can use a version of OpenSSL built without the "no-ssl3" flag. Downgrading your OpenSSL is not recommended. Q: What is the potential impact of this bug? A: If a relay is affected by this bug, anybody can make the relay exit remotely. It does not enable any data leaks or remote code execution. Still, the ability to selectively disable relays might enable a sophisticated attacker to do some kinds of traffic analysis more efficiently. So, fix your relay if it's affected. Q: Should we run in circles and freak out? A: Not this time. We should just make sure we fix affected relays. Q: Hey, Nick, you didn't explain this properly! A: Please send a follow-up message that explains it better. :) best wishes, -- Nick

1 1

tor-relays on Nokia N900
by Franklin 20 Oct '14

20 Oct '14

Hi How to set tor-relays on Nokia N900?

1 0

Anonbox Project
by Sven Reissmann 18 Oct '14

18 Oct '14

Hi there, I recently read about the anonbox project [1], a small hardware-router, which allows end-users to connect their whole LAN to the Tor network. The project is on kickstarter at the moment [2]. Has there already been a discussion on how this might affect the performance of the Tor network? Regards, Sven. [1] http://anonabox.com [2] https://www.kickstarter.com/projects/augustgermar/anonabox-a-tor-hardware-r… -- PGP Key: https://0x80.io/pub/files/key.asc PGP Key Fingerprint: 2DF2 79CD 48DD 4D38 F0B6 7557 2E68 D557 49AA 1D99 Note: I'll be transitioning away from this key in the near future.

15 20

Re: [tor-relays] Few questions about relaying
by teor 17 Oct '14

17 Oct '14

Unless you have a specific need to debug tor (hint: you don't), you should remove this line to improve security: DisableDebuggerAttachment 0 And please consider adjusting these lines rather than removing them: RelayBandwidthBurst 25 MBytes RelayBandwidthRate 20 MBytes We've found that relays perform best when given a rate slightly under the capacity of the link. teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w… On 12 Oct 2014, at 01:22 , tor-relays-request(a)lists.torproject.org wrote: > Date: Sat, 11 Oct 2014 17:21:51 +0300 > From: s7r <s7r(a)sky-ip.org> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Few questions about relaying > Message-ID: <54393CFF.5030903(a)sky-ip.org> > Content-Type: text/plain; charset=ISO-8859-1 > > Signed PGP part > RelayBandwidthBurst 15 MBytes > RelayBandwidthRate 3 MBytes > ContactInfo QuebecFibe(a)gmail.com - 200Mb dedicated relay > ControlPort 9052 > CookieAuthentication 1 > DataDirectory /home/blaise/.arm/tor_data > DirPort 9030 > DisableDebuggerAttachment 0 > ExitPolicy reject *:* > Log notice file /home/blaise/.arm/tor_log > Nickname QuebecFibe > ORPort 27645 > RunAsDaemon 1 > > > Use this. You are using the latest Tor? > > > On 10/11/2014 5:11 PM, Blaise Gagnon wrote: > > http://pastebin.com/DQ4k7Fzz > > > > 2014-10-11 10:06 GMT-04:00 s7r <s7r(a)sky-ip.org > > <mailto:s7r@sky-ip.org>>: > > > > Can you please copy/paste your entire torrc to a pastebin and > > provide us the link? > > > > It is hibernating only if you use accounting. Provide us your > > entire complete torrc and we will correct it for you if you don't > > have traffic limits on your server. > > > > On 10/11/2014 4:54 PM, Blaise Gagnon wrote: > >> after a few hours, still hibernating, and still wondering why I > >> lost Stable, Guard and Named all at the same time (see atlas > >> graph)... weird. > > > >> 2014-10-11 6:03 GMT-04:00 Blaise Gagnon <quebecfibe(a)gmail.com > >> <mailto:quebecfibe@gmail.com> <mailto:quebecfibe@gmail.com > >> <mailto:quebecfibe@gmail.com>>>: > > > >> no reason for my node to be hibernating, no caps... > > > >> 2014-10-11 3:31 GMT-04:00 Lunar <lunar(a)torproject.org > >> <mailto:lunar@torproject.org> <mailto:lunar@torproject.org > >> <mailto:lunar@torproject.org>>>: > > > >> Blaise Gagnon: > >>> and ... what is "hibernating" ? > > > >> See AccountingMax and related options in tor manpage: > > > >> AccountingMax N > >> bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits|TBytes Never send > >> more than the specified number of bytes in a given accounting > >> period, or receive more than that number in the period. For > >> example, with AccountingMax set to 1 GByte, a server could send > >> 900 MBytes and receive 800 MBytes and continue running. It will > >> only hibernate once one of the two reaches 1 GByte. When the > >> number of bytes gets low, Tor will stop accepting new connections > >> and circuits. When the number of bytes is exhausted, Tor will > >> hibernate until some time in the next accounting period. To > >> prevent all servers from waking at the same time, Tor will also > >> wait until a random point in each period before waking up. If you > >> have bandwidth cost issues, enabling hibernation is preferable to > >> setting a low bandwidth, since it provides users with a > >> collection of fast servers that are up some of the time, which is > >> more useful than a set of slow servers that are always > >> "available". > > > >> -- Lunar <lunar(a)torproject.org <mailto:lunar@torproject.org> > > <mailto:lunar@torproject.org <mailto:lunar@torproject.org>>> > > > >> _______________________________________________ tor-relays > >> mailing list tor-relays(a)lists.torproject.org > >> <mailto:tor-relays@lists.torproject.org> > >> <mailto:tor-relays@lists.torproject.org > > <mailto:tor-relays@lists.torproject.org>> > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > > > > > > >> _______________________________________________ tor-relays > >> mailing list tor-relays(a)lists.torproject.org > >> <mailto:tor-relays@lists.torproject.org> > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > _______________________________________________ tor-relays mailing > > list tor-relays(a)lists.torproject.org > > <mailto:tor-relays@lists.torproject.org> > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > > > > > _______________________________________________ tor-relays mailing > > list tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > -- > s7r > PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 > PGP Pubkey: http://www.sky-ip.org/s7r@sky-ip.org.asc >

2 1

Unstable router
by humbletoruser＠Safe-mail.net 16 Oct '14

16 Oct '14

Hello guys, I'm hosting a tor relay at home. My router is a Fritz-Box (this one: http://avm.de/service/fritzbox/fritzbox-7362-sl/uebersicht/ ) and the internet connections is really unstable. Frequently the connection breaks. Not only to the internet, also the local network is down till the router reboots. Is there a better solution for routing a DSL connection? A better router or a way to replace the router with the computer running the tor node. Any hint is appreciated. Thanks in advance! Another question: If I'm acessing my side through a .onion address theres no need for ssl/https as the traffic is encrypted anyways, right?

4 3