- tor-relays - lists.torproject.org

OVH Mitigation
by Dr Gerard Bulger 10 Sep '20

10 Sep '20

I know we should dilute our dependence on OVH, but cheap and seem to ignore the fact the machine is an exit node. OVH has a seemingly patented a system to deal with denial of service attacks. I am not sure what they detect but when they do we get this: "We have just detected an attack on IP address x.x.x.x. In order to protect your infrastructure, we vacuumed up your traffic onto our mitigation infrastructure. The entire attack will thus be filtered by our infrastructure, and only legitimate traffic will reach your servers. At the end of the attack, your infrastructure will be immediately withdrawn from the mitigation" To be fair, the automated system takes it off after an our or two. If my tor server is left in this mitigated state, the tor exit gets labelled a BAD EXIT which is something to avoid as takes days to be trusted again. As soon as I get their email I now stop TOR to prevent that embarrassing label, and perhaps doing so stops whatever it is OVH is detecting. Being shutdown for a few hours seems better than being a bad exit. Gerry

3 2

Could Zoom be using the wrong dan-tor blacklist
by Eddie 07 Sep '20

07 Sep '20

Starting yesterday (maybe Saturday) we have been unable to initiate any Zoom calls. They just sit "connecting". According to Zoom, there are no issues that would lead to this. My investigation, traces I have run on the server, and using a VPN (on a tablet on my LAN) show the exact same symptoms I had a year (or so) ago with a couple of AT&T sites, which I eventually narrowed down to being caused by the same blacklist by routinely switching IPs and then eventually shutting down my relay temporarily. Is anyone else seeing similar and/or have any suggestions as I rather not have to shut my relay down. Running a multitude of VPNs on my internal machines is not really an option and my relay isn't going to function if I throw a VPN on my server. Cheers.

1 0

How many threads needed for unbound at a fast relay?
by Toralf Förster 05 Sep '20

05 Sep '20

I do wonder about a reasonable number. -- Toralf

3 3

Re: [tor-relays] Tor relay marked "false positive" from NCSC-FI
by Peter Gerber 03 Sep '20

03 Sep '20

