- tor-relays - lists.torproject.org

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
by balbea16 03 Jan '17

03 Jan '17

Hi There I evaluated some relays with newly assigned (red) guard flags. All of them had already the stable flag assigned. And (so far I could see) all of them had (almost) static IP addresses. In my case, this may be the reason why I don't get a guard flag. My ISP changes it every 24 hours. However, I'd be fine with "just" operating a fast middle node. I will keep an eye on this. Mike

3 4

_AceLewis tor relays: please specify 'MyFamily' in your torrc
by nusenu 03 Jan '17

03 Jan '17

Hi Lewis, thanks for adding your 6 tor relays to the network! Please do not forget to set the MyFamily parameter in your torrc configuration to tell clients your relays belong to a single operator. If you need help with the MyFamily option let us know. thanks, nusenu +------------+-----------+-----------------+----------------+ | first_seen | nickname | IP | eMyFamilyCount | +------------+-----------+-----------------+----------------+ | 2016-12-27 | acelewis4 | 138.197.131.213 | NULL | | 2016-12-27 | acelewis | 188.226.129.48 | NULL | | 2016-12-27 | acelewis3 | 207.154.205.226 | NULL | | 2016-12-27 | acelewis5 | 139.59.160.33 | NULL | | 2016-12-27 | acelewis6 | 139.59.42.48 | NULL | | 2016-12-27 | acelewis2 | 139.59.252.170 | NULL | +------------+-----------+-----------------+----------------+

1 0

Re: [tor-relays] Grizzly Steppe
by rush23＠gmx.net 02 Jan '17

02 Jan '17

By the way Jerry Gamblin checked the list against the tor exit nodes and found 191 that have been used in this hacking... There you can find his thread with the whole listing.. https://twitter.com/JGamblin/status/814627227656683521 Regards 0x23 Am 2. Januar 2017 09:39:50 MEZ schrieb tor-relays-request(a)lists.torproject.org: >Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > >You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of tor-relays digest..." > > >Today's Topics: > > 1. Re: Grizzly Steppe (Rana) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 2 Jan 2017 10:39:40 +0200 >From: "Rana" <ranaventures(a)gmail.com> >To: <tor-relays(a)lists.torproject.org> >Subject: Re: [tor-relays] Grizzly Steppe >Message-ID: <03ed01d264d3$c4700b40$4d5021c0$(a)gmail.com> >Content-Type: text/plain; charset="utf-8" > >My bet is that the recorded IP address dates back to the days when your >node >was an exit. Naturally the Russian hackers have used Tor, probably in >tandem >with a VPN - it would have been stupid of them not to, and stupid they >are >not. > >And you are right - now the US government will blame Tor exit operators >for >the sheer stupidity of email operators in political shops such as DNC >that >do not force their users to encrypt email end to end. PGP is too much >trouble for them. > >If I am right there is nothing you can do now, you have already closed >the >exit. If they pressure you, migrate your relay to another IP. > >Rana > >From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On >Behalf >Of Dr Gerard Bulger >Sent: Monday, January 02, 2017 10:15 AM >To: tor-relays(a)lists.torproject.org >Subject: [tor-relays] Grizzly Steppe > >I ran an exit node, but gave up after too many abuse reports that >annoyed my >ISP. So I turned al exit ports off, and reports stopped as a rely. >After >months and many terabytes of data I get an abuse complaint that my tor >IP >has been used for espionage. > >"NCSC have been made aware of a report and associated malicious >indicators >released by the United States Government relating to malicious cyber >activity. A copy if the report and indicators can be found at the >following >link:- >https://www.us-cert.gov/security-publications/GRIZZLY-STEPPE-Russian-Malicio >us-Cyber-Activity >Details within this report indicate network assets which may have been >compromised or associated with malicious activity. We have identified >the >following IP address from this report as x.x.x.x As a minimum, it is >recommended that you check systems and any available logs concerned >with the >above addresses for indications of malicious activity" > >There are no other details as to HOW my tor relay is being used. The >espionage seems to relay on the stupidity of recipients on receiving >emails >asking for passwords. I am not sure HOW ISP or relay service can stop >that. >Or is it that my relay was being used to transfer the data? > >I assume my IP was found by way of a DNS leak which I need to look >into. >There is nothing else I can do as a relay to stop this or is there? > >Gerry > > > >

1 0

Grizzly Steppe
by Dr Gerard Bulger 02 Jan '17

02 Jan '17

