- tor-relays - lists.torproject.org

Re: [tor-relays] Improving Node Connection Testing
by teor 02 Jun '15

02 Jun '15

> > Date: Tue, 02 Jun 2015 11:58:25 -0400 > From: 12xBTM <12xbtm(a)gmail.com> > > This is a little write-up on the quality of data connections involving > nodes, and some thoughts on that. So, as of today, the quality of nodes > is determined by their bandwidth, uptime, and not being malicious. There > are two major missing factors from this, and I wanted to bounce some > ideas around: Latency and Packet Loss. These are fairly simple tests > that can be performed on nodes, albeit, it would increase the resource > load on the bwauths. However, nodes with high latency or packet loss > should be identified, and nodes should be measured with these two > important factors. > > High latency will increase the delay of the circuit, but will not appear > in the consesus at all. A node can have enormous latency and hamper that > circuit without anyone knowing. The same could be said for a node that > drops a lot of packets, or drops a lot of packets at a certain time of > day (peak usage). Do the bwauths only measure the time to transmit the data, or do they include the time to connect as well? Including the time to connect would be a measure of latency, particularly for smaller file transfers. Are the bwauths only using one size of file transfer to measure bandwidth? Using a small and large size would allow measurement of mostly-latency and mostly-throughput with the current infrastructure. Since, as far as I know, Tor connections are in-order delivery, dropping packets will cause retransmits, and back up (parts of) the transmission. This will reduce the bandwidth as a side-effect. This reduction in bandwidth is currently measured by the bwauths - but, as you say, it isn't a direct measurement. In future, it would be great to have separate statistics for latency and packet loss - but this is perhaps a job for something more like Ooniprobe? teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

3 2

IPv6 slows BW?
by torelay 02 Jun '15

02 Jun '15

I have two relays that I set up last night to test. They're at the same datacenter, same spec server, and configured identically. The only difference is one is set up for IPv6 and the other isn't. With IPv6 BW is at: 75kB/s Without IPv6 BW is: 110kB/s Is this normal behavior or has anyone else experienced this loss of bandwidth? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

2 1

Fwd: Re: Multi-core Support
by 12xBTM 02 Jun '15

02 Jun '15

-------- Forwarded Message -------- Subject: Re: [tor-relays] Multi-core Support Date: Tue, 02 Jun 2015 11:55:31 -0400 From: 12xBTM <12xBTM(a)gmail.com> To: Roman Mamedov <rm(a)romanrm.net> Some multicore support (at least 4 cores) should be a priority. Going beyond doesn't cater to many node operators at this time. Don't quote me on the numbers, but having decent 4-core support would let someone run a node with the same bandwidth on an Atom/i5 that currently runs on one thread of a Xeon. Or, if someone has a Xeon, such as a collocation center, would let them fully utilize the processor they are paying for, which would be a good morale boost for node operators. But, honestly, the very minimum that can be done to improve the situation (which I know is being worked on as of 0.2.7) is improving a 2-thread program, to further utilize 2 threads of a cpu. That way, we can get by with 2 processes on one 4-thread CPU, instead of being tempted to jumped to 4 processes. On 2.6.15 11:31, Roman Mamedov wrote: > On Tue, 02 Jun 2015 11:13:13 -0400 > 12xBTM <12xbtm(a)gmail.com> wrote: > >> Improving multi-core support can allow users to saturate high bandwidth >> connections with cheaper processors, less setup, and just more efficient >> deployment of high-capacity nodes in general. Improving multi-core >> support should be a major priority. > Sure but I doubt anyone contests that it's better to have multicore support, > than to not have it. However that work doesn't get automatically done. > > One quick and simple stop-gap alternative that I suggested some time ago would > be to stop ignoring more than two relays per IP address. > > With the IPv4 shortage and abundance of multi-core CPUs, raising that limit to > let's say 4, would at least allow many people to run a Tor process per core on > the same single IPv4 that they have (utilizing up to four cores, not just two). > > Considering that Tor is already somewhat multi-threaded (each process can use > up to "120-130%" CPU), that might be just enough in most circumstances, since > true 6-8-core CPUs are rare, and what's seen more often beyond 4 cores is > either Intel HT or AMD's "light" core technologies. > > Of course the management (and memory) overhead of multiple processes is still > there, so proper multi-core scaling is the ideal final goal. >

1 0

Re: [tor-relays] Multi-core Support
by teor 02 Jun '15

02 Jun '15

> Thomas White: > Have there been any updated ETAs concerning the development/support > of multi-core for the core tor workloads? If not, is there anything > in particular that I could do to speed the process up? Scaling the > capabilities of the Tor process would be a huge relief and help for > my upcoming project so I am keen to push it through should it be > possible to bring up the priority list. t T > > On 1.6.15 9:11, Tor-Admin wrote: > I have to agree with that, multicore support is really important and > should be on the top of the priority list. > > On Tue, 02 Jun 2015 11:13:13 -0400 > 12xBTM <12xbtm(a)gmail.com> wrote: > Improving multi-core support can allow users to saturate high bandwidth > connections with cheaper processors, less setup, and just more efficient > deployment of high-capacity nodes in general. Improving multi-core > support should be a major priority. > > Date: Tue, 2 Jun 2015 20:31:56 +0500 > From: Roman Mamedov <rm(a)romanrm.net> > Sure but I doubt anyone contests that it's better to have multicore support, > than to not have it. However that work doesn't get automatically done. The work is currently listed in Trac in: https://trac.torproject.org/projects/tor/ticket/1749 https://trac.torproject.org/projects/tor/ticket/7572 teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Re: [tor-relays] Multi-core Support
by teor 02 Jun '15