Hi tschador(a)posteo.de: > today my ISP received an abuse report from > ncsc-fi-autoreporter(a)traficom.fi [1]: > --- > The information below is presented in the following format: > ASN | IP | TIMESTAMP (UTC) | PTR/DNAME | CC | TYPE | CASE | INFO > > 24940|95.217.16.212|2020-09-01 07:27:48 > +0000|95.217.16.212|DE|malweb|1130659|Datasource: b, Url: > hxxp://95.217.16.212/tor/server/fp/23ad6b165137d957c09aa0f7a3ee7b05cec4a8f2, > Http Request: GET, Additional Information: This host is most likely > serving a malware URL., Artifact Hash: 69b9e2721018f0ebaebf901d98d8c9b9 > --- > The ip belongs to my non-exit relay. [2] There is no action required for > me, but I wonder why they mark traffic on the dirport as 'malware'? I've received a similar mail not too long ago. Looking into it, I couldn't but conclude that it was some sort of phishing scam. When following the link one was asked to provide a lot of information. The webpage seems to be outdated, incomplete and nowhere was explained why they'd scan the internet for anything. All in all, the page looked as "phishy" as it gets. For reference, below is the abuse mail I received. Regards Peter -------- Forwarded Message -------- Subject: Fwd: Abuse Message [AbuseID:730BD4:2C]: AbuseCleanMXInfo: [clean-mx-viruses-172313691](95.216.14.206)-->(abuse(a)hetzner.de) viruses sites (1 so far) within your network, please close them! status: As of 2020-08-09 16:47:16 CEST Date: Sun, 09 Aug 2020 16:48:21 +0200 From: abuse(a)hetzner.com Reply-To: abuse(a)hetzner.com To: <removed> Dear Mr Peter Gerber, For your information we are forwarding you the email of the ticket [AbuseID:730BD4:2C]. The source email with details about the issue is attached to this email. Important note: When replying to us, please leave the abuse ID [AbuseID:730BD4:2C] unchanged in the subject line. Kind regards Abuse department Hetzner Online GmbH Industriestr. 25 91710 Gunzenhausen / Germany Tel: +49 9831 505-0 Fax: +49 9831 505-3 abuse(a)hetzner.com www.hetzner.com Register Court: Registergericht Ansbach, HRB 6089 CEO: Martin Hetzner, Stephan Konvickova, Günther Müller For the purposes of this communication, we may save some of your personal data. For information on our data privacy policy, please see: www.hetzner.com/datenschutzhinweis On 09 Aug 16:47, abuse(a)clean-mx.de wrote: > Dear abuse team, > > please have a look on these perhaps offending viruses sites(1) so far. > > Notice: We do NOT urge you to shutdown your customer, but to inform him about a possible infection/misbehavior ! > > status: As of 2020-08-09 16:47:16 CEST > > Please preserve on any reply our Subject: [clean-mx-viruses-172313691](95.216.14.206)-->(abuse(a)hetzner.de) viruses sites (1 so far) within your network, please close them! status: As of 2020-08-09 16:47:16 CEST > > > http://support.clean-mx.de/clean-mx/viruses.php?email=abuse@hetzner.de&resp… > > (for full uri, please scroll to the right end ... > > This information has been generated out of our comprehensive real time database, tracking worldwide viruses URI's > > If your review this list of offending site(s), please do this carefully, pay attention for redirects also! > Also, please consider this particular machines may have a root kit installed ! > So simply deleting some files or dirs or disabling cgi may not really solve the issue ! > > Advice: The appearance of a Virus Site on a server means that > someone intruded into the system. The server's owner should > disconnect and not return the system into service until an > audit is performed to ensure no data was lost, that all OS and > internet software is up to date with the latest security fixes, > and that any backdoors and other exploits left by the intruders > are closed. Logs should be preserved and analyzed and, perhaps, > the appropriate law enforcement agencies notified. > > DO NOT JUST DELETE THE FILES. IF YOU DO NOT FIX THE SECURITY > PROBLEM, THEY WILL BE BACK! > > You may forward my information to law enforcement, CERTs, > other responsible admins, or similar agencies. > > +----------------------------------------------------------------------------------------------- > > |date |id |virusname |ip |domain |Url| > +----------------------------------------------------------------------------------------------- > |2020-08-09 16:05:31 CEST |172313691 |PUA.Win.Trojan.Generic-6629274-0 |95.216.14.206 |95.216.14.206 |http://95.216.14.206/tor/status-vote/current/consensus-microdesc/0232af+14c131+23d15d+27102b+49015f+d586d1+e8a9c4+ed03bb+efcbe7.z > +----------------------------------------------------------------------------------------------- > > > Your email address has been pulled out of whois concerning this offending network block(s). > If you are not concerned with anti-fraud measurements, please forward this mail to the next responsible desk available... > > > If you just close(d) these incident(s) please give us a feedback, our automatic walker process may not detect a closed case > > explanation of virusnames: > ========================== > unknown_html_RFI_php not yet detected by scanners as RFI, but pure php code for injection > unknown_html_RFI_perl not yet detected by scanners as RFI, but pure perl code for injection > unknown_html_RFI_eval not yet detected by scanners as RFI, but suspect javascript obfuscationg evals > unknown_html_RFI not yet detected by scanners as RFI, but trapped by our honeypots as remote-code-injection > unknown_html not yet detected by scanners as RFI, but suspious, may be in rare case false positive > ...javascript.insert Please pay attention for script code after </html> > unknown_exe not yet detected by scanners as malware, but high risk! > all other names malwarename detected by scanners > ========================== > > > yours > > Gerhard W. Recher > (CTO) > > net4sec UG (haftungsbeschraenkt) > > Leitenweg 6 > D-86929 Penzing > > GSM: ++49 171 4802507 > > Geschaeftsfuehrer: Martina Recher > Handelsregister Augsburg: HRB 27139 > EG-Identnr: DE283762194 > > w3: http://www.clean-mx.de > e-Mail: mailto:abuse@clean-mx.de > PGP-KEY: Fingerprint: A4E317B6DC6494DCC9616366A75AB34CDD0CE552 id: 0xDD0CE552 > Location: http://www.clean-mx.de/downloads/abuse-at-clean-mx.de.pub.asc

1 0

anyone else with this issue?
by niftybunny 30 Aug '20

30 Aug '20

Daily DDOS love the last 14 days … https://imgur.com/a/rfu0OUA <https://imgur.com/fCsIv6V> even for my standards, thats a shit-ton of sockets … Tor DDOS protection is configured but I get more connections than I can drop … nifty

7 9

ubuntu focal and Tor
by potlatch 28 Aug '20

28 Aug '20