I ran an exit node, but gave up after too many abuse reports that annoyed my ISP. So I turned al exit ports off, and reports stopped as a rely. After months and many terabytes of data I get an abuse complaint that my tor IP has been used for espionage. "NCSC have been made aware of a report and associated malicious indicators released by the United States Government relating to malicious cyber activity. A copy if the report and indicators can be found at the following link:- https://www.us-cert.gov/security-publications/GRIZZLY-STEPPE-Russian-Malicio us-Cyber-Activity Details within this report indicate network assets which may have been compromised or associated with malicious activity. We have identified the following IP address from this report as x.x.x.x As a minimum, it is recommended that you check systems and any available logs concerned with the above addresses for indications of malicious activity" There are no other details as to HOW my tor relay is being used. The espionage seems to relay on the stupidity of recipients on receiving emails asking for passwords. I am not sure HOW ISP or relay service can stop that. Or is it that my relay was being used to transfer the data? I assume my IP was found by way of a DNS leak which I need to look into. There is nothing else I can do as a relay to stop this or is there? Gerry

3 2

How can we trust the guards?
by Rana 01 Jan '17

01 Jan '17

Sorry for the naïve question, but we have a total of about 7000 relays, many of them residential and thus practically unused or very lightly used. So the actual number of relays that carry most of the traffic is rather small, and many of them are middle relays, leaving an even smaller number of guard relays. This means that an adversary with a rather modest budget can easily take over half the guards. Whats the trust mechanism (if any) to ensure that the majority of guards are not hijacked by adversaries?

2 1

Re: [tor-relays] [Crypto-practicum] Open-source cooperative security using low-cost HSMs?
by grarpamp 31 Dec '16

31 Dec '16

On Fri, Dec 30, 2016 at 10:36 PM, Bill Cox <waywardgeek(a)gmail.com> wrote: > One problem is shills. IIUC, TOR has a problem where an attacker can create > a ton of nodes that collude. > TOR could be > 50% shills and we would not know. Is this something that could > be implemented effectively with the dreaded web of trust? Yes. It has been repeatedly brought up among tor that relay operators, being globally spread and relatively physically mobile for the purpose of keysigning, can cross sign their node keys with gpg keys, have their gpg keys signed in person under proof of relay ownership as usual, dump the fingerprints into the consensus and sks, then build relay selection algorithms that download and verify the wot into user run tools that then build their circuits in the controller. Users can elect to use variant levels of trust present in the wot, anon / nym / context signing, ID signing, photo signing, multisig assertions, etc. Beyond just the wot, all sorts of other external metrics, even subscriptions to third party metrics services, could be applied to such a relay selection process. 7000 relays, even at low 10% shill and 1:1 would require 700 unique persons of the adversary that pass the smell test of other operators and principals, that has real costs. Or your allies just supply the number of validated nodes needed to prevent network saturation and users simply decline to route anything but CNN and gerbil pr0n through the 700 unvalidated nodes. Pretty simple really, needs nothing more than one structured comment field in the consensus and some external tools, but nobody has rolled it out or even developed concept further yet.

1 0

"Graceful" Restart of Tor-Relay ?
by mistral.relay＠posteo.net 30 Dec '16

30 Dec '16

Hello all, a newbie question: assuming that I want to shut down and restart a running tor-relay (for whatever reason; e.g. a linux reboot is required) - is it fine to just shut down the relay or is there a nicer, more tor-user friendly way so circuits don't drop for them unexpectedly? I was thinking about a command to tell tor to complete whatever is ongoing, but to not accept any new circuits or other requests and then stop working. Would setting the BandwidthBurst to 0 followed by a tor-reload do this over some time (checking with e.g. arm what is still ongoing)? Many thanks!

5 4

I am in with 4 exits
by niftybunny 30 Dec '16

30 Dec '16

https://twitter.com/JGamblin/status/814627227656683521 <https://twitter.com/JGamblin/status/814627227656683521> anyone can beat this? Markus

1 0

TransPort: Convert iptables to pf
by diffusae 28 Dec '16

28 Dec '16

Hello! Does anybody know how to convert this to pf rules in FreeBSD: iptables -t nat -A OUTPUT -p tcp -d 10.192.0.0/10 -j REDIRECT --to-ports 9040 I' running a Tor client in a jail on a different IP and want to route only the .onion traffic through. The DNS stuff is working fine, but I can't find a solution for the above iptables rule, which is working. I like transparently do DNS and Routing for .onion traffic on the network. I looked into the wiki and also find some pf rules, which are routing all the traffic though Tor, but this only works locally. The machine is on FreeBSD 11.0-STABLE. Tor is running in a jail with cloned loopback interface (lo1) and has also a private IP address on the main NIC. Maybe you have some hints. Thanks a lot Regards,

5 11

Relay is missing Running flag in the consensus
by Dmitrii Tcvetkov 28 Dec '16

28 Dec '16