02 Jun '15

> Date: Tue, 2 Jun 2015 20:31:56 +0500 > From: Roman Mamedov <rm(a)romanrm.net> > > On Tue, 02 Jun 2015 11:13:13 -0400 > 12xBTM <12xbtm(a)gmail.com> wrote: > >> Improving multi-core support can allow users to saturate high bandwidth >> connections with cheaper processors, less setup, and just more efficient >> deployment of high-capacity nodes in general. Improving multi-core >> support should be a major priority. > > Sure but I doubt anyone contests that it's better to have multicore support, > than to not have it. However that work doesn't get automatically done. > > One quick and simple stop-gap alternative that I suggested some time ago would > be to stop ignoring more than two relays per IP address. > > With the IPv4 shortage and abundance of multi-core CPUs, raising that limit to > let's say 4, would at least allow many people to run a Tor process per core on > the same single IPv4 that they have (utilizing up to four cores, not just two). This was suggested in https://trac.torproject.org/projects/tor/ticket/13414 But the concern was that any increase to 2 relays per IP would make it much easier for sybil attacks. Perhaps we could try an increase to 3 or 4 per IP? teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Multi-core Support
by Thomas White 02 Jun '15

02 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Have there been any updated ETAs concerning the development/support of multi-core for the core tor workloads? If not, is there anything in particular that I could do to speed the process up? Scaling the capabilities of the Tor process would be a huge relief and help for my upcoming project so I am keen to push it through should it be possible to bring up the priority list. t T - -- Activist, anarchist and a bit of a dreamer. Keybase: https://keybase.io/thomaswhite PGP Keys: https://www.thecthulhu.com/pgp-keys/ Current Fingerprint: BA81 407C BD61 CD15 E5D9 ADA9 5FA2 426F F34E 0FD4 Master Fingerprint: DDEF AB9B 1962 5D09 4264 2558 1F23 39B7 EF10 09F0 Twitter: @CthulhuSec XMPP: thecthulhu at jabber.ccc.de XMPP-OTR: 77E6C8C6 95FDE863 1172A1E1 8C114C01 691398AC -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVbFLfAAoJEF+iQm/zTg/UxTgP/2iB0gqd1R/h7ME6Zq6DQubM elmg7rtquh9H0NfTJ6/l5y2Y5ipLLZiN9dda+NxAl3RMD0ge0lwawoS8JjVcTsOP p+umbSJi2cy5/d2YWJXqLukLH6KITdza+5d5BMGZvOV9MkQNuPBXpQj9m0QH8lti K4zWH9bNEDWp9w+EHJSz5FcqwvpWhEPYipYdnBUEUO4lfaUlOJOfdHyrktrjD70b jIsz+OaFn7RyV85yMbpfMBH4TvSrdbhpshUKqy5TOPGww2Uupsf2EbAK3jYyelFA ZhENY8c0h39WNtamPImxsrN4dvyrKNt9SXGlGPoVZVCYvNH0/8/2MEPtdr9xYt3+ ntarnmDFi5+nqUHlzYn8flJv7h4o01CCNaueirE3IQJr7RC5sYBIIY38+ejO0sXq 4iAXraB2YeOhRvOLDrMMdAQP+6811/1bgH4tSNHV1XxW4BQJAjPxi5KSLe/+13S1 MaVoBvpxURT2O/QFQN8SOKKv5IY0/i78jEOjQpKgdvXMRxlpgycEpMKSRupBntZR OGFof1Hu22IYH6SGwnTBPeM+6Y7VV5VnX2fbPtMEH02Lplok3RZPciAXWtkhQGBn PN1TxLOm6NUtkwc8hEPulHDBamLLKNbQqAbdNfd7G0Bia7KBPQ1WM37FFTHyqaPz 7L4JuvUJ6iHLFob2CQAj =1DfQ -----END PGP SIGNATURE-----

4 4

Re: [tor-relays] Auto-detect and enable IPv6 // Re: Please enable IPv6 on your relay!
by teor 02 Jun '15

02 Jun '15

