- tor-relays - lists.torproject.org

Question about responding to abuse request
by Patrick ZAJDA 05 Jul '15

05 Jul '15

Hi all, I run a Tor exit node, and I received an abuse complain from Webiron. In this mail, I can read the following: "If you run a VPN, anonymizer service (like a TOR exit or proxy node), or business intelligence not contracted with the site owner, then we request that the targeted range be blocked from your service. If it is being blocked, then it's at the right and choice of our clients to refuse access." So if I understand correctly, they ask me to block the targeted range they give me in this report. I know I can block this IP range by adding it to my exit policy, but I would like to know how others exit node operators manage these type of requests, because I ask myself if it is not against tor philosophy to block access to a specific network to Tor users. Thanks all in advance for your answers. Best regards, -- Patrick ZAJDA

5 4

Running a Relay behind a NAT (was Re: unflagged BAD EXIT nodes)
by teor 04 Jul '15

04 Jul '15

> Date: Sat, 4 Jul 2015 19:34:45 -0400 > From: Ben Serebin <ben(a)reefsolutions.com> > Subject: Re: [tor-relays] unflagged BAD EXIT nodes > > ?I'll hijack the response.... I'm a sysadmin, an unloved Windows one. My unwanted $0.02 are: > > - Windows installer (omg, Windows, the evil one which if you really want greater adoption is the answer! Oh smokes, someone said it! I agree that relay installers, particularly for non-Linux platforms, would help increase Tor's platform diversity. But platform diversity isn't a large part of Tor's threat model, as its impact is mainly felt through vulnerabilities shared by an entire platform. Currently, it looks like 90% of the Tor relays are Linux, by count of relays. (I believe the weighted bandwidth statistic is much higher than 90%.) https://metrics.torproject.org/platforms.html One suggestion I've heard, but that isn't ideal, is to download the Tor Browser Bundle, and modify the torrc in it to run a relay. That said, a relay operator really needs to know how to download, install, and configure a service on a secured server. So that's one reason a one-click installer is a bad idea. > - change the architecture so running behind nat works (this is probably the #1 limit factor for increasing relays). Every tom, dick, and harry could then add bandwidth via every internet circuit. It would be insane! Tor relays run quite fine behind a NAT, as long as the NAT box handles the number of connections which tor makes. There's even src/tools/tor-fw-helper, which supports NAT-PMP and UPnP. It can be configured via the torrc option: PortForwarding 1 Or, you can configure your NAT box to forward ports yourself. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 1

unflagged BAD EXIT nodes
by starlight.2015q2＠binnacle.cx 04 Jul '15

04 Jul '15

Could someone comment on why 15 exit nodes discovered to be sniffing and abusing login credentials have not been marked with the BAD EXIT flag? The research appears to be legitimate, involved a good deal of effort, and seems credible: https://chloe.re/2015/06/20/a-month-with-badonions/ was blogged by Sophos, also credible https://nakedsecurity.sophos.com/2015/06/25/can-you-trust-tors-exit-nodes/ Is there an issue of trust w/r/t this security researcher? An issue of methodology and/or reproducibility? A shortage of resources to follow up? An investigation attempting to identify the operators? The researcher writes that they received a polite reply from and was summarily ignored with no further comment. AND the exits continue to steal and abuse credentials. If true this would be contrary to the inclusiveness generally exhibited by the Tor Project. IMO a likely password-stealing exit should be marked-first, questions asked later. If some kind of mix-up or mistake has occurred, a good operator should readily be able to defend themselves and not feel ruffled for it.

7 11

Re: [tor-relays] unflagged BAD EXIT nodes
by starlight.2015q2＠binnacle.cx 04 Jul '15

04 Jul '15

At 10:04 7/4/2015 +0200, nusenu wrote: >I find it more worrying that we do not "hear" >about the 'more serious attacks' that keep >them busy and don't allow them to look into >i.e. 'AviatoChortler' (even after a few >weeks). That might mean that there is a >constant stream of 'more serious attacks' >(without information I can only guess). Here is one where 70 bad exits were rewriting an .onion address on a clearnet portal and sending a Tor email service's users to an evil onion clone: https://lists.torproject.org/pipermail/tor-talk/2015-April/037549.html I can see the argument for ignoring the near-zero-ranked exits (as they will virtually never be used) and the massive BW password stealer (due to the value of the bandwidth and the fact that HTTPS is immune to passive sniffing). But am concerned Chloe apparently received mute indifference as her contribution to the project is significant.

1 0

Re: [tor-relays] Simplifying ExoneraTor
by Magnus Hedemark 04 Jul '15

04 Jul '15

tor(a)dserrano5.es thus spoke: > Results: do we really need the "Exit: yes" column? Seems pretty redundant to > me. How so? All exits are relays, but not all relays are exits. And if a relay is only configured as an exit for part of the time, that's a potentially important part of the historic record. Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland

2 1

de-centralised bad exit list files - a bad and/or naive idea ?
by Toralf Förster 03 Jul '15

03 Jul '15

Reading "[tor-relays] unflagged BAD EXIT nodes" /me wonders, such a feature would makes sense. Technically this could yield to a ./torrc.d config directory, where tor users could store the (regular updated) list/s they do trusts. -- Toralf, pgp key: 872AE508 0076E94E

3 2

turned on statistics
by starlight.2015q2＠binnacle.cx 01 Jul '15

01 Jul '15

It looked interesting so I turned on EntryStatistics 1 ConnDirectionStatistics 1 HiddenServiceStatistics 1 in addition to the default DirReqStatistics 1 and the output is indeed interesting. Also have CellStatistics 1 though this information does not seem to be published in the ExtraInfo digest. Any reason why having any of these enabled might be a bad idea? Running 0.2.6.9.

1 0

How to create HSDir on a private network
by Ceysun Sucu 01 Jul '15

01 Jul '15

Hi, I'm currently trying to simulate a tor network on shadow to test out some properties of hidden service's, i was wondering how could i create a hidden service directory or if someone could point towards an example configuration. Thanks, C,Sucu

3 2

Tor handshaking
by Adrian Soh 30 Jun '15

30 Jun '15

My ISP slows handshaking (circuit initialization) severely. Are there Torrc settings or changes to Orbot (Android) that I could use?

2 1

Re: [tor-relays] A bridge too far
by jchase 29 Jun '15

29 Jun '15

Thanks, isis, for your answer. I restarted my bridge without the flags and it's been running 7 days and still no stable flag back. Any experiments you can suggest? -J Chase > jchase transcribed 0.8K bytes: >> Hello, >> Can anybody help me figure out why my bridge has stopped showing the >> flags fast, running and stable? Especially stable, I would love to get >> that flag back. I run two bridges, on two different Rasp Pi's, the one >> with a globe fingerprint of B08284109C72C81ACF5866A17A4CC64CE3E16499 . >> The other with a globe fingerprint of >> 1BCD3EBEFE17EEB86EEDE21D5E2DB8468E2864CF . The first bridge runs with >> obfs 3 & 4 on a Pi 2. It seems I lost the stable flag around the time I >> got obfs 4 up and running. The second bridge runs only with obfs 3 on an >> older Pi. >> I've read that the stable flag is quite handy. Any ideas about how I can >> get it back? >> Greetings, >> J Chase > > Hi J, > > Your bridge B08284109C72C81ACF5866A17A4CC64CE3E16499 appears to have a current > uptime of about 50 hours, and to have the Stable flag, according to > dir-spec.txt, [0] it must have: > > "Stable" -- A router is 'Stable' if it is active, and either its Weighted > MTBF is at least the median for known active routers or its Weighted MTBF > corresponds to at least 7 days. > > Meaning that you probably just need to let the bridge run for a few more days, > and it'll get its Stable flag back. > > Also, for what it's worth, BridgeDB will still distribute your bridge, even if > it doesn't have the Stable flag. The only required flag for your bridge to > get distributed is the Running flag. However, you are correct that having the > Stable flag is useful, because BridgeDB, when distributing some bridges to a > user, will try pretty hard to make sure that at least one of the bridges has > the Stable flag. So, with the Stable flag, you've got a better chance of > being distributed to clients more often, but it's not strictly necessary to > have it, especially for a bridge like yours with small bandwidth and CPU. > > [0]: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt?id=26929b8c5554… >

1 0