Hello, I have a problem with one[1] of my exit relays: about a week ago this relay lost its Running flag, but it was running all the time. I upgraded Tor on this relay to 0.2.9.7-rc from "tor-devel" FreeBSD port and restarted it. Relay was and still is accessible from outside via ports 80 and 443. FreeBSD version is 11.0-RELEASE-p2. After about 24 hours running on new version I decided to check votes from bwauth on detailed page here[2]. Back then the relay had votes for Running flag from maatuuska, dizum and dannenberg. I've checked the relay's ability to open connections to bwauths and it couldn't connect to longclaw - connection timed out, all other bwauths are reachable from the relay. Test was performed by command "openssl s_client -connect <bwauth ip>:443". Ipfw and pf are disabled on the server, there are only tor, ssh and local_unbound running, unbound uses my recursive DNS resolver on another server. DNS queries are resolved fine. Then I saved /var/db/tor directory and started Tor with fresh identity[3], but in about 6 hours it showed similiar symptoms: only maatuska, dizum and dannenberg were voting for it, so I switched back to old identity[1] since. In December 23th I decided to downgrade Tor version back to 0.2.8 from FreeBSD port "tor" and I enabled info level logging. The relay was running since with version 0.2.8.11, at the moment still only 3 bwauth are voting "Running" flag for it: maatuska, dizum and dannenberg. All bwauths except longclaw are accessible from the server. All bwauths are accessible from my neighbour relays in the same datacenter[4][5]. Log info.log has size of 200 megabytes at the moment, first concerning message is: Dec 23 11:54:23.000 [warn] Cannot make an outgoing connection without a DirPort. messages during relay startup, but they disappear eventually: # grep -c 'outgoing connection without a DirPort' info.log 19 They don't look like a reason for the problem. Another anomaly is huge amount of messages like Dec 23 11:54:24.000 [info] router_pick_published_address: Success: chose address '85.143.213.44'. ... Dec 26 13:58:31.000 [info] router_pick_published_address: Success: chose address '85.143.213.44'. # grep -c router_pick_published_address info.log 1653449 I upgraded Tor to version 0.2.9.8 from FreeBSD port "tor". The flood of router_pick_published_address doesn't reproduce with new version. I can compress the log file to 2 mb file with xz -9 and publish it, though I don't want to do it right away because of the warning: Dec 23 11:54:20.000 [warn] Your log may contain sensitive information - you're logging more than "notice". Don't l og unless it serves an important reason. Overwrite the log afterwards. as I don't really know what exact info I should scrub from it. Currently relay is running with identity[1] and version 0.2.9.8 with info logging. Traceroute to longclaw: 17:05:15-root@bsd1 ~ # traceroute 199.254.238.53 traceroute to 199.254.238.53 (199.254.238.53), 64 hops max, 40 byte packets 1 192.168.240.102 (192.168.240.102) 0.084 ms 0.088 ms 0.059 ms 2 192.168.240.5 (192.168.240.5) 0.664 ms 0.180 ms 0.105 ms 3 85.143.208.1 (85.143.208.1) 1.035 ms 1.437 ms 3.960 ms 4 185-47-53-25.customer.comfortel.pro (185.47.53.25) 0.759 ms 0.615 ms 0.645 ms 5 81-27-254-184.rascom.as20764.net (81.27.254.184) 1.507 ms 1.213 ms 1.300 ms 6 80-64-96-225.rascom.as20764.net (80.64.96.225) 12.082 ms 11.974 ms 11.867 ms 7 xe-9-2-0.bar1.Stockholm1.Level3.net (213.242.110.113) 11.781 ms 11.575 ms lag-127-401.ear1.Stockholm2.Level3.net (213.242.110.41) 12.083 ms 8 * * * 9 63-235-41-149.dia.static.qwest.net (63.235.41.149) 112.242 ms 115.032 ms 117.349 ms 10 * * * 11 65.116.154.6 (65.116.154.6) 182.361 ms 182.780 ms 185.128 ms 12 208.99.210.41 (208.99.210.41) 181.991 ms 182.831 ms 182.524 ms 13 208.99.192.65 (208.99.192.65) 181.698 ms 182.007 ms 182.437 ms 14 204.8.32.86 (204.8.32.86) 185.968 ms 185.809 ms 185.945 ms 15 wren.riseup.net (198.252.153.1) 181.940 ms 181.907 ms 181.890 ms 16 * * * 17 * * * Please tell what I can do to understand a reason of the problem. P.S. During compress attempt of the log memory of the server was exhausted: xz and tor processes were killed. So log is containing information since Dec 23 11:54:20 UTC till Dec 26 13:58:39 UTC. I'll compress logs on another machine. [1] 1836695E7DFE2F80B13A9884431759B5DD19F1DA [2] https://consensus-health.torproject.org/ [3] 9E2833F5F95421B52A5336F66B063E471725F011 [4] 2C2CD992B785F09752278260DCD8D6D6242BB87A [5] 7F350D9EAD6C74730FB13862308BE60FA9B19678

2 1