> Date: Fri, 22 May 2015 19:29:43 +0500 > From: Roman Mamedov <rm(a)romanrm.net> > > On Fri, 22 May 2015 13:31:02 +0000 > Speak Freely <when2plus2is5(a)riseup.net> wrote: > > > Uhh, I would like to point out that it would be exceptionally stupid > > to have Tor autoconfigure IP addresses, regardless of whether it's > > IPv4 or IPv6. > > On IPv4 it currently does. There is zero rationale as to why IPv6 must be > different from IPv4 in this aspect. IP address autodetection is a useful feature for those servers which are dynamically assigned IP addresses. But it's not appropriate in every circumstance, which is why the ORPort and DirPort config options allow an IP address to be specified. It's only in the absence of a configured IP that autodetection is performed. Here are the enhancement requests in trac that need to be completed for IPv6 address autodetection: The enhancement request for Tor autodetecting IPv6 addresses is here: https://trac.torproject.org/projects/tor/ticket/5940 Since Tor normally autodetects its IPv4 address via its first directory request, this requires the directory authorities and/or fallback directories to be on IPv6 answering directory requests: Directory Authorities on IPv6 https://trac.torproject.org/projects/tor/ticket/6027 Fallback Directories on IPv6 https://trac.torproject.org/projects/tor/ticket/8374 Fallback Directories Initial Release on IPv4/IPv6 https://trac.torproject.org/projects/tor/ticket/15775 Clients/Relays will also need to query directory servers on both IPv4 and IPv6 to autoconfigure both addresses. Currently, directory requests are only made using the default IP protocol, or IPv4 (I'm not sure which). Once these client and server changes are in place, we then need to test clients to ensure they will bootstrap correctly: * When clients are on IPv4 only, mixed IPv4/IPv6, and IPv6 only; (3) Combined with: * On first run and subsequent runs; (2) Combined with: * When the directory authorities are available on IPv4 only, IPv4/IPv6, and IPv6 only; * When the directory authorities aren't available, and Fallback Directories are available on IPv4 only, IPv4/IPv6, and IPv6 only; (6) Combined with: * Using HTTP (DirPort) and Tunneled (ORPort) directory fetches. (2) 4 4/6 6 a4 Y Y f a4/6 Y Y Y a6 f Y Y f4 Y Y N f4/6 Y Y Y f6 N Y Y Y = Yes, Tor should bootstrap f = Tor should use other authorities or fallback directories with matching IP version(s) N = Tor should fail to bootstrap if it doesn't have access to any directories with matching IP version(s), and it doesn't have a recent consensus. Otherwise, it should find a directory with a matching IP version. This may involve a tunneled directory request if DirPorts are not available but ORPorts are, and Tor has enough information to tunnel over an ORPort (this might not apply in the first run case). That's a lot of different combinations that we need to test and ensure they work as intended. And I am concerned about the complexity of the "N" case. We'd appreciate any help on these IPv6 enhancements, particularly coding the server-side changes, as it's difficult to code and test the client-side changes without them. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Re: [tor-relays] How to use our own TOR relay as entry node for local network hosts
by teor 02 Jun '15

02 Jun '15

> Date: Sun, 24 May 2015 08:47:20 +1000 > From: Zenaan Harkness <zen(a)freedbms.net> > >> 3. Disable the polipo proxy on the Tor relay in your network, you do >> not need that. Run a bridge instead of a relay. Make it a non public >> bride (PublishServerDescriptor 0) and run Tor Browser on all the >> computers in your network with UseBridges 1 and define the ip:port of >> your bridge and connect it directly, no proxy setting. This way other >> 'strangers' won't be able to use your bridge and you will also not >> need the Guard flag or uptime and bandwidth requirements. > > That last bit (UseBridges 1, configure bridge IP), looks like it does > the job needed here, no new Tor config options required. There are 3 different ways to set up your local bridge, each with their own pros and cons: 1. Configure a private bridge * Only your clients use this bridge * No cover traffic 2. Configure a bridge distributed by BridgeDB * Your clients and other clients may use your bridge as the first hop * BridgeDB doesn't distribute all bridges straight away, so you may or may not get cover traffic * You can't separately rate limit external and local traffic at the bridge itself - RelayBandwidthRate includes all bridge traffic 3. Configure the server as a relay, but configure the clients to connect to it as a bridge * If you configure a client with a mandatory guard relay using EntryNodes and StrictNodes, the relay must have and maintain the guard flag. But configuring clients with a relay server in a "bridge" config line avoids the need for a guard flag. * Your clients use this bridge, as do other clients as at least a middle hop, and a guard or exit hop depending on flags * You get the most cover traffic this way * You can't separately rate limit external and local traffic at the bridge itself - RelayBandwidthRate includes all relay and bridge traffic * This mode of operation is less common, and may reveal some bugs in Tor. In my experience it has worked fine for months with 0.2.5 - 0.2.7-alpha, but please report any issues on https://trac.torproject.org/projects/tor/ticket/1776 * As a precaution, if you ever reconfigure a relay Tor node as a bridge Tor node, please delete the keys so it appears as a new bridge in BridgeDB. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

IPv6 adress valid?
by tor-server-creator＠use.startmail.com 01 Jun '15

01 Jun '15

hi, is that IPv6 adress valid for example "becks" [2a01:4f8:162:7345::2]? how do i know if IPv6 is correct and reachable? thanks

4 3

[warn] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server.
by Martin Ekendahl 29 May '15

29 May '15