Question: What's with the failure when installing Tor of the "no valid keys" for focal? I've had to back up to ubuntu 18 several times. --potlatch-- Sent with [ProtonMail](https://protonmail.com) Secure Email.

1 0

Hello CypherpunkLabs Tor relays
by nusenu 25 Aug '20

25 Aug '20

Hello CypherpunkLabs, I noticed your set of new relays and wanted to say hi, welcome you to the Tor relay community and give you a few recommendations and pointers especially since you are aiming to run 100 tor relays. The Tor relay guide has a lot of useful information, so you probably want to start there: https://torproject.org/relay-guide Since all your current relays appear to be OVH based I'd like to point out the following quote from the guide: > Try to avoid the following hosters: > > OVH SAS (AS16276) > Online S.a.s. (AS12876) > Hetzner Online GmbH (AS24940) > DigitalOcean, LLC (AS14061) https://community.torproject.org/relay/technical-considerations/ The reasoning behind this, is that those hosters are already hosting many tor relays, and the network dislikes centralization. OVH is the biggest commercially available tor hoster in terms of exit capacity today already. Depending on your per-relay size you might end up running a big fraction of the network and especially big exit operators are encourage to take care of their DNS resolution. Specific guidelines can be found here: https://community.torproject.org/relay/setup/exit/ IPv6 connectivity is also encouraged (which currently none of your relays appear to have). Especially for big operators it is recommended to managed their relays using configuration management (puppet, salt, ansible, ...) and update them regularly. An ansible role for Tor relay operator (I maintain) can be found at: https://github.com/nusenu/ansible-relayor The ContactInfo Information Sharing Specification is a spec about a machine readable ContactInfo string: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification Your site suggests that you (will) run bridges and exits. Combining these two types of nodes under a single operator is generally a bad idea since tor's MyFamily configuration is not supported for bridges, so users might end up using your bridges _and_ your tor exits - which puts them at risk should someone compromise you, please consider running non-bridges only. For strong protections for your long term relay keys you can use tor's OfflineMasterKey feature, especially relevant if your run a big fraction of the network: https://2019.www.torproject.org/docs/tor-manual.html.en#OfflineMasterKey kind regards, nusenu PS: don't forget about your MyFamily setting if you do not choose a solution that manages that for you automatically. -- https://mastodon.social/@nusenu

2 1

IPv6 Support or Uptime?
by Josh Lawson 23 Aug '20

23 Aug '20

I have IPv6 with my ISP, but there seems to be a bug in the firmware of my networking equipment that causes IPv6 to stop working periodically and I have to take my network down and bring it back up. If I do not do this, my relay stops functioning as I have torrc configured to use IPv6 and IPv4. So, my question is whether or not having a higher uptime is more important or having IPv6 support? My relay never goes down when on IPv4 only. I apparently cannot have both until the firmware bug is fixed. I appreciate it!

4 4

Tor bandwidth scanner "longclaw" slow to the US West Coast
by Neel Chauhan 23 Aug '20

23 Aug '20

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. This includes two Tor exit instances on a dedicated server hosted in Los Angeles on Psychz Networks (AS40676): https://metrics.torproject.org/rs.html#details/156AAC3FAD1ACC8906316519DCB4… https://metrics.torproject.org/rs.html#details/A69CEB30328B1E85C6B167FECAF2… And two Tor non-exit instances on a home server in Seattle on Wave Broadband (AS11404), using a symmetrical Gigabit link: https://metrics.torproject.org/rs.html#details/B0F9BA27944FA59E3B1A182208FF… https://metrics.torproject.org/rs.html#details/DB710B14D7329B7289CFCC547F48… The consensus weight values from longclaw are much lower than other North American bandwidth scanners, according to https://consensus-health.torproject.org/. This also affects other relays/ISPs on the West Coast US/Canada, such as Emerald Onion, AT&T U-verse, Sonic.net, and QuadraNet. The same ISPs/hosts in the East Coast aren't affected. This discrepancy in the measurement disproportionately favors European and East Coast US/Canada relays at the expense of West Coast relays, centralizing the Tor network even further than it already was. This wasn't an issue in the past, even as early as a few months ago. It only started appearing around June. Is anyone else hosting West Coast relays having this issue? Is "longclaw" actually measuring bandwidth from Europe? If so, WHY? I got in contact with "longclaw"'s admin and he wasn't too helpful. Best, Neel Chauhan === https://www.neelc.org/

4 4

Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)
by nusenu 23 Aug '20

23 Aug '20

Hi, here is my motivation for working on automated verification of operatorurls in ContactInfo: https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in… -- https://mastodon.social/@nusenu

9 16