This morning I rebooted my relay after some patching. I was running 2.6.7 on Ubuntu 14.04.2 LTS from. The server is always a bit slow rebooting but when it came back up always check the Tor relay and now I see an excessive amount of these errors: May 29 12:20:36.000 [warn] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 906; recommendation warn; host CC23B32FA040945FF49D94AC3D4334429CB4E2CD at 62.75.241.71:1110) May 29 12:20:36.000 [warn] 905 connections have failed: May 29 12:20:36.000 [warn] 849 connections died in state connect()ing with SSL state (No SSL object) May 29 12:20:36.000 [warn] 42 connections died in state handshaking (TLS) with SSL state unknown state in HANDSHAKE May 29 12:20:36.000 [warn] 8 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN May 29 12:20:36.000 [warn] 2 connections died in state handshaking (TLS) with SSL state SSL negotiation finished successfully in OPEN May 29 12:20:36.000 [warn] 2 connections died in state handshaking (TLS) with SSL state SSLv3 read server hello B in HANDSHAKE May 29 12:20:36.000 [warn] 1 connections died in state handshaking (TLS) with SSL state SSLv3 read finished A in HANDSHAKE May 29 12:20:36.000 [warn] 1 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in CLOSED I still see about 7000 inbound connections and 3000 outbound, I'm not sure what my connection average is, but the current bandwidth being used is below average (from the reboot). There have been a couple DDOS alerts from my ISP the past couple days, something I never used to get. I can confirm via my dashboard nothing has been mitigated so I assume no filtering is going on, and traffic is still coming and going, but for some reason there are a lot of connections not being made it appears from the logs, and these only started appearing after I restarted my server/relay. Any ideas what would be causing all these issues?

1 0

Get bridge
by Victor Victoe 28 May '15

28 May '15

2 1

Re: [tor-relays] Leaseweb exit relay notice
by tor＠t-3.net 25 May '15

25 May '15

On 05/25/2015 08:17 PM, Rejo Zenger wrote: > ++ 25/05/15 12:48 -0400 - tor(a)t-3.net: >> >> A lot of trouble would be prevented for exit node operators if, when they >> brought their relays up for the first time, they ensured that the exit policy >> rejected port 25. Even if they desire to run as unrestricted a relay as >> possible, in my experience, that one really should be rejected. It is the > > Some (or most or even all) of the Leaseweb nodes didn't forward port 25. > So, alltough you advice is a good one, it's not applicable to some (or > most or even all) of the nodes that are discussed in this thread. > I'd be curious to know what this checker says about the IP address that ultimately got this ISPs attention: http://mxtoolbox.com/blacklists.aspx I run 2 fast exits with only ports 25 and 465 rejected. I find that the IPs are in some expected lists that target Tor, plus barracuda and spamhaus-zen. But not a gigantic pile of RBLs like was being described. No sorbs, no spamcop, no uceprotect. Nothing like a real spamming box. Doing nothing on email ports but still ending up on a meaningful number of RBLs doesn't sound right. Maybe all it took to piss the ISP off was for one of them to do it.

2 1

Re: [tor-relays] Leaseweb exit relay notice
by tor＠t-3.net 25 May '15

25 May '15

On 05/22/2015 12:19 AM, Speak Freely wrote: > The problem is compounded by the fact each BL company is racing it's way > to the bottom, adding each others finds to their own lists. SpamHaus has > OVER 1 *BILLION* addresses listed. > > I lost several relays (11) from OVH because DanTor recorded my relays, > then CBL recorded DanTor, then SpamHaus Zen recorded CBL, which allowed > OVH to claim "100% of your IPs are blacklisted on multiple lists" when > in reality it was from a guy in the UK who publishes all Tor relays - > guard, middle, exit - that caused this whole problem for me. Not one > single complaint from anyone against any of my relays. > > > Matt > Speak Freely > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays A lot of trouble would be prevented for exit node operators if, when they brought their relays up for the first time, they ensured that the exit policy rejected port 25. Even if they desire to run as unrestricted a relay as possible, in my experience, that one really should be rejected. It is the port which email servers tend to use to deliver mail to one another, and some bad/old clients might try to use it as well. In theory, open-relay port 25 is just about sending email. It can send email on behalf of anyone in the world. Big deal, right? But in practice, open-relay port 25 is all about spam. Has been for years and years. It's always been abused by awful spammers wherever it may be found. It's never been used as some great tool for anonymity or email freedom. As far as Tor exits go specifically, there is someone out there who is apparently watching Tor for when exits appear that are willing to send on port 25. They very quickly begin dumping spam out of any such relays, should they appear. I know this because I briefly turned on relay for port 25, and the spammers found it fast. They immediately transformed it into a spam-vomiting heap of crap. Traffic graphs on it skyrocketed (although within the configured maximums). The new mail in the admin mailbox for the netblock clearly reflected what the box was doing. I closed that port off fast, and problem solved. In addition to port 25, relay operators who want to be extra careful of their relationship with their ISP may also wish to reject ports 465 and 587. Doing that would more-completely lock the Tor exit away from the tricks spammers use. By blocking off the email portion of the relay (especially port 25), the machine doesn't spew spam, and therefore doesn't get noticed by those who are trying to stop spam. This is good for the relay because the 'net is more accepting of it (IP reputation lists, RBLs, etc), and good for the exit relay operator's working relationship with the hosting ISP. Reputable ISPs tend to dislike spam, and if a billion spam complaints flood in for your relay, it's not going to help your cause. People who are trying to do anonymous email have means to do so which do not include dumping anything directly to port 25. And if a direct push from Tor to 465 or 587 is wanted, it can always go to the relays which don't perceive any ISP-related risk from it.

2 1

[Fwd: Re: a line "enable IPv6 on your relay"]
by tor-server-creator＠use.startmail.com 25 May '15

25 May '15

sorry, i confused something. "relay should show in the consensus as an "a" line." does not mean a "a" is required in torrc. i got confued cause of the headline "1.1 Ordinary relays" stupid me, pardon -------------------------- Original-Nachricht -------------------------- Betreff: Re: [tor-relays] a line "enable IPv6 on your relay" Von: yl <tor(a)yl.ms> Datum: Sonntag, 24. Mai 2015 19:54 An: tor-relays(a)lists.torproject.org Am 24.05.2015 um 19:25 schrieb tor-server-creator(a)use.startmail.com: > shouldnt there be a "a" in the first line? how important ist the > letter > a? i guess some operators just added the lines without "a" like > above. > additional: how many ipv6 relays are up NOW? and are there plans to > include a button into torbrowser to enable/disable ipv6? Not sure where the a should be put, so maybe someone can just past a sample config with the IPv6 enabled, I think from that we can substitute easily. One question also, is this for relay servers or ONLY for exit enabled servers? yl _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 1

a line "enable IPv6 on your relay"
by tor-server-creator＠use.startmail.com 24 May '15

24 May '15

hi, about that following lines in the mail from Moritz Bartl. [tor-relays] Please enable IPv6 on your relay! > In short, you add: > ORPort [IPv6::address]:port > IPv6Exit 1 > ExitPolicy reject6 *:* shouldnt there be a "a" in the first line? how important ist the letter a? i guess some operators just added the lines without "a" like above. additional: how many ipv6 relays are up NOW? and are there plans to include a button into torbrowser to enable/disable ipv6? thanks

2 1

Complaint being on a tor dnsbl..
by 0x23 23 May '15

23 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hey guys, Today I got a complaint from my vServer hoster that has received an abuse email The company who accused the usage of my system is called sectoor http://www.sectoor.de/tor Here's the abuse message: More Information About Sectoor Listing on the Sectoor TOR DNSBL indicates that this IP address is a tor node or a subnet (/24) containing a tor node. This listing *does not* indicate that your IP address has been blacklisted by Sectoor, as this list also contains subnets that contain a tor node. The subnet listing is not designed to block connections, but rather for use as a scoring mechanism. Your IP will only be blacklisted if it is the tor node itself and listed by Sectoor Exitnodes. Sectoor TOR DNSBL lists every IP address which is known to run a tor server and allow their clients to connect to one of the following ports: * Port 25 * Port 194 * Port 465 * Port 587 * Port 994 * Port 6657 * Ports 6660-6670 * Port 6697 * Ports 7000-7005 * Port 7070 * Ports 8000-8004 * Port 9000 * Port 9001 * Port 9998 * Port 9999 More information about SECTOOR can be found at their website: http://www.sectoor.de/tor.php *Reason for listing - **TOR Server Network detected (TOR Node on ip xxxxxxxxxxx) - see http://www.sectoor.de/tor.php for more information.* What would you reply on that accusation? I tried to convey that this isn't true and that this company only tries to alienate me as a customer cause there also running vServer offers. For now I reject using these ports..:-( Regards - -- -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQIzBAEBCgAdBQJVYGegFhwweDIzIDxydXNoMjNAZ214Lm5ldD4ACgkQF7zsyb8G Yjgxwg//c4+j6BNmr7wzyxuH3C0T3iQMrF9gK5vfdU2nyRBSV4Hqbb8zIIc1+eQy 9XMqD+tZ0uUKtT6Q+Ket1y6zqCvX1fX4NpEMN6DWMyyRCnDa1m/AOU04PQpr6VIS TzZc93BYCv+Sw8Rdt24XyRRJ9u05vehY4fkjX4qgiGp9zZDgkpZsO06qzDa4zBXb 5oHRMlO2Q2ePYAsl53E78JUMD7+rphBdUmogGU0xpEWysBSFMGCMqQt6g5+zwqtB HABL95S85UKj1mZ3vj0kbi3/jMJYG0vL5+zqBvzUFIU5NlOrz0DFKG/O8uG8h6gA avyxzdpwtBIox/FYkNG2TWeJ00RscKJ/1u33WATwOTL0x5VkIehP9Njl7pnz4cO4 4SkpV7SSGAhqPVnVPvEcYLPBGuqZAyNV/0r0GZZUdQEC0J8+BsQgf77vr5vC4yTz P2/Fj5BVzhT2UxpNtRfFnhGu+KNmXbyiVJ17jDxNfeEl7uuDRgFCMc+Vg0fvl2LY mAOZuTwUyxbl+6Gyeob66RdSmhNERr8vGvGCv1TKvFuwry2hrQI5HFRiQpssGsHX k19Z4S999jBe8fdz4EevYMMwI1phWnT3eOoSJDc4jKkClrrYgTXqU1w0riMcyPGP wMo4gHv2Ie9dBki4VC4JXDGXCqehp9dyNjKwmEp5UTzPwO45bZE= =K+EM -----END PGP SIGNATURE-----

3 2

Auto-detect and enable IPv6 // Re: Please enable IPv6 on your relay!
by Roman Mamedov 22 May '15

22 May '15

Hello, > We still have a depressingly low number of relays that support IPv6 > (currently only ~120 of ~1900 relays). If your host supports IPv6, > please enable it, especially if you run an exit! This has to be done > explicitly. If you (supposedly) care so much, then can you please make it automatic? There is no need to explicitly put the ____IPv4____ address into the torrc. And there is no need to explicitly put the IPv6 address into the config file of virtually any other IPv4+IPv6 supporting software I can think of: web, mail, NTP, XMPP servers, those are all capable of automatically figuring out which IPs the host has. Can't think of any reason of why this has to be otherwise in Tor, aside from perhaps a certain lack of understanding of best IPv6 implementation practices from the Tor developers side and/or nobody simply giving much thought to this yet. I currently run 15 Tor relays, 14 of those IIRC are IPv6 capable. But since you did not bother to make enabling IPv6 in Tor anywhere near user-friendly [1], I am simply not going to bother pecking the IPs into each torrc individually. [ One of the practical reasons being that I sometimes need to migrate the Tor 'identity' (torrc + /var/lib/tor/*) between machines and providers with v4/v6 addresses obviously changing. ] Aside from migrations between providers, the requirement to specify the IP is also impractical in many other situations, e.g. my ISP at home provides only a __dynamic__ IPv6 subnet which changes to a different one with each new PPPoE session. [1] Ideally there should be no 'enabling' at all!!! IPv6 should be active by default, IF the relay has determined it is able to make a successful IPv6 connection with a dir-authority -- oh and also that's how you can discover the actual working IPv6 address to use; or at least with a simple "IPv6Relay 1, but certainly with no requirement of specifying the IP address in the config file. -- With respect, Roman

2 2

Leaseweb exit relay notice
by blaatenator 21 May '15

21 May '15

Hi all, FYI: Yesterday I got the notice below from Leaseweb. I picked them because Leaseweb is mentioned in the Good/Bad ISP <https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs> post. Apparently a blacklist named SECTOOR added a whole IP block of Leaseweb to block my Exit relay. Since this list is used by some bigger corporations, it got some other customers in trouble and they asked me to restrict the mentioned ports. I understand the reasoning and can't blame them for asking my I guess (and since most relevant ports are not mentioned I guess it is not too bad), but I found it a bit weird that a whole subnet is being listed. On 05/20/2015 03:20 PM, Lesley Koomen wrote:> Dear sir, madam, > > It appears you are hosting a TOR node on your LeaseWeb IP address. > This has resulted in the block of a (part) LeaseWeb IP subnet. (/24) > As the subnet is added on the SECTOOR blacklist > (http://www.sectoor.de/tor.php) this is affecting customers in the same > range as yourself. > > The SECTOOR blacklist is e.g. implemented by Hotmail, Live and Gmail. > This results in other customers not being able to longer use the mail > services of these companies. > Sectoor TOR DNSBL lists every IP address which is known to run a tor > server and allow their clients to connect to one of the following ports: > > * Port 25 > * Port 194 > * Port 465 > * Port 587 > * Port 994 > * Port 6657 > * Ports 6660-6670 > * Port 6697 > * Ports 7000-7005 > * Port 7070 > * Ports 8000-8004 > * Port 9000 > * Port 9001 > * Port 9998 > * Port 9999 > > > Therefore, we kindly, yet urgently ask you to disable the connection to > the mentioned ports within 24 hours. Failure to comply and respond > (confirm) to this warning, will result in a block of your involved IP > address(es). > > Thank you for your co-operation and understanding. > > > > Kind regards, > > Lesley Koomen > Team Manager Abuse Prevention

8 10

HOWTO: deliver tor-exit-notice_DE.html over ipv6 port 80 too
by Toralf Förster 21 May '15

21 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 B/c ipv6 of Tor implements currently no DirPort I copied+pasted together the following solution to deliver a Tor exit notice over HTTP port of ipv6 too : The python snippet runs under a non-privileged user w/o login shell : $ cat ipv6-httpd.py import socket from BaseHTTPServer import HTTPServer from SimpleHTTPServer import SimpleHTTPRequestHandler class MyHandler(SimpleHTTPRequestHandler): def do_GET(self): return SimpleHTTPRequestHandler.do_GET(self) class HTTPServerV6(HTTPServer): address_family = socket.AF_INET6 def main(): server = HTTPServerV6(('::', 8181), MyHandler) server.serve_forever() if __name__ == '__main__': main() The ip6table rules to redirect fort 80 from outside to the local non-privileged port : from=80 to=8181 $IPT -t nat -A PREROUTING -i enp3s0 -p tcp -m tcp --destination-port $from -j REDIRECT --to-ports $to $IPT -A INPUT -p tcp -m tcp --destination-port $to -j ACCEPT And finally the script to start it during boot : $> cat /home/simplehttp/ipv6-httpd.sh #!/bin/sh # d=$(mktemp -d /tmp/XXXXXX) &&\ cd $d &&\ cp /etc/tor/tor-exit-notice_DE.html ./index.html &&\ nice python ~/ipv6-httpd.py 1>./log 2>&1 :-) - -- Toralf pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlVeC48ACgkQxOrN3gB26U59HwD8CwnBIpZOkq8tN01ciWsZQh7c FO42AGmkkhCI/CbucnYA/j3zSq1wJzuHgMdWZUbQCQvHt+KEYkobdNkcHqkK3mWE =FA7E -----END PGP SIGNATURE-----

1 1

[warn] Tried to establish rendezvous on non-OR or non-edge circuit.
by Cmar433 21 May '15

21 May '15

Hi people .. i yesterday started IPV6 but now i see in log following messages periodically part of my torrc below. I only add ipv6 lines. Any idea ? or its normal ? Thanks Cmar ORPort 37.157.192.208:443 ORPort [2a02:2b88:2:1::3a62:1]:9050 ## If you want to listen on a port other than the one advertised in ## ORPort (e.g. to advertise 443 but bind to 9090), you can do it as ## follows. You'll need to do ipchains or other port forwarding ## yourself to make this work. #ORPort 443 NoListen #ORPort 127.0.0.1:9090 NoAdvertise ## The IP address or full DNS name for incoming connections to your ## relay. Leave commented out and Tor will guess. Address 37.157.192.208 ## If you have multiple network interfaces, you can specify one for ## outgoing traffic to use. OutboundBindAddress 37.157.192.208 info from log: May 19 22:42:03.000 [notice] Average packaged cell fullness: 99.082% May 19 22:42:03.000 [notice] TLS write overhead: 3% May 19 22:42:03.000 [notice] Circuit handshake stats since last time: 118791/118793 TAP, 161141/161141 NTor. May 19 23:13:45.000 [warn] Tried to establish rendezvous on non-OR or non-edge circuit. May 20 03:08:03.000 [warn] Tried to establish rendezvous on non-OR or non-edge circuit. May 20 03:33:54.000 [warn] Tried to establish rendezvous on non-OR or non-edge circuit. May 20 04:42:03.000 [notice] Heartbeat: Tor's uptime is 18:00 hours, with 4375 circuits open. I've sent 211.07 GB and received 203.24 GB.

3 2

BWauth kookiness
by starlight.2015q2＠binnacle.cx 20 May '15

20 May '15

Some possible fallout related to the earlier discussion [tor-relays] amount of unmeasured relays continuously rising since 2 weeks https://lists.torproject.org/pipermail/tor-relays/2015-May/007003.html My relay Binnacle 4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2 has 9375 Kbyte (75 Mbit) of unfuzzy (no ISP traffic shaping) bandwidth, but in the last few days the BWAuths' opinion went from # gabelmoo # tor26 # moria1 # longclaw bw1-w Bandwidth=7382 Measured=7100 *bw2-w Bandwidth=7382 Measured=9330 bw3-w Bandwidth=7382 Measured=13700 GuardFraction=69 bw4-w Bandwidth=7382 Measured=23700 to bw1-w Bandwidth=9375 Measured=17100 bw3-w Bandwidth=9375 Measured=77900 GuardFraction=75 *bw4-w Bandwidth=9375 Measured=23000 * selected for consensus While it's flattering to be promoted to double the actual capacity, with the potential to go 8x, I suspect it's may not a great idea in the grand scheme of things. And to think at one time I was feeling short-changed. . . FYI BWauths Regards

2 2

Tor Consensus Weight Stuck at 20 (Even on Relay with "Stable" Flag)
by Neel Chauhan 19 May '15

19 May '15

Hi, I have a Tor relay (https://atlas.torproject.org/#details/342587A287603040A49BB364D72EAC0B6BC3D…) running from a FreeBSD server at my house on with a 5 megabit upstream connection. I have seen that lately, Tor's "Consensus Weight" value on this relay has not been going anywhere above (or below) 20. My relay has gotten the "Stable" flag, but yet didn't see it's consensus weight value rise. I decided to look at https://consensus-health.torproject.org/, and saw that two of the four bandwidth consensus servers, namely tor26 (86.59.21.38) and longclaw (199.254.238.52) don't seem to be calculating any consensus value for Tor relays in the last few days. Has anyone else been having this problem? And if the Tor consensus operators are reading this, (approximately) when would this problem get resolved? Thanks, Neel Chauhan

8 17

Tor relay/btc node script
by torelay 18 May '15

18 May '15

I've written my first script. It is to automate the process of setting up a tor relay/bridge (published or not) and a bitcoin full node (with hidden service url and/or clearnet ip) on a fresh debian os. The script is at https://github.com/mktx-code/relay-node. To write it I used a combination of the sky-ip tuts and random github codes for syntax and structuring. Please give me any comments criticisms. Appreciated.

2 1

Re: [tor-relays] Windows Tor Server Guide
by Ben Serebin 18 May '15

18 May '15

Hi there... 1st post (I figured after years of donating to EFF, I should run a tor relay). I've searched and read many posts on tor-relays and the best Windows Tor Server Guide I found was this below one by Rafael Rodriguez. A few questions, and apologies if they seem silly, but there is scant info out there for us Windows admins. - is a web server needed? - the below email post had the slashes stripped from the path entries which makes it tricky to follow (talk about an annoying mail-list process). Overall, throw all the files in a single dir? - before I load it as a service, once all files and config the "torrc" can I just launch the tor.exe and then test it's working? - is this the only way to run a relay on Windows? Hoping there's a special approach to simplify the process (now I know why there aren't more of them). Thanks, -Ben Rafael Rodriguez rafaelr at icctek.com Wed Nov 5 00:47:46 UTC 2014 Previous message: [tor-relays] Windows Tor Server Guide Next message: [tor-relays] Windows Tor Server Guide Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Hi, here is it. Please, feel free to contribute to it. RUNNING A TOR SERVER IN WINDOWS - Download latest Tor Browser Bundle. - Install to c:tor - Create a temporary folder on your Desktop and name it "server". - Copy all files from C:TorBrowserTorBrowserDataTor to the "server" folder on the Desktop. - Browse to C:TorBrowserTorBrowserTor; delete the folder "PluggableTransports" and it content. - Copy all files from C:TorBrowserTorBrowserTor to the "server" folder on the Desktop. - Browse to C:Tor and delete everything inside that folder. C:Tor should be completely empty at this point. - Move all files from the "server" folder on your Desktop to C:Tor - Browse to C:Tor and create a new folder named "datadir". - Create a new text file in C:Tor named "notices" (I myself use notices.log but we want to keep it simple for users who may not know how to change the file extension from .txt to .log) - EDIT C:TORTORRC FILE: (this could be the torrc-defaults file and all its comments). Note that the sample below is just for references. Each user needs to define her/his own parameters based on their own needs and that's impossible for me to cover in a single file for everyone. Hence, each parameter should be included in the torrc-defaults with due comments to be used as reference. Also, noted that I'm using IPv4 geoip by default. Users using IPv6 should define geoip6 in their torrc file. Then again, I cannot use a single sample file for all deployments. The defaults file should be used as reference once again. DATADIRECTORY .DATADIR LOG NOTICE FILE .NOTICES.TXT GEOIPFILE .GEOIP AvoidDiskWrites 1 SocksPort 0 ORPort 9001 DirPort 9030 ExitPolicy reject *:* Nickname RelayBandwidthRate RelayBandwidthBurst Up until this point, all I've written is nothing more than using the default Tor Bundle to create a "Server" package. All steps above could be made easier for users if a "Tor Windows Server" package was available for download on the Tor Project or somewhere else. I refuse the idea of creating such package myself to distribute it since many packages could start floating on the net and bad intentioned people could bundle them with arbitrary code, viruses and so on. A Windows Installer package can be built for distribution though. Next, I will address the two main things we need to run tor as a Windows service (server): 1- Install Tor as Windows Service. 2- Security (Isolating the Tor service). INSTALL TOR AS WINDOWS SERVICE I personally use nssm [2] (Non-Sucking Service Manager) myself to register the service but feel free to use default Windows tools for registering Tor service if you believe so. Anyways, irrespective the tool used to register the Tor service, we just need the following: Service: C:Tortor.exe Name: TorServer Parameters: -f C:Tortorrc Start the TorServer service and everything should just work at this point. The datadir directory will be populated with tor files once started and the notices.txt file will also reflect so. SECURITY (Quick explanation - We can go into details later) - Create a Standard user account and name it Tor with a strong password. - Policies: 1- Deny access to this computer from the network 2- Deny log on locally 3- Deny log on through Remote Desktop Services - NTFS Permissions for Tor windows user account: 1- Read/Write permissions to datadir folder 2- Read/Write permissions to notices.txt or (notices.log) file - Open Services, Start -> Run -> type "services.msc" without quotes, press enter and your Services window will pop up. Scroll down and find the TorServer service and double click it. Move to the LOG ON tab and set the "Log on as: This account: .TOR. Enter the strong password for the Tor user account in the password field and apply changes. Restart the service and now Tor will be running in its own isolated/limited account in Windows.

2 3

Job for tor.service failed.
by tor-server-creator＠use.startmail.com 14 May '15

14 May '15

hi there. 0.2.5.12 on debian jessie: "service tor reload" causes message: "Job for tor.service failed. See 'systemctl status tor.service' and 'journalctl -xn' for details." it says something like "failed to start LSB"? any advice for me please? cheers

3 3