Re: [tor-relays] Reapply exit policy on reload

[lists]

On Samstag, 10. August 2024 14:38:27 CEST George Hartley via tor-relays wrote:
> I am very well aware of that and how it works, I have seen your commit that
> got merged, and am a C/C++ programmer as well.
> 
> Nevertheless, this is a feature I wanted anyway, so I could just reload the
> config and block IP's or even ranges if SSH range / portscans are done
> using my exit.

You've always been able to do that, my script does it several times a day. 
Every 10 minutes if necessary.

But that has nothing to do with 'ReevaluateExitPolicy 1'.
This has now been explained several times in this thread


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Reapply exit policy on reload

[lists]

On Samstag, 10. August 2024 05:25:51 CEST George Hartley via tor-relays wrote:

> If this is a client to guard detection only, then why does my exit node also 
block a significant amount of DoS (I had around the same statistics when my 
guard probability fraction was still zero, so clearly something is working):

- It says so in the man page from 2019 that you linked above.

- And well, an exit is also a guard, an HsDir, Intro, Rdv and whatever else.


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Reapply exit policy on reload

[lists]

On Samstag, 10. August 2024 00:58:29 CEST George Hartley via tor-relays wrote:
> Then these must be targeted attacks, as I have never encountered something
> like this during 10 years of relay operation under different providers and
> aliases.

Of course, these are targeted attacks and have been extreme since the Ukraine 
war.
If a handful of servers of large relay orgs with hundreds of relays are 
brought down,
it can affect 20-30% of the total exit traffic.

The attacks pushed the Junipers to their limits and the entire IX was at risk.

In the next few days I can show a live example of targeted hidden service 
attacks.
2 hs are currently public in the client software and are being attacked.
2 more will be added tomorrow and I am sure that DDoS will start shortly 
after.
You can see this very clearly in PoW metrics on Grafa.

https://db4n0nym3.grafana.net/public-dashboards/
71ad3412bfde44058993dccb07a5e593

> Sorry, but the Tor logs that I am seeing suggest that most DoS gets
> mitigated.

You can't see everything in the Tor logs. 
Toralf has developed some tools to better monitor relays.
Specifically ddos-inbound.sh helped me to develop rules.
https://github.com/toralf/torutils

> As far as I know, the concurrent connection (not circuit!) DoS defense is
> relatively new, so give the developers some time.
> 
> Also, any default IPTables rule-set should automatically either reject or
> just drop connections above a certain threshold.

That's why we have developed dynamic IP/NFtables rules for the guards.
The whole story began here:
https://gitlab.torproject.org/tpo/community/support/-/issues/40093
For Tor exits, the policy reject is of course more effective.

And from 10-20G you can no longer use conntrack. Linux does not scale.
You can't do much with table inet filter.
I drop the most stubborn IPs with ethtool using NIC hardware filtration.
The rest with nftables dynamic sets in the ingress hook before prerouting.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Reapply exit policy on reload

[lists]

On Dienstag, 30. Juli 2024 18:34:44 CEST George Hartley via tor-relays wrote:
> I would definitely want to be able to change my exit policy by just sending
> a simple "kill -SIGHUP $pid".
> 
> So yeah, consider myself interested in this functionality.
> 
> But, don't we already have that implemented?
> 
> I remember changing my exit policy then doing "systemctl reload tor" and
> after a few hours, Metrics showed that SSH was now also rejected.

It's not about changing the exit policy via reload. Yes, that's always been 
possible.

It's about killing _existing_ connections that are currently DOSing us.

Example: 500K connections from IP 1.2.3.4
You create the reject policy,
ExitPolicy reject 1.2.3.4/32:*
do a reload and the _existing_ connections are terminated.

In order for this to work you have to use the new config option:
ReevaluateExitPolicy 1   # (Default 0)


And of course a version of Tor in which trinity's commit was merged ;-)

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opening metrics-api.torproject.org for testing

[lists]

On Freitag, 2. August 2024 17:49:01 CEST Toralf Förster via tor-relays wrote:
> On 8/2/24 17:38, Hiro wrote:
> > We are now opening NSA for testing
> 
> May I ask, what the abbreviation "NSA" means?

Network Status API

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Hardware sizing for physical exit node

[lists]

On Mittwoch, 10. Juli 2024 00:32:04 CEST Osservatorio Nessuno via tor-relays 
wrote:

> we are planning to get some hardware to run a physical Tor exit node,
> starting with a 1Gbps dedicated, unmetered uplink (10Gbps downlink). We
> will also route a /24 on it, so we will have large availability of
> addresses to run multiple instances. We have been running a few exit
> nodes so far, but never on our own hardware.

Your bottleneck is the 1G uplink.
For comparison, I have 2x Xeon E5-2680v2 10C/20T and 256Gb RAM
2x 10G nic (LACP bond) and I can not achieve 10G throughput with it.
As a rule of thumb, I would always count one instance per thread or core.
I have 40T and 40 tor exit instances.

F3Netze has specified the hardware in Contact info:
https://metrics.torproject.org/rs.html#search/185.220.100.

> Which is the bandwith limit per core/Tore instance? Or what can we
> expect to be the bottleneck?

That depends on the CPU clock speed. Fast Ryzen or Epyc's can do 50-70 MiB/s 
per core/instance.

> Due to some other requirements we need for some experiments (SFP ports,
> coreboot support, etc) we can mainly choose between these 2 CPUs:
>   Intel i5-1235U
>   Intel i7-1255U
> 
> The cost between the two models is significant enough in our case to
> pick the i7 only if it's really useful.
> 
> In both cases with 32GB of DDR5 RAM (we can max to 64 if needed, but is
> it?).
> 
> Should this allow us to saturate the uplink?

Guards need more resources than exits since the introduction of congestion-
control and because of DDoS I would use 64GB RAM for a guard.
With your IP space and 1G uplink, I would take the i5 with 32Gb, save the 
money and maybe add a second server later. Or if you build the hardware 
yourself, look for a used Epyc or Ryzen server. 16 or 32 core with high _base_ 
clock. Used server hardware from the data center is like new.

> To summarize, with this bandwith, this hardware and a /24 how many Tor
> exit nodes should be ideal to run considering that each of them could
> have their own address?

https://metrics.torproject.org/rs.html#search/185.220.101.
We are 5 relay orgs sharing a /24. Currently 5x 2x10G(or 25G)
With now 8 relays per IP, over 2000 instances can run in a /24 subnet. It 
would be nice if you share the subnet with 1-2 other relay operators.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] DDOS alerts from my provider

[lists]

On Montag, 8. Juli 2024 19:34:51 CEST Rafo (r4fo.com) via tor-relays wrote:
> But this week I’ve received 2 DDoS alerts from my provider
> (Netcup), both are ~3 gigabits. They seem to be coming from other Tor
> relays.I’m running an Invidious like instance on my server (which uses
> around 600 megabits) but I have a 2.5 gigabit port. So I configured my Tor
> relay to use 300-400 megabits.I’m not sure where that 3 gigabit of data
> comes from.I have lowered my advertised bandwidth to 100 megabits, would
> that be enough to prevent these kind of issues?Kind regards,Rafo

Reducing the advertised bandwidth does not help. ;-) In general, one tor 
instance will rarely reach 100 megabits.

There is little you can do on the server against targeted DDoS. But you can 
stop IPs with a lot of connections to your tor daemon using dynamic exit 
police¹ or dyn. IP/nftable rules². For targeted help, you should specify the 
type of relay you have and your OS.

https://gitlab.torproject.org/tpo/community/support/-/issues/40093

¹https://github.com/artikel10/surgeprotector

²https://forum.torproject.org/t/is-tor-network-resistant-to-tcp-syn-flood-dos-attacks-from-outside-of-tor/12690/4

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Metrics 'Running' flag is back for bridges who don't publish the OrPort

[lists]

Oh, the fix only lasted 23 hours. ;-)
'Running' flag is gone again.


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Tor Metrics 'Running' flag is back for bridges who don't publish the OrPort

[lists]

I don't know if this was mentioned at the Tor Relay Meeting yesterday, if so, 
I missed it. ;-)

A few months ago there was a recommendation to not exposing OrPort for 
bridges.
This had the unpleasant effect that all bridges were 'red' on Tor Metrics, 
even though they were running perfectly fine.
I noticed yesterday after the meeting that everything is 'green' again.
https://metrics.torproject.org/rs.html#search/ForPrivacyNET

Thank you, I believe these 6 people did that:
https://gitlab.torproject.org/tpo/network-health/team/-/issues/318


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Onion Services operators please enable tor PoW defense

[lists]

On Mittwoch, 5. Juni 2024 14:50:20 CEST gus wrote:
> Hi,
> 
> As some of you might have noticed, we have a high load situation on the
> network for a couple of weeks now affecting in particular onion services
> (but not only them).[1]
> 
> We recommend Onion Services operators to enable our Proof of Work (PoW)
> defense[2][3] and finetune their torrc[4].
> 

As a little help, defaults from 0.4.8.11

### IntroDoSDefense & PoWDefenses are disabled by default
#
# https://community.torproject.org/onion-services/ecosystem/technology/pow/
# More details, see: 'man torrc' DENIAL OF SERVICE MITIGATION OPTIONS
# Tor Network values set by the consensus, if any, can be found here:
# https://consensus-health.torproject.org/#consensusparams

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 80 [::1]:80

# HiddenService options are per onion service:
HiddenServiceEnableIntroDoSDefense 1
#HiddenServiceEnableIntroDoSBurstPerSec 200 # (Default: 200)
#HiddenServiceEnableIntroDoSRatePerSec 25   # (Default: 25)

HiddenServicePoWDefensesEnabled 1
#HiddenServicePoWQueueRate 250  # (Default: 250)
#HiddenServicePoWQueueBurst 2500# (Default: 2500)
#CompiledProofOfWorkHash auto   # (Default: auto)

HiddenServiceDir /var/lib/tor/other_hidden_service/
HiddenServicePort 22 127.0.0.1:22
HiddenServicePort 22 [::1]:22
HiddenServiceEnableIntroDoSDefense 1
...


For larger websites and forums like Dread:
https://blog.nihilism.network/servers/endgame/index.html

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relay migration

[lists]

On Dienstag, 4. Juni 2024 23:24:50 CEST Roger Dingledine wrote:
> On Tue, Jun 04, 2024 at 04:42:50PM +, Eldalië via tor-relays wrote:

> > I have to move somewhere else a a (middle) relay I have been running for a
> > few years. It will be down for 2-4 weeks, then be back online in a
> > different location, with different ISP, at better speed. But it will run
> > on the same hardware and software. Should I keep the same keys, or start
> > from scratch?

> Having a relay downtime of 2-4 weeks though could really increase the
> time until you get flags like Guard back, due to some design flaws in
> how the directory authorities track stability. (The simple version of the
> issue is: we treat downtime as much more serious than not-existing-yet.)

Thanks for the info, Roger.

@Eldalië If you want to keep your history on Tor metrics, go with the old 
keys.
If you generate new keys and have a new IP, you can let your relay run as a 
bridge for a few weeks or months and then reconfigure it later. That would be 
very helpful, especially if the IP is accessible from Turkmenistan. It's been 
a year, but internet censorship is still there:
https://forum.torproject.org/t/tor-relays-help-turkmens-to-bypass-internet-censorship-run-an-obfs4-bridge/7002/8#torrc-example-6

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Updating tor issue

[lists]

On Freitag, 3. Mai 2024 18:17:41 CEST Keifer Bly wrote:
> System is up to date, I run apt-get update regularly.

Did you even only read 2 sentences from the link?
Buster is EOL and will be completely archived in a few weeks.
> > https://www.debian.org/releases/buster/
Debian is 2 releases ahead!
You won't get 3rd party packages (tor) anymore.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Updating tor issue

[lists]

On Freitag, 3. Mai 2024 17:00:44 CEST Keifer Bly wrote:

> What is the correct format for adding tor as a trusted source?
A not outdated system. ¹AFAIK obfs4proxy for buster (oldoldstable) has had a 
security hole for a long time and you are putting your users at risk!

> deb-src http://deb.debian.org/debian buster main
> deb http://security.debian.org/ buster/updates main
> deb-src http://security.debian.org/ buster/updates main
First upgrade the system. buster -> bullseye -> bookworm
https://www.debian.org/releases/buster/

https://www.debian.org/releases/bullseye/releasenotes
https://www.debian.org/releases/stable/releasenotes

Reinstalling might be easier.

¹Upgrading your old system & obfs4proxy was recommended here 2-3 years ago.
Somehow you're going around in circles.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Backdoor in upstream xz/liblzma leading to ssh server compromise

[lists]

On Samstag, 30. März 2024 01:02:54 CEST he...@relaymagic.org via tor-relays 
wrote:
> Just wanted to bring this to everyone’s attention if you hadn’t seen it
> already. Developer discovered a backdoor in xz-utils
> https://www.openwall.com/lists/oss-security/2024/03/29/4

Pretty unlikely that anyone uses testing or sid for productive servers.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor is not upgrading via apt from deb.torproject.org

[lists]

On Montag, 19. Februar 2024 00:27:04 CET s7r wrote:
> Peter Palfrader wrote:
> 
> > 
> > our gitlab-ci has not managed to build a tor nightly in ages.
> > 
> 
> 
> Thank you for stepping in! No better person to ask :)
> 
> The upgrade via apt from nightly used to work every time, back since 
> Debian Wheezy. It stopped to work since ~ autumn 2023.

Thanks to David everything is working again.
https://gitlab.torproject.org/tpo/core/tor/-/issues/40861
https://gitlab.torproject.org/tpo/core/tor/-/issues/40918
'Disable a sandbox unit test that is failing on Debian Sid'

I just upgraded some relays.

> > unless our gitlab-ci actually manages to build a whole set, you won't
> > see packages on deb.tpo.
> > 
> > cf.
> > 
> > https://gitlab.torproject.org/tpo/core/debian/tor/-/pipelines?scope=all&pa
> > ge=1&ref=debian-main
 
> > some of these are actual tor building issues,
> > like https://gitlab.torproject.org/tpo/core/debian/tor/-/jobs/479068
> > 
> > 
> > | sandbox/opendir_dirname: [forking]
> > | 
> > |   FAIL ../src/test/test_sandbox.c:266: opendir: Operation not permitted
> > |   [1]
> > |   [opendir_dirname FAILED]
> > | 
> > | sandbox/chmod_filename: [forking] OK
> > 
> > 


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Problem with relay and ovh??

[lists]

On Sonntag, 18. Februar 2024 01:42:30 CET Keifer Bly wrote:

Every few months the same question with the same log messages :-(

> 00:36:35.000 [warn] You are running Tor as root. You don't need to, and you
> probably shouldn't.
^^Still not fixed.

> Feb 18 00:36:34.640 [notice] Opening OR listener on [::]:9001
> Feb 18 00:36:34.640 [notice] Opened OR listener connection (ready) on [::]9001
IPv6 is not configured in torrc.
If anything is unclear, 'man torrc' helps. Search|grep 'Address' & 'ORPort'

> Feb 18 00:36:50.000 [notice] Unable to find IPv6 address for ORPort 9001.
> You might want to specify IPv4Only to it or set an explicit address or set or 
> set Address.
The error message is clear and precise.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor is not upgrading via apt from deb.torproject.org

[lists]

On Donnerstag, 15. Februar 2024 13:54:51 CET s7r wrote:

> I have recently found something interesting on my relays. On all relays 
> and clients actually.
> 
> As always I am using Debian and apt to get Tor from deb.torproject.org 
> tor-nightly-main-bullseye main (for example). I also have the keyring 
> installed, proper key and everything.
> 
> Currently I am on:
> 
> Tor version 0.4.9.0-alpha-dev.
Mee too.

I let nightly's upgrade automatically, but not stable.
Therefore I have the following config in
/etc/apt/50unattended-upgrades

Unattended-Upgrade::Origins-Pattern {
...
// Update TorProject's nightly dev packages: (Suite & Codename: 
tor-nightly-main-bookworm)
//   apt-cache policy | grep release
"o=TorProject,a=tor-nightly-main-bookworm,n=tor-nightly-main-bookworm";
};

> 
> If I manually check out deb.torproject.org with my browser I see there 
> is another package released in February 2024, except it notes as the 
> same version 4.9.0-alpha-dev but it has a different timestamp.
> 
> $ apt update reports no errors, looks like is working fine, but it 
> doesn't notify there's a newer version and does not apply any updates to 
> Tor. This happens only to Tor package from nightly, rest of packages 
> from debian.org deb are updated as usual.
> 
> So, anyone else experienced this?

Damn, you're right:

http://deb.torproject.org/torproject.org/dists/tor-nightly-main-bullseye/InRelease
Suite: tor-nightly-main-bullseye
Codename: tor-nightly-main-bullseye
Date: Fri, 09 Feb 2024 11:28:02 UTC
Valid-Until: Wed, 20 Mar 2024 11:28:02 UTC

root@boldsuck:~# apt update
root@boldsuck:~# apt-cache show tor
Package: tor
Version: 0.4.9.0-alpha-dev-20230909T020422Z-1~d12.bookworm+1

So I also have the last version from September 9th, 2023,
although one from February 9th, 2024 is in the archive. :-(
Tor stable update is OK.

Full log output:
https://paste.debian.net/1307420/

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relay in AT marked as DE in metrics

[lists]

On Mittwoch, 31. Januar 2024 19:50:13 CET Carlo P. via tor-relays wrote:

> I have a relay on 152.53.17.183 / 2a0a:4cc0:1:1333::beef which is listed as
> "German" in metrics.torproject.org, but actually it is in Austria 

Was just a topic here recently:
https://lists.torproject.org/pipermail/tor-relays/2024-January/021472.html

Ask geofeed from the provider and submit a bug report.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] A new kind of attack?

[lists]

On Montag, 15. Januar 2024 23:19:37 CET Chris Enkidu-6 wrote:
> 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
> 
> 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

This seems to be related to what we already had in September:
https://forum.torproject.org/t/excessive-unbalanced-relay-traffic/9291

It is always only intermittent and only some off my relays are affected.
https://forum.torproject.org/t/excessive-unbalanced-relay-traffic/9291/8

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Dutch Relays

[lists]

On Dienstag, 19. Dezember 2023 16:23:27 CET Jordan Savoca via tor-relays 
wrote:
> On 12/18/23 6:59 AM, ab...@relayon.org 2023 wrote:
> > These are complete and utter shit.
> > 
> > avoid like the plague!
> > 
> > nifty
;-) You've landed in the sun again, I envy you.

> Oh? I'm curious to hear more about your reasons/experience, if you're
> open to sharing. They're pretty well-regarded in networking spaces.

ColoClue is nice if you have _low_ traffic and want to learn about routing 
BGP, OSPF... Artikel10 has server running there.

Christopher Sheats could ask for traffic prices at
https://serverius.net/colocation/server-colocation/

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Metrics

[lists]

So you don't have to dig through the logs:
(as root or sudo)
~# cat /var/lib/tor/pt_state/obfs4_bridgeline.txt
~# cat /var/lib/tor/fingerprint

or with multiple instances:
~# cat /var/lib/tor-instances/NN/pt_state/obfs4_bridgeline.txt

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] WebTunnel: What ASNs/networks work best?

[lists]

On Montag, 14. August 2023 16:40:09 CEST Jordan Hillis wrote:
> Can I get a copy of the webtunnel-bridge Docker image and
> documentation? Thanks

https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel#server-setup
More info in the last (June 24) Tor Relay Operator Meetup notes.


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Middle relay IP blocking

[lists]

On Dienstag, 8. August 2023 00:30:38 CEST Gary C. New via tor-relays wrote:

> In addition to network diversity, there is the fact that most individuals
> find it necessary to run an at Home internet connection 24 x 7 x 365. So...
> Other than for the reasons inspired by the subject of this post, why not
> just run a low-resource consuming Tor server at home, too,

Most people definitely have the router on all the time. I saw this recently 
because I wanted to run a bridge for Turkmenistan at home:
On Ubiquity EdgeOS Router (Vyatta/Debian based) you can 'apt install tor'
OPNsense (FreeBSD based): https://docs.opnsense.org/manual/how-tos/tor.html



-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Middle relay IP blocking

[lists]

On Montag, 7. August 2023 22:28:32 CEST s7r wrote:

> While all the above is true, a thing to remember is to make sure we 
> don't end up all renting too many VPS'es or dedicated servers in the 
> same places / same AS numbers - we need network diversity,
Especially at the exits, which unfortunately occur in a few places and in 
large heaps. Approx 50%: Berlin Germany, Utrecht Netherlands, Roost 
Luxembourg.

> it is a very 
> important factor, more AS numbers, more providers, more physical 
> locations, etc. So, running at home is super good and recommended from 
> this perspective, provides us with the diversity we need,

You made a good list of underused ISP's on lowendtalk and on nusenu's 
OrNetStat there are over 500 AS where only 1 or 2 relays are running. There 
should be enough data centers in the world to achieve diversity even without 
running at home.
https://nusenu.github.io/OrNetStats/#autonomous-systems-by-cw-fraction

Runnig snowflake @home is a nice option. Many relays @home only have kbit/s of 
bandwidth. In my humble opinion, a Tor relay should offer at least 10 MB/s.

> however who can afford the 
> hassle should definitely run a middle relay or bridge at home
Yes, anyone with a good internet connection at home can do this.
At least in Germany, every ISP offers its customers a http & ftp proxy. Use 
them in your browser or OS. This might have less of a problem running Tor 
relays at home. Because most websites will then see the proxy IP.

> (even Exit 
> relay, I do run an Exit relay at my office place and I had one police 
> visit in like 8 years or so).
@office is different than @home. I wouldn't advise anyone to run an exit at 
home.
It's no fun when the cops ring at 6:00 am and search your whole apartment. And 
if you're unlucky, they take all computers, cell phones and other 'things'.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Middle relay IP blocking

[lists]

On Samstag, 5. August 2023 08:40:42 CEST Marco Predicatori wrote:
> secureh...@gmail.com wrote on 8/4/23 01:46:
> > I tried reporting a similar issue a few months ago (post wasn’t approved
> > by
> > moderator). I was running a relay from my home ISP. After a short while
> > certain websites became inaccessible from other computers in my home
> > network that shared the same public IP. After trial and error with other
> > IP addresses (non-Tor) I realized commercial gateway services had
> > blacklisted our IP address.
> 
> Same here, middle node. In order to access some sites, I have to shut down
> briefly my modem in order to obtain a new IP, and for a while all goes
> smoothly again.

Hi @all,

Just my 2 cents. Is this worth the hassle?
Calculate your power consumption 24x7x30 @home.

For 1-5$ you can get a VPS.
This exit has 1GB RAM and 1CPU and costs $3.50/month
https://metrics.torproject.org/rs.html#details/376DC7CAD597D3A4CBB651999CFAD0E77DC9AE8C

Search or ask for offers on LEB & LET:
https://lowendbox.com/
https://lowendtalk.com/discussion/185210/tor-relay-bridge

$websearch: cheap vps unlimited bandwidth
IONOS 1,-EUR/Month - 1GB RAM - 1vCore unlimited bandwidth - prepaid (=no 
contract term)
https://www.ionos.de/server/vps

Dedicated server for $15 per month: 4 Cores/4 threads - 16GB DDR3 - 5 usable 
IPv4  :-)
https://www.nocix.net/cart/?id=261

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Help Turkmens to bypass Internet censorship: run an obfs4 bridge!

[lists]

On Dienstag, 1. August 2023 23:22:12 CEST Gary C. New via tor-relays wrote:

> The failure logs and metrics are going to be confusing to new obfsbridge
> operators. I suppose documenting this on the obfsbridge setup page will
> have to be sufficient in the interim; along, with pointing them to the
> bridgedb metrics page.

regarding this, Meskio just created an isue
https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/129

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Help Turkmens to bypass Internet censorship: run an obfs4 bridge!

[lists]

On Dienstag, 1. August 2023 23:22:12 CEST Gary C. New via tor-relays wrote:
> On Tuesday, August 1, 2023, 10:54:40 AM MDT,  wrote:
> 
>  On Montag, 31. Juli 2023 23:06:54 CEST Gary C. New via tor-relays wrote:
> >> Please let me know, if you are able to get the OBFS4
> >> bridge working without exposing the ORPort. Respectfully,
> >
> > Yes, that's working
> 
> Great News!
> 
> > == Announcements ==
> > rdsys is ignoring the running flag now :)
> > * To hide your bridge's ORPort:
> > ORPort 127.0.0.1:auto>
> > AssumeReachable 1
> 
> Per Roger's comment in the Issue, it sounds like I can simply firewall
> incoming connections to the ORPort and add the AssumeReachable 1 directive
> to the torrc? Is that correct?
I am currently forwarding OBFS4 port and ORPort on my router. At the moment it 
is more important that I find an IP with Gus that can be reached from 
Turkmenistan. At the weekend I will test with unused bridges whether the 
ORPort is needed or not.

> > The previously mentioned logs and the Tor metrics showing the bridge as
> >offline can be ignored.

> The failure logs and metrics are going to be confusing to new obfsbridge
> operators. I suppose documenting this on the obfsbridge setup page will
> have to be sufficient in the interim; along, with pointing them to the
> bridgedb metrics page.

We should note that this is a new feature which has yet to be tested.

Gus wrote to me:
"But, it's still a new feature and I don't know if it will break something.
Can you check if the number of connections/users drops and if bridgeDB
assign your bridge to a new distribution method? Let me know if
something breaks!"


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Help Turkmens to bypass Internet censorship: run an obfs4 bridge!

[lists]

On Dienstag, 1. August 2023 19:21:08 CEST Toralf Förster wrote:
> On 8/1/23 18:54, li...@for-privacy.net wrote:
> 
> > == Announcements ==
> > rdsys is ignoring the running flag now :)
> > * To hide your bridge's ORPort:
> > ORPort 127.0.0.1:auto
> > AssumeReachable 1
> 
> 
> I do assume I can ignore this log message ? :

Yes ;-)
Unfortunately, they come every 1-2 hours

>   "Aug 01 17:18:19.000 [warn] The IPv4 ORPort address 127.0.0.1 does not 
> match the descriptor address . If you have a static public IPv4 
> address, use 'Address ' and 'OutboundBindAddress '. If you 
> are behind a NAT, use two ORPort lines: 'ORPort  NoListen' 
> and 'ORPort  NoAdvertise'.",


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Help Turkmens to bypass Internet censorship: run an obfs4 bridge!

[lists]

On Montag, 31. Juli 2023 23:06:54 CEST Gary C. New via tor-relays wrote:

> Please let me know, if you are able to get the OBFS4
> bridge working without exposing the ORPort. Respectfully,
Yes, that's working

All Info about this new feature:
Anti-censorship team meeting notes, 2023-06-29
https://forum.torproject.org/t/orport-127-0-0-1-auto/8470
https://lists.torproject.org/pipermail/tor-project/2023-June/003642.html

== Announcements ==
rdsys is ignoring the running flag now :)
* To hide your bridge's ORPort:
ORPort 127.0.0.1:auto
AssumeReachable 1

The previously mentioned logs and the Tor metrics showing the bridge as offline 
can be ignored.
https://metrics.torproject.org/rs.html#details/E6709F6130C61638400F27FAC6358E3412790F72

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Help Turkmens to bypass Internet censorship: run an obfs4 bridge!

[lists]

On Montag, 31. Juli 2023 00:55:15 CEST Gary C. New via tor-relays wrote:
> On Sunday, July 30, 2023, 3:30:55 PM MDT, li...@for-privacy.net  wrote:
> > I don't know if I should ignore that or better configure it that >way:
> > ORPort 127.0.0.1:8443 NoListen
> > ORPort 8443 NoAdvertise
> > ORPort [::1]:8443 NoListen
> > ORPort 8443 NoAdvertise
> 
> Other way around:
> ORPort 8443 NoListen
> ORPort 127.0.0.1:8443 NoAdvertise

Uh thanks, Gus replied me PM 'I can just ignore the logs' and bridge is 
running with:
ORPort 127.0.0.1:8443
AssumeReachable 1

But I want to test the new obfsbridges future 'only expose obfsports and not 
ORPort' next days with different configs. You saved me from a stupid pitfall ;-)

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Help Turkmens to bypass Internet censorship: run an obfs4 bridge!

[lists]

On Freitag, 21. Juli 2023 18:07:35 CEST gus wrote:

> New update: In the last few weeks, internal political conflicts and
> other events[1] in Turkmenistan have led to another wave of censorship
> on Tor and anti-censorship tools. Tor bridges have been one of the few
> free alternatives for people in Turkmenistan to connect with the world
> and access the open Internet.
> 

I stopped snowflake and now a bridge is running on my dynIP.

> 
> ## torrc example
> 
> BridgeRelay 1
> ORPort 127.0.0.1:auto
> AssumeReachable 1
> ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
> ServerTransportListenAddr obfs4 0.0.0.0:8080
> ExtORPort auto
> Nickname helptm
> ContactInfo 
> Log notice file /var/log/tor/notices.log
> # If you set BridgeDistribution none, please remember to email
> # your bridge line to us: frontd...@torproject.org
> BridgeDistribution none

But I have that in the log :-(
Jul 30 16:48:29 t520 Tor-01[93466]: The IPv4 ORPort address 127.0.0.1 does not 
match the descriptor address  203.0.113.18. If you have a static public IPv4 
address, use 'Address ' and 'OutboundBindAddress '. If you are 
behind a NAT, use two ORPort lines: 'ORPort  NoListen' and 'ORPort 
 NoAdvertise'.
Jul 30 16:48:29 t520 Tor-01[93466]: The IPv6 ORPort address ::1 does not match 
the descriptor address 2001:db8:1234:1::::. If you have a 
static public IPv4 address, use 'Address ' and 'OutboundBindAddress 
'. If you are behind a NAT, use two ORPort lines: 'ORPort  
NoListen' and 'ORPort  NoAdvertise'.

I don't know if I should ignore that or better configure it that way:
ORPort 127.0.0.1:8443 NoListen
ORPort 8443 NoAdvertise
ORPort [::1]:8443 NoListen
ORPort 8443 NoAdvertise

I'm aware of
https://gitlab.torproject.org/tpo/core/tor/-/issues/40208
I hope to get it done with scipting on my Mikrotik, or switch to ipv4 only.

frontd...@torproject.org has no PGP key, can I send you or meskio the 
bridgeline?

Bridgeline must be:
Bridge obfs4 :  cert=abra+kadabra iat-mode=0
But DynIP changes every few days. Do you also give the bridge users 
myrouter.example.net?

Because of your post in the forum:
https://forum.torproject.org/t/orport-127-0-0-1-auto/8470
should we do this with all running bridges, or only the hidden ones?

-- 
Ciao Marco!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Wrong "first seen" flag for bridges at metrics.torproject.org

[lists]

On Montag, 17. Juli 2023 20:12:34 CEST telekobold wrote:

> I have an issue regarding the "first seen" flag at
> metrics.torproject.org: It is definitely wrong for my two bridges - both
> dates are much too close in the past.

> Has anyone observed similar behavior for its relay? (I found it
> meaningful to first ask here before creating an issue.

Yeah, looks like a bug. My approx. 1 year old bridges are all:
First Seen 2023-06-20

https://metrics.torproject.org/rs.html#search/ForPrivacyNETbr

I don't care about the date, the only important thing is that they have users 
and make traffic ;-)

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] (EVENT) Tor Relay Operator Meetup - June 24, 2023 @ 18.00 UTC

[lists]

On Samstag, 24. Juni 2023 18:03:47 CEST li...@for-privacy.net wrote:
> On Dienstag, 20. Juni 2023 23:01:23 CEST gus wrote:
> > Just a friendly reminder that the Relay Operator meetup will happen this
> > Saturday, June 24 at 18 UTC.
> > 
> > ## Agenda
> > 
> > 1. Announcements
> > 
> >  - Tor Relay Operators meetup @ CCCamp 2023!
> >  - More unrestricted snowflake proxies are needed
> >  - Relays EOL (0.4.5.x) removal
> >  - IPv4 limit proposal
> > 
> > 2. Presentation about Webtunnel bridges with Tor Anti-censorship Team
> > 
> > 3. Tor Network Health proposals discussion
> > 
> >  - Meta proposal discussion
> >  - contactinfo proposal discussion
> > 
> > 4. Q&A
> > 
> > https://pad.riseup.net/p/tor-relay-op-meetup-june-keep
> 
> https://pad.riseup.net/ is down :-(
> As an alternative, the 'German riseup' systemli could be taken. systemli.org
> is hosted on its own servers at Community-IX.
> 
> https://pad.systemli.org/p/tor-relay-op-meetup-june-keep

I think gus copied the pad. Thanks. Hidden service link is:
http://mjrkrqnlf26etelsi7zpkqc3dzlrzyurvmd3jksmndarzzbugz5xctid.onion/p/tor-relay-op-meetup-june-keep

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] (EVENT) Tor Relay Operator Meetup - June 24, 2023 @ 18.00 UTC

[lists]

On Dienstag, 20. Juni 2023 23:01:23 CEST gus wrote:

> Just a friendly reminder that the Relay Operator meetup will happen this
> Saturday, June 24 at 18 UTC.
> 
> ## Agenda
> 
> 1. Announcements
>  - Tor Relay Operators meetup @ CCCamp 2023!
>  - More unrestricted snowflake proxies are needed
>  - Relays EOL (0.4.5.x) removal
>  - IPv4 limit proposal
> 
> 2. Presentation about Webtunnel bridges with Tor Anti-censorship Team
> 
> 3. Tor Network Health proposals discussion
>  - Meta proposal discussion
>  - contactinfo proposal discussion
> 
> 4. Q&A
> 
> https://pad.riseup.net/p/tor-relay-op-meetup-june-keep

https://pad.riseup.net/ is down :-(
As an alternative, the 'German riseup' systemli could be taken. systemli.org 
is hosted on its own servers at Community-IX.

https://pad.systemli.org/p/tor-relay-op-meetup-june-keep



-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[lists]

On Sonntag, 11. Juni 2023 13:46:06 CEST xmrk2 via tor-relays wrote:

> Background: I am running a lightning node, lightning is a layer 2 protocol
> to scale Bitcoin. Lightning nodes need to be connected to each other
> ideally 24/7. I was contacted by the operator of another Lightning node,
> complaining that he cannot connect to my node. He is Comcast customer, I am
> not. I was also running a tor relay on the same public IPv4 address.
> 
> 
> Any ideas on how to combat this?
It might help to configure Lightning node as a hidden service.
I offer my Monero and Bitcoin RPC & P2P ports as a hidden service.

And have additionally SocksPort flag 'OnionTrafficOnly' on the client and 
hidden 
service side.
SocksPort 9050 OnionTrafficOnly
# Tell the tor client to only connect to .onion addresses in response to 
SOCKS5 requests on this connection.
# This is equivalent to NoDNSRequest, NoIPv4Traffic, NoIPv6Traffic.

> I was thinking about including some false positives in tor relay list.
I wouldn't do that. I think you'll end up on the bad-relay list in no time.
I would rather write to the Comcast network admins first. Give them good 
examples. E.g. in Germany the ISP's support Tor (NetCologne, Deutsche Telekom, 
...)

Mirror:
https://torproject.netcologne.de/dist/
Our Traffic sponsors:
https://www.community-ix.net/sponsors/

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
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?

[lists]

On Samstag, 3. Juni 2023 18:18:46 CEST Tschador wrote:

> today I found this warning in the log of my relay

> Jun 03 04:04:33.000 [warn] Possible compression bomb; abandoning stream.

> What does this mean?
A simple log message that the tord didn't unpack a Zip Bomp. DDOS protection 
in the Tor software I believe. 
https://en.wikipedia.org/wiki/Zip_bomb

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Configuring key expiration warning messages?

[lists]

On Freitag, 19. Mai 2023 13:55:10 CEST telekobold wrote:

> If there isn't such an option, does anyone happen to have a script
> ready for this (before I start trying to implement something like this
> myself)?

Yes in toralf's /torutils:
https://github.com/toralf/torutils/blob/main/key-expires.py


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] new exit relay

[lists]

On Mittwoch, 12. April 2023 17:14:46 CEST Linux-Hus Oni via tor-relays wrote:
> hi again, actulay i have made my exit to a bridge, so my bandwith is not so
> big for an exit. it is automatically removed from the metrics ?

Get a new IP, you put users at risk!

It doesn't matter, even if your relay no longer appears in metrics after a few 
days every Tor relay IP is in many private and professional databases after a 
few hours.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Police request regarding relay

[lists]

On Mittwoch, 12. April 2023 18:28:09 CEST tor-opera...@urdn.com.ua wrote:
> Finn  wrote:
> > The weird thing is, that the relay in question is only a relay and
> > not an exit node since its creation (185.241.208.179)
> > (https://nusenu.github.io/OrNetStats/w/relay/B67C7039B04487854129A66B16F5E
> > E3CFFCBB491.html) - anyone has an idea how this happens? Best regards
> 
> We receive this mostly from France and Germany. We figured out that
> they downloaded the Tor Browser then looked at the Tor Circuit widget
> and just collected the addresses they could see there.
> 
> This is the same as when Police, Attention Seekers, Cyber White
> Knights, Censors and other scoundrels contact every ISP they see in a
> traceroute.

Without a court order, the cops have no right to request data at all.

Generally also for commercial providers:
The European Court of Justice ruled that German data retention 
(Vorratsdatenspeicherung) is incompatible with EU law and therefore 
inapplicable.

https://digitalcourage.de/blog/2023/vorratsdatenspeicherung-medienberichte
(only in German)

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Police request regarding relay

[lists]

On Dienstag, 11. April 2023 14:09:15 CEST Finn wrote:
> Hello everyone,
> 
> We are hosting multiple relays under our AS 210558 and received an email
> from a local police station in Germany requesting user data, nothing
> unusual.
Nothing unusual? I had a house search because of exits but never a user data 
request because of entry nodes.

As a German organization, you must fully comply with Telekommunikation-
Telemedien-Datenschutz-Gesetz §9 (the German telemedia data protection law), 
which prohibits to log any personally identifiable data or usage data unless 
required for billing purposes. As you do not charge for using your services, 
you will never be able to keep any connection data. ¯\_(ツ)_/¯

Tor routers owned by German media services are protected by Telemediengesetz 
§8

https://www.gesetze-im-internet.de/ttdsg/__9.html
https://www.gesetze-im-internet.de/tmg/__8.html

Updated german exit page
https://github.com/chgans/tor-exit-notice

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Selecting Exit Addresses

[lists]

On Freitag, 31. März 2023 16:56:16 CEST denny.obre...@a-n-o-n-y-m-e.net wrote:
> The second IP is still in "Exit Addresses" with the new configuration ...
> https://metrics.torproject.org/rs.html#details/3B85067588C3F017D5CCF7D8F65B
> 5881B7D4C97C

I don't understand that now either. I have at least 200 relays configured like 
this. I don't understand that now either. I have at least 200 relays configured 
like this with different IP's and subnets. I always set OutboundBindAddresses 
for relays, bridges and HS.

Everything I can think of, it may take up to 24 hours for the 2nd IP to 
disappear from tor metrics.


> torrc:
> 
> Address 209.141.39.157
> OutboundBindAddress 209.141.39.157
> ORPort  9001 IPv4Only


> 
> denny.obre...@a-n-o-n-y-m-e.net wrote ..
> 
> > Thanks Marco.
> > 
> > First, I had to change my ORPort to 9001 with your proposed configuration
> > because using 443 caused an error => "Could not bind to 0.0.0.0:443:
> > Address already in use. Is Tor already running?"
> > Probably because my other Tor instance (hidden service) is using it.
> > 
> > Now I'm just waiting for the metrics to update to see if everything is as
> > expected.
> > 
> > Finally, thanks for the help with IPv6 because I cannot get it to work.
> > Somehow when I try to check IPv6 availability (
> > https://community.torproject.org/relay/setup/post-install/ ), I get
> > "ping6: connect: Network is unreachable". I don't have time to set it up
> > right now (I already spent hours last week) so I'll get back to you for
> > that.
> > 
> > Denny
> > 


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Selecting Exit Addresses

[lists]

Hi denny,

> Hi,
> 
> I just activated my first exit relay. (
> https://metrics.torproject.org/rs.html#details/3B85067588C3F017D5CCF7D8F65B
> 5881B7D4C97C ) I had the following in my torrc (plus some other things):

I've answered the rest to the list.
If you want to enable IPv6 at Frantech/BuyVM:

First create one in Stallion from your given subnet.
This is what my /etc/network/interfaces looks like at Frantech


# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 104.244.73.43/24
gateway 104.244.73.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 127.0.0.1 107.189.0.68 107.189.0.69
dns-search for-privacy.net

iface eth0 inet6 static
address 2605:6400:0030:f78b::2/64
up  ip -6 route add 2605:6400:0030::1 dev eth0
up  ip -6 route add default via 2605:6400:0030::1
down ip -6 route del default via 2605:6400:0030::1
down ip -6 route del 2605:6400:0030::1 dev eth0
dns-nameservers ::1 IPv6ns1 IPv6ns2


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Selecting Exit Addresses

[lists]

On Freitag, 31. März 2023 01:26:42 CEST denny.obre...@a-n-o-n-y-m-e.net wrote:
> Hi,
> 
> I just activated my first exit relay. (
> https://metrics.torproject.org/rs.html#details/3B85067588C3F017D5CCF7D8F65B
> 5881B7D4C97C ) I had the following in my torrc (plus some other things):

Don't forget to write Francisco a ticket. So he knows abuse mails come from a 
tor exit. https://buyvm.net/acceptable-use-policy/

> SocksPort 0
> ControlPort 9052
> ORPort  209.141.39.157:443
> 
> 
> I have 2 IPs on my server and I wanted Tor to use 209.141.39.157. I thought
> setting it with ORPort would suffice. But under "Exit Addresses" in the
> metrics it was my other IP. So I added the following in my torrc:
> 
> Address 209.141.39.157
> OutboundBindAddress 209.141.39.157

> 
> And now I have both IPs in the "Exit Addresses". How can I prevent my exit
> relay from using the other IP? Note that I have also another instance of
> Tor running a hidden service that I intended to run on the other IP.

For IPv4 only a flag is missing at the ORPort
See [NEW FEATURE] Relay IPv6 Address Discovery
https://www.mail-archive.com/tor-relays@lists.torproject.org/msg17760.html

Dual stack config:
Address 185.220.101.33
Address [2a0b:f4c2:2::33]

OutboundBindAddress 185.220.101.33
OutboundBindAddress [2a0b:f4c2:2::33]

ORPort 185.220.101.33:9001
ORPort [2a0b:f4c2:2::33]:9001

IPv4 only:
Address 185.220.101.33
OutboundBindAddress 185.220.101.33
ORPort 9001 IPv4Only

Then restart the relay, a reload is not enough.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] AirTor/ATOR continues to pester Tor relay operators, promising donations

[lists]

On Freitag, 17. März 2023 17:25:10 CET Bauruine wrote:

> ... but I'll
> just keep "mining" consensus weight. Because you don't need a modified
> version of Tor and you don't need the blockchain for that. Just download
> the consensus and look at the consensus weight and you have your proof
> of uptime and relaying.

Yeah, contribution in accumulated consensus weight, that's what nusenu has 
been doing for a long time:
https://nusenu.github.io/OrNetStats/#top-relay-contributors-by-aroi

Besides, no reputable relay operator would use a modified
version of Tor. (from third-party sources) ;-)


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Confusing bridge signs...

[lists]

On Sonntag, 12. März 2023 04:45:21 CET Keifer Bly wrote:
> I do not use any scripts to start tor, I just type tor to start the process
> on debian.
That's where your problems begin. You start a 2nd tor process as root that 
doesn't take the default configs from:
/usr/share/tor/tor-service-defaults-torrc & /etc/tor/torrc

You have a systemd system & tor.service is activated by default. You don't 
have to do anything, tor runs automatically after a reboot|server start.

The systemd services are controlled with the following commands:
systemctl start tor.service
systemctl stop tor.service
systemctl restart tor.service
systemctl reload tor.service
systemctl status tor.service

> And yes the datacenter I run in has an external firewall which
> requires setting up port forwarding.
Ok, anything in the customer interface for the datacenter router.
 
> The result of running ls -A /var/log/tor
> 
> root@instance-1:/home/keifer_bly# ls -A /var/log/tor
> notices.log  notices.log.1  notices.log.2.gz  notices.log.3.gz
>  notices.log.4.gz  notices.log.5.gz
There are 6 log files of one of the tor processes. Both write to syslog.

> 
> So it's creating separate .gz files for some reason. I don't know why that
> is or what to do from here. Thanks.
I wrote, learn what _logrotate_ does. Hint: without that, the hd fills up.
man logrotate

> 
> 
> 
> --Keifer
> 
> On Fri, Mar 10, 2023 at 8:15 AM  wrote:
> > On Mittwoch, 8. März 2023 18:13:01 CET Keifer Bly wrote:
> > > Strangely, nothing whatsoever is being written to the notices.log file,
> > > upon checking it it is completely empty, nothing there.
> > 
> > That can't be, please post:
> > ~# ls -A /var/log/tor
> > 
> > In general, everything is always written to /var/log/syslog &
> > systemd-journald
> > to /var/log/journal (binaries).
> > ~$ man journalctl
> > 
> > > I wonder why that
> > 
> > Read what _logrotate_ does. Every tor restart creates a new empty log
> > file.
> > 
> > > would happen and how else to tell what's going on? Tor is running as
> > > root
> > 
> > Why do you change security-related default settings? Default tor user is:
> > debian-tor. (On Debian and Ubuntu systems)
> > 
> > > so it's not a permission issue, and I also set up a port forwarding rule
> > 
> > Why? You have a server in the data center. You only need forwarding on a
> > router! Packet forwarding is also disabled in /etc/sysctl.conf per
> > default.
> > 
> > Your iptables must start like this.
> > *filter
> > 
> > :INPUT DROP [0:0]
> > :FORWARD DROP [0:0]
> > :OUTPUT ACCEPT [0:0]
> > 
> > ...
> > -A INPUT -p tcp --dport   -j ACCEPT
> > ...
> > 
> > No FORWARD, no  OUTPUT rules.
> > 
> > --
> > ╰_╯ Ciao Marco!
> > 
> > Debian GNU/Linux
> > 
> > It's free software and it gives you
> > freedom!___
> > tor-relays mailing list
> > tor-relays@lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relay requirements

[lists]

On Dienstag, 7. März 2023 13:31:13 CET mail--- via tor-relays wrote:
 
> Running a few relays on 1-2 CPU cores with limited RAM is
> fine, but just keep an eye on it and don't run other memory intensive stuff
> on the server (like DNS query caching, which can take quite some RAM as
> well).

A recursive, and caching DNS server like unbound or PowerDNS(+dnsdist) is 
absolutely necessary on an exit or in your own network.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Confusing bridge signs...

[lists]

On Mittwoch, 8. März 2023 18:13:01 CET Keifer Bly wrote:

> Strangely, nothing whatsoever is being written to the notices.log file,
> upon checking it it is completely empty, nothing there.
That can't be, please post:
~# ls -A /var/log/tor

In general, everything is always written to /var/log/syslog & systemd-journald 
to /var/log/journal (binaries).
~$ man journalctl

> I wonder why that
Read what _logrotate_ does. Every tor restart creates a new empty log file.

> would happen and how else to tell what's going on? Tor is running as root
Why do you change security-related default settings? Default tor user is: 
debian-tor. (On Debian and Ubuntu systems)

> so it's not a permission issue, and I also set up a port forwarding rule
Why? You have a server in the data center. You only need forwarding on a 
router! Packet forwarding is also disabled in /etc/sysctl.conf per default.

Your iptables must start like this.
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
...
-A INPUT -p tcp --dport   -j ACCEPT
...

No FORWARD, no  OUTPUT rules.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relay requirements

[lists]

On Dienstag, 7. März 2023 03:00:49 CET Sydney wrote:
> Newbie here. No network experience but already running 2 TOR instances: 1
> TOR service + 1 bridge.
Never mix different relay types under one IP.

> I would like to "upgrade" to TOR relays but have a few questions relating to
> hardware needs.

1core 2GB RAM is enough for an exit. This one:
https://metrics.torproject.org/rs.html#details/D00795330D77C75344C54FB8800531FAB3C40FBE
1core, 2GB RAM, 10GB Network
You need bandwidth, _unlimited_ bandwidth. A relay easily has 50-100TB/month!
Tor relay (=router) bandwidth is in + out!

> I guess my fundamental question is what is the advantage of running multiple
> relays of the same type, on the same server?
Because C-tor is not multicore aware.

> I see some operators running
> dozens of them, all in the same country, same ISP. Why not just a single
> relay running with a large capacity?
see above (multicore) These are very powerful servers. Mostly their own, in 
colocation.
1x10G, 2x10G or more network connection, 64 or 128 CPU cores 256-512 GB RAM and 
_unlimited_ bandwidth.
In addition usually their own ASN. To advertise an AS via BGP, at least a /24 
(255 IP's) is required.

That's why I keep asking when we'll finally be able to run IPv6 only relays.
/24 IP + ASN approx. 5000 EUR/(1st)year. (Only via waiting list & if never 
received an IPv4 allocation)
/48 IPv6 + ASN approx. 100 Eur/year.

https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-waiting-list

> Also, is there a requirement for the
> number of relays per core? (Maybe this is the answer to my question.) I
> know my bridge is currently keeping one core of my 2-core server constantly
> under load. Thank in advance.
Rule of thumb - one instance per core.


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] D5A3882CBDBE4CAD2F9DDA2AB80FE761BEDC3F11 is spoofing my contact info

[lists]

This is _not_ my relay:

https://metrics.torproject.org/rs.html#details/D5A3882CBDBE4CAD2F9DDA2AB80FE761BEDC3F11
https://nusenu.github.io/OrNetStats/w/relay/D5A3882CBDBE4CAD2F9DDA2AB80FE761BEDC3F11.html

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Confusing bridge signs...

[lists]

On Samstag, 4. März 2023 02:09:19 CET Keifer Bly wrote:
> Wheres the pastebin page? Thanks.
$websearch pastebin

https://paste.debian.net/
https://paste.systemli.org/
https://pastebin.mozilla.org/
...


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Confusing bridge signs...

[lists]

On Dienstag, 28. Februar 2023 19:02:38 CET Keifer Bly wrote:
> Yep, and after that the same still happens, it is still going offline
In the syslog is why tor aborts.

To help you, you should post your logs to a pastbin page. From the start of 
the tor daemon until it goes offline.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Confusing bridge signs...

[lists]

On Freitag, 24. Februar 2023 04:11:27 CET Keifer Bly wrote:
> Yes, the limit is 50GB per month, but for some reason the distribution
> mechanism is not updating and the bridge keeps going offline despite the
> new torrc.

What comes to my mind without logs (& your 'killall -HUP' of a systemd service 
is not optimal), your wrong config (2x same Port) has maxed out 'Restart=on-
failure'.

Try:
~# systemctl stop tor
~# systemctl list-units --failed

if not zero than:
~# systemctl reset-failed
~# systemctl start tor

To see if the tor.service has finished successfully:
~# systemctl status tor

if not, read log:
journalctl -xe

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Frantech (was Re: Confusing bridge signs)

[lists]

On Freitag, 24. Februar 2023 14:19:13 CET Jeff Teitel wrote:
> On Fri, Feb 24, 2023 at 12:10 AM Marco wrote:
> > Yes, Frantech should actually be avoided. But in Miami there are few Tor
> > relays. A SLICE 512  for $2.00/m or $20.00/y is sufficient for a bridge.
> > https://buyvm.net/kvm-dedicated-server-slices/
> 
> Why should Frantech be avoided?
> 

https://community.torproject.org/relay/technical-considerations/

Because Frantech=PONYNET (especially Luxembourg) it's just as crowded as:
OVH SAS (AS16276)
Online S.a.s. (AS12876)
Hetzner Online GmbH (AS24940)
DigitalOcean, LLC (AS14061)
;-) Berlin (AS60729)

That doesn't mean that you should turn off your Tor exit when it's already 
running. :-) I have some running there too.
Frantech is suitable for the first exit experiences because you don't have any 
problems with abuse there, if you follow the rules.

To find little-used providers:
https://nusenu.github.io/OrNetStats/#autonomous-systems-by-cw-fraction

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Confusing bridge signs...

[lists]

On Donnerstag, 23. Februar 2023 13:43:29 CET gus wrote:

>   AccountingStart day 12:00
>   AccountingMax 50 GB
> 
> 
> Example: Let's say you want to allow 50 GB of traffic every day in each
> direction and the accounting should reset at noon each day:
Hi Gus, I think Keifer meant the 5GB limit or now 50GB per month. ;-)

I would recommend checking here more often:
https://lowendbox.com/blog/2-usd-vps-cheap-vps-under-2-month/
Server Host: 2048MB RAM, 1000Mbps Unmetered Port
(^^ make sure to use the coupon code!)

There are always offers for Easter, Christmas or Black Friday. (VPS unlimited 
for 10-30 dollars/year)

Or:

Yes, Frantech should actually be avoided. But in Miami there are few Tor 
relays. A SLICE 512  for $2.00/m or $20.00/y is sufficient for a bridge.
https://buyvm.net/kvm-dedicated-server-slices/

> For more details about AccountinMax, see this Support doc:
> https://support.torproject.org/relay-operators/limit-total-bandwidth/

> Did you also install obfs4proxy package? Because on Metrics it says
> that your bridge don't have any 'transport protocol'.

@Keifer read my message how you check that:
https://lists.torproject.org/pipermail/tor-relays/2023-January/020979.html


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Confusing bridge signs...

[lists]

On Samstag, 18. Februar 2023 18:56:00 CET Keifer Bly wrote:
> Ok. Here is the torrc file:
> 
>   GNU nano 3.2   /etc/tor/torrc
> 
> 
> Nickname gbridge
> ORPort 443
> SocksPort 0
> BridgeRelay 1
> PublishServerDescriptor bridge
> ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
> ServerTransportListenAddr obfs4 0.0.0.0:8080
> ExtOrPort auto
> Log notice file /var/log/tor/notices.log
> ExitPolicy reject *:*
> AccountingMax 5 GB
> ContactInfo keiferdodderblyyatgmaildoddercom
> 
> 
> Where in this torrc file is that configured?
Then set it to 'any' and wait 24-48 hours to see what happens. Maybe there was 
an error in the db.

If your bridge is still not distributed, it could be due to the outdated 
obfs4proxy or because of 'AccountingMax 5 GB'.
Sorry but, 5 GB is a 'fart in the wind' the accounting period would only be a 
few hours a month. It's not even worth distributing them because it would only 
frustrate the users.

> And how would it be blocked in
> Russia already if it hasn't even been used?
Why should this new feature of the bridgedb, more precisely the rdsys backend, 
have anything to do with whether someone uses a bridge? This is a bridgedb 
distribution method introduced by meskio.


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Questions about Tor consensus weight & swag

[lists]

On Samstag, 18. Februar 2023 18:26:55 CET shruub via tor-relays wrote:

> > RelayBandwidthBurst
> 
> One question, what actually is the burst? Haven't found anything online
> nor in man.
> 

man torrc:
RelayBandwidthBurst N bytes|KBytes|MBytes|GBytes|TBytes|KBits|MBits|GBits|
TBits
If not 0, limit the maximum token bucket size (also known as the burst) for 
_relayed traffic_ to the given number of bytes in each direction.
They do not include directory fetches by the relay (from authority or other
relays), because that is considered "client" activity. (Default: 0)

https://onbasca.readthedocs.io/en/latest/bandwidth_tor.html

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Confusing bridge signs...

[lists]

On Donnerstag, 16. Februar 2023 06:15:02 CET Keifer Bly wrote:

> So my bridge at
> https://metrics.torproject.org/rs.html#details/4D6E3CA2110FC36D3106C86940A1D
> 4C8C91923AB says it has “none “,
Well, then you have configured BridgeDistribution (Default: any) to none.

> though the torrc file has it set to be distributed publicly.
PublishServerDescriptor has nothing to do with BridgeDistribution method,
'man torrc' explains the config options.

> I have not personally given the bridge to anyone.
Then nobody can use the bridge except you :-(
You can also see this in the metrics history or in /var/lib/tor/stats/bridge-
stats.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Questions about 4 Relays per IP and the ddos mitigation scripts

[lists]

On Mittwoch, 8. Februar 2023 00:07:22 CET nusenu wrote:

> I don't think relays should silently drop
> other relays packets without first trying:
> - to confirm that accepting that IP would render the relay (mostly) unusable
> (by first running in a mode that accepts relay IPs) - to understand the
> actual root cause
> - to contact the relay operator at the other
> - to report relays they consider malicious
> 
> Not investigating such cases is a missed opportunity
> to find potential bugs or a new detection mechanism for malicious relays.
> It is also a missed opportunity to help protect the tor network at a higher
> level, because it is unlikely that everyone is using (the same) filters.
> 
> Filters that result in blocks for a large fraction of the tor network
> are more likely a sign of an unsuitable filters than an indicator that most
> of the tor network is engaging in attack against other relays,
> especially when they include well known and long term trusted operators.
> 
> This a good topic to be added to the Expectations for Relay Operators
> document.
> https://gitlab.torproject.org/tpo/community/team/-/wikis/Expectations-for-R
> elay-Operators
> 
> At the very least relays blocking/dropping some packets of other relays
> should be very transparent about it.

On exits, i don't block|rate limit via nftables I block via exit policy.
Alex from Artikel10 created a nice python script:
https://github.com/artikel10/surgeprotector
I'm running the script with 1 TCP connections as the LIMIT.

Once issue ¹#40676 is resolved, the relays will no longer need to be 
restarted. A reload would close already established outbound connections.

¹https://gitlab.torproject.org/tpo/core/tor/-/issues/40676

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] backports obfs4proxy unsigned

[lists]

On Freitag, 13. Januar 2023 18:18:21 CET tor wrote:
> the backport of obfs4proxy seems to be unsigned

Backports has been an official Debian service since ~2010 and the packages are 
signed with the debian-archive-keyring.

> I needed to use:
> deb [trusted=yes] http://deb.debian.org/debian bullseye-backports main

No, then you have configured something wrong, or you don't have a Debian 
system.

Raspbian != Debian and, like Ubuntu, must first import the debian-archive-
keyring:
https://packages.debian.org/bullseye/debian-archive-keyring

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] obfs4proxy ubuntu jammy arm64

[lists]

On Freitag, 13. Januar 2023 18:05:19 CET Martin wrote:
> Just out of curiosity, when will this version be implemented in the TOR
> repositories?

As far as I can tell, not in the near future. (this version and also future 
versions)
Obfs4proxy has too many dependencies and is packed better (as backport) in the 
distribution:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs4/-/issues/33736#note_2773768

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] obfs4proxy ubuntu jammy arm64

[lists]

On Freitag, 13. Januar 2023 16:09:33 CET li...@for-privacy.net wrote:

> > Where do I get version 14?
> 
> From backports:
> https://lists.torproject.org/pipermail/tor-relays/2023-January/020976.html

A little help for backports that I've already posted:
https://lists.torproject.org/pipermail/tor-relays/2022-March/020461.html

1. check which version is installed:

~# apt-cache policy obfs4proxy
obfs4proxy:
  Installed: 0.0.14-1~bpo11
  Candidate: 0.0.14-1~bpo11
  Version table:
 *** 0.0.14-1~bpo11 100
100 https://deb.debian.org/debian bullseye-backports/main amd64 
Packages
100 /var/lib/dpkg/status
 0.0.8-1+b6 500
500 https://deb.debian.org/debian bullseye/main amd64 Packages


2. Add Backports to sources.list:
~# sudo nano /etc/apt/sources.list

# bullseye-backports, previously on backports.debian.org
deb http://deb.debian.org/debian/ bullseye-backports main


3. Then install:

~# sudo apt update
~# sudo apt install -t bullseye-backports obfs4proxy

https://backports.debian.org/Instructions/
Installed backport packages are set to 'AutomaticUpgrades: yes'

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] obfs4proxy ubuntu jammy arm64

[lists]

On Freitag, 13. Januar 2023 15:40:50 CET tor wrote:
>  Hello
> 
> I'm running ubuntu, jammy, arm64.
> 
> When I run:
> 
> machine@user_1:~$ sudo apt-get install obfs4proxy
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> obfs4proxy is already the newest version (0.0.13-1).
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 
> Where do I get version 14?
> 
From backports:
https://lists.torproject.org/pipermail/tor-relays/2023-January/020976.html

If ubuntu doesn't have one yet: (blame https://canonical.com/)
backport it yourself or take it from the debian repo.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] I think I'm available 24/7

[lists]

On Dienstag, 3. Januar 2023 00:46:30 CET fastliftednloud via tor-relays wrote:

> I'm game to do my part and operate a relay, something simple for a
> technologically simple guy, like a guard or middle relay.

You can help directly with a Firefox plugin: Snowflake proxy. Has the same 
function as a bridge and is installed in seconds:
https://snowflake.torproject.org/

> I'm about ready
> to try and install for operation on my windows PC. The resources say that
> if you want to operate a relay on windows you need to be available 24/7. I
> think I am, could someone confirm this for me please.

You don't have to be available 24/7, your relay should be online 24/7. ;-)
And if possible have a static IP.


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] inet_csk_bind_conflict

[lists]

On Freitag, 2. Dezember 2022 16:30:48 CET Chris wrote:

> As I'm sure you've already gathered, your system is maxing out trying to
> deal with all the connection requests. When inet_csk_get_port is called
> and the port is found to be occupied then inet_csk_bind_conflict is
> called to resolve the conflict. So in normal circumstances you shouldn't
> see it in perf top much less at 79%. There are two ways to deal with it,
> and each method should be complimented by the other. One way is to try
> to increase the number of ports and reduce the wait time which you have
> somehow tried. I would add the following:

I use on old Dual Intel Xeon E5-2680v2 CPU's, 256 GB RAM & the Tor IP's/traffic 
routed over a dual 10G NIC. (40 exit relays)

> net.ipv4.tcp_fin_timeout = 20
net.ipv4.tcp_fin_timeout = 4

> net.ipv4.tcp_max_tw_buckets = 1200
net.ipv4.tcp_max_tw_buckets = 200

> net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_keepalive_time = 60

> net.ipv4.tcp_max_syn_backlog = 8192
net.core.netdev_max_backlog = 262144

https://github.com/boldsuck/tor-relay-configs/blob/main/etc/sysctl.d/local.conf

> 
> The complimentary method to the above is to lower the number of
> connection requests by removing the frivolous connection requests out of
> the equation using a few iptables rules.
> 
> I'm assuming the increased load you're experiencing is due to the
> current DDos attacks and I'm not sure if you're using anything to
> mitigate that but you should consider it.
> 
> You may find something useful at the following  links
> 
> [1](https://github.com/Enkidu-6/tor-ddos)
> 
> [2](https://github.com/toralf/torutils)
> 
> [background](https://gitlab.torproject.org/tpo/community/support/-/issues/40
> 093)
> 
> Cheers.
> 
> On 12/1/2022 3:35 PM, Christopher Sheats wrote:
> > Hello tor-relays,
> > 
> > We are using Ubuntu server currently for our exit relays.
> > Occasionally, exit throughput will drop from ~4Gbps down to ~200Mbps
> > and the only observable data point that we have is a significant
> > increase in inet_csk_bind_conflict, as seen via 'perf top', where it
> > will hit 85% [kernel] utilization.
> > 
> > A while back we thought we solved with with two /etc/sysctl.conf settings:
> > net.ipv4.ip_local_port_range = 1024 65535
> > net.ipv4.tcp_tw_reuse = 1
> > 
> > However we are still experiencing this problem.
> > 
> > Both of our (currently, two) relay servers suffer from the same
> > problem, at the same time. They are AMD Epyc 7402P bare-metal servers
> > each with 96GB RAM, each has 20 exit relays on them. This issue
> > persists after upgrading to 0.4.7.11.
> > 
> > Screenshots of perf top are shared
> > here: https://digitalcourage.social/@EmeraldOnion/109440197076214023
> > 
> > Does anyone have experience troubleshooting and/or fixing this problem?


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Performance issues/DoS from outgoing Exit connections

[lists]

On Samstag, 22. Oktober 2022 22:40:38 CEST Toralf Förster wrote:
> On 10/21/22 22:09, Alexander Dietrich wrote:
> > This is still experimental, so if you decide to give the script a try,
> > please keep an eye on it.
> 
> IMO a "reload tor" is fully sufficient and should be preferrred over
> "restart", or ?
> 
> Years ago I wrote a bash script, which created for an ip to be blocked
> just an own file. Such a file can be easily removed and then tor
> reloaded to unblock that ip ;)

Just tested because Applied Privacy and I have the problem that the exit 
policy rules do not work with some IPs¹.

Last night at 10pm: IP 79.137.192.228 had 500k connections. Added the IP to 
the exit policy and reloaded tor.

Policy in that order:
ExitPolicy reject 79.137.192.228/32:*
ExitPolicy reject *:22
ExitPolicy reject *:25
ExitPolicy accept *:*

12 hours later the IP still has over 100k connections.
-> systemctl restart tor
1 hour later the IP has 0 connections :-)

¹https://gitlab.torproject.org/tpo/core/tor/-/issues/40676

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] bridge down

[lists]

On Mittwoch, 19. Oktober 2022 01:12:37 CEST Anonforpeace via tor-relays wrote:
> I have set the static NAT and forwarded the port.
On your router?

> Here is what I get.
:-(
Logs and configs are more readable on a pastbin page.
E.g. paste.debian.net or privatebin.deblan.org

> darkhoodie-HP-Compaq-Pro-6300-SFF kernel: [441419.629454] [UFW BLOCK]
UFW? In your localnet behind a gateway router you usually don't need a fw on 
the hosts.

> 18 19:06:28 darkhoodie-HP-Compaq-Pro-6300-SFF Tor[73719]: Your server has
> not managed to confirm reachability for its ORPort(s) at x.x.x.x:443.
> Relays do not publish descriptors until their ORPort and DirPort are
> reachable. Please check your firewalls, ports, address, /etc/hosts file,

Port forward on your router is probably not correct, or there is an error in 
the torrc.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] knock knock, police is here

[lists]

On Samstag, 10. September 2022 14:37:18 CEST volker.m...@gmx.de wrote:

> On Tuesday morning police knocked on my door, performing a full house
> search.
For me the bastards were 2 weeks ago at 6:05 am :-(
Until now I was not told which IP's and when it was.

> Unfortunately they found some dope (yea, 420guy here) during the house
> search, which  makes thing even more complicated.
Oh, that sucks. I hope you don't live in Bavaria and it's your first BTM case.
Since my whole place is full of IT stuff, including server cabinets, they 
overlooked the BTM stuff. They were only interested in child pornography.

> Now I am considering shutting down all my exits.
For me they have achieved the opposite, I would like to do even more exit 
traffic. The server IP's continue to run under my name. Lawyer Udo Vetter¹ will 
inspect the files and we will most likely file a complaint.
I'm saving for my next server and would like to offer Freifunk exit traffic in 
addition to Tor exit traffic.
If the cops come again, everything will be re-registered as an LLC or LTD like 
relayon.org & yggdrasil.ws do.

¹https://www.vetter-mertens.de/law-blog/
Solmeke is also familiar with exits.
https://www.wbs-law.de/kanzlei-anwaelte/christian-solmecke/

> I promise you guys, there is nothing more bad than a police house search in
> the early morning hourse. Even a burglary would be less worse. Burglars
> come, steal, go and you never hear again from them.
Oh, I've had worse raids before. They only searched 2 laptops and a mobile 
phone for child porn pictures. They didn't find anything and didn't search the 
rest of the IT any further. They confiscated nothing and ransacked no 
cupboards. We then talked about why I do Tor and Freifunk. What does that 
cost. And were interested in FreeBSD on the Macbook.

> Police comes, searches through all your belongings, destroys your privacy,
> is allowed to take ALL what they want - and they will send you bad bad
> letters afterwards.
I am in contact with Digitalcourage and Artikel10 and have sent them all the 
documents.

> What are your thoughts about this?
Heartfelt condolences.

You are welcome to write to me privately and in German.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relays spamming my OR port

[lists]

On Donnerstag, 18. August 2022 19:47:45 CEST Toralf Förster wrote:
> On 8/18/22 18:19, li...@for-privacy.net wrote:
> > kantorkel's Article10 relays have more than 100 connections per IP to me.
> 
> Those IPs mostly close with an error:
> 
> $> grep -h " 185.220.101.*" /tmp/orstatus.*9051 | awk '{ print $1 }' | sort | 
> uniq -c
OK, that's all 4 of us. We don't have IPv4 connections to each other, the Tor 
protocol doesn't allow that.

>  341 CONNECTRESET
>   78 DONE
>  783 IOERROR

I have connections to kantorkel via IPv6 (2a0b:f4c2:2::/64).
This is actually fast but stupid when Tor relays connect in the same rack.
IPv6 connections should better be limited to /48 subnets in the Tor protocol. 
Or /32


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relays spamming my OR port

[lists]

On Donnerstag, 18. August 2022 19:25:54 CEST Toralf Förster wrote:
> On 8/18/22 18:19, li...@for-privacy.net wrote:
> > 10, 20 or more users can have set up the circuits using the same relays.
> > kantorkel's Article10 relays have more than 100 connections per IP to me.
> 
> IMO there'se no 1:1 relation of circuits to TCP connections, or ?
Heck, I'd have to read the tor specs for that.
All I know is when I had tor-arm or NYX on some relays 2-3 years ago, there 
were multiple simultaneous connections to the same relay.

> Doesn't 1 TCP connection between 2 relays will handle all circuits going
> between them ?
If that's really the case, I can set up the ip|nftables rules much more 
strictly.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relays spamming my OR port

[lists]

On Donnerstag, 18. August 2022 19:22:44 CEST Toralf Förster wrote:
> On 8/18/22 18:19, li...@for-privacy.net wrote:
> >> D767979FE4C99D310A46EC49037E9FE7E3F64E9D is a particularly frequent
> >> naughty boy.
> > 
> > ;-)  It is very, very unlikely that there is a naughty relay in AS680.
> > That relay most likely does DNS-, BW- or network healing test in the Tor
> > network. https://metrics.torproject.org/rs.html#search/as:AS680
> > (German university or research institutes)
> 
> Do you know more about those tests ? That relay produces many wrong
> ORStatus.CLOSED events:

So I don't know exactly. If someone is really screwing things up, it might be 
a student who hacked a server.
I'll take Sebastian in CC, maybe he knows more about it.

> $> grep D767979FE4C99 /tmp/orstatus.9051 | uniq -c
>  896 TLS_ERRORD767979FE4C99D310A46EC49037E9FE7E3F64E9D
> 141.20.103.33 443 v4 0.4.5.10
> 
> $> grep D767979FE4C99 /tmp/orstatus.29051 | uniq -c
>  965 TLS_ERRORD767979FE4C99D310A46EC49037E9FE7E3F64E9D
> 141.20.103.33 443 v4 0.4.5.10
> 
> The data were collected using [1] over the past 20 hours at [2].
> 
> 
> [1] D767979FE4C99D310A46EC49037E9FE7E3F64E9D
> [2] 65.21.94.13

@Sebastian
Do you know more about the relay in the DFN?

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relays spamming my OR port

[lists]

On Mittwoch, 17. August 2022 19:31:48 CEST Logforme wrote:
> I run the relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3
> 
> I have tried to mitigate the current DoS by implemented connection
> limits in my iptables using Toralf's template: More than 25 connection
> during 10 mins and you end up on my naughty list.
> Lots of connection attempts from the naughty list dropped but still my
> relay gets "overloaded"
> 
> However, I have noticed that a few relays also end up on the naughty
> list, and I wonder how that can happen. My understanding is that a relay
> will only open 1 connection to another relay so should therefore never
> end up on the list. Correct?

10, 20 or more users can have set up the circuits using the same relays.
kantorkel's Article10 relays have more than 100 connections per IP to me.

On my smaller relays I allow 100 connections per IP:
https://privatebin.deblan.org/?b4768471c3c9e7ef#EhDETgMKQRvpL6VwH7ABE3bN2cuM68PRVj3fmmAC8k54

But I can't use that on the big servers because Linux kernel “conntrack” tables 
and nftables sets only have 65535 entries.
See: The dark side of using conntrack
https://blog.cloudflare.com/conntrack-tales-one-thousand-and-one-flows/

> D767979FE4C99D310A46EC49037E9FE7E3F64E9D is a particularly frequent
> naughty boy.
;-)  It is very, very unlikely that there is a naughty relay in AS680.
That relay most likely does DNS-, BW- or network healing test in the Tor 
network.
https://metrics.torproject.org/rs.html#search/as:AS680
(German university or research institutes)

> I guess my real question is if these connections are legit and I'm
> hurting the Tor network by using connection limits?
Yes, never block other relays.
If you think there is somewhere a malicious relay, report it on bad-relay or in 
this list.


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] easy way to test my exit policy

[lists]

On Dienstag, 16. August 2022 16:36:52 CEST Tom Yates wrote:
> i've been grumbled at in a way that makes me want to validate my exit
> policy before dismissing the grumble.

I don't know exactly what you want to test there. You can see what you have 
open on tor metrics.
No IP/nftables for outgoing traffic!

My reduced exit policy (SSH only allowed for IPv6) default reject all:
https://privatebin.deblan.org/?e6d6b354ba010b0f#HZ6TGyzUoGQmWG39pVBsXG6BxtBCXXjnirWP2N2ysejJ
On tor metrics:
https://metrics.torproject.org/rs.html#details/376DC7CAD597D3A4CBB651999CFAD0E77DC9AE8C

ExitPolicy default accept all:
https://privatebin.deblan.org/?5bfff231f7c74255#BcNS8L395BGoYotnZobKcvaGPJU4EiF2W2TvTB7uEfiY
On tor metrics:
https://metrics.torproject.org/rs.html#details/D80F649226CC96BBE0FF7B45B3791901569FE5AC

> how do people test their exit policies?
I use https://metrics.torproject.org/
or
http://YOUR.EX.IT.IP/tor/server/authority

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Have you experienced DDoS?

[lists]

On Montag, 15. August 2022 16:59:47 CEST abuse compartment wrote:
> Daily. “Best” day was around 320 Uptime Robot mails after a good night
> sleep.
:-) Because you always write such nice replies to abuse mails.

> > Was somebody else also subject to DDoS today?
Um, this has been a high topic in this list for 2-3 months, on torproject 
github, on relay meetings and in the last 2-3 tor release notes.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Setting a bridge to automatically change IP adresses

[lists]

On Mittwoch, 10. August 2022 02:02:36 CEST Keifer Bly wrote:
> Thanks. But it just seems that would make it easier to have "new" bridges,
> as all of the in use ones will eventually be blocked? 

So either you have dozens of unused IP's on your server then do as I do, let 
the bridges run, _now_
https://nusenu.github.io/OrNetStats/for-privacy.net.html
and set different BridgeDistribution methods.
# Recognized methods are: "https", "email", "moat", "settings", "telegram", 
"reserved".

Or you haven't ordered any IP's for a looong time.
https://docs.hetzner.com/general/others/ipv4-pricing/
The setup fee + monthly costs = one bar metal server/month¹ or one KVM for a 
whole year (both incl. 1IP & IPv6/48 sub)

¹ unmetered unlimited traffic (1000 Mbit), see my OT post.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] OT: cheap bar metal machines

[lists]

HiHo,
because I switched to my own servers in colocation, I canceled some rented 
ones. These were all Supermicro blades 8c Opteron, 2 hd's and BMC (IPMI).
https://www.supermicro.com/Aplus/system/3U/3012/AS-3012MA-H12TRF.cfm
SSD: Samsung (840,850,860) EVO, SATA: WD Enterprice (WDC_WD1003FBYX)

They're relatively cheap. 16 EUR + 8 EUR per 16GB RAM. So server with 16GB RAM 
= 24 EUR/month or 32GB = 32 EUR/month. The 16GB are more than enough for 2 Tor 
instances! I still operated Monero mining on 4 CPU cores.

Currently there is a 10% discount (permanent) and all servers with unmetered 
unlimited traffic (1000 Mbit). All with no setup fee.
https://servdiscount.com/
The same applies to the new servers https://www.webtropia.com/
You can rent the servers prepaid or with a term of 1,3,6,... months/notice 
period.

Hints:
If you set up a customer account beforehand, you can upload your SSH keys for 
server setup. When setting up, select Raid1 (mdraid on Linux) directly.


If you have any questions, please write to me personally. German or English.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Overload (dropped ntor) due to DDoS??

[lists]

On Friday, August 5, 2022 1:11:27 AM CEST s7r wrote:
> Richard Menedetter wrote:

> > I have a non exit relay running on a root server (4 AMD Epyc cores, 8 GB
> > RAM, 2.5 GBit/s Ethernet) I have limited tor to numcpus 2,
Why? Do you have other services on the server? Otherwise, omit num CPU. Let 
the tor daemon use all CPU's for crypto stuff.

> > relaybandwidthburst 15 MB, hardwareaccel 1, maxadvertisedbandwidth 10 MB,
> > maxmeminqueues 3GB
> 
> Thanks for running a relay!
> 
> didn't you also use RelayBandwidthRate along with RelayBandwidthBurst ?
> 
> 
> > 
> > Usually it takes less than 1 CPU core, and like 1 GB of RAM.
> > But recently my relay is foten shown as obverloaded.
> > I have these LOG entries:
> > Tor[814]: General overload -> Ntor dropped (290376) fraction 5.3451% is
> > above threshold of 0.5000%
> 
> You are not the only one, it's an ongoing DoS attack on the network, 
> targeting onion services.
> 
> 
> > 
> > Is this due to DDoS attacks or a misconfigration on my side?
> 
> 
> Besides the question above about RelayBandwidthRate I don't see anything 
> wrong.
> 
> 
> > Is there something that I can do to aleviate this issue?
> 
> 
> Nope, there is nothing you can do, unfortunately. Tor has some defenses 
> against DoS and will blacklist / mark the abusing addresses, etc. as 
> much as it can. But as you know DoS is a never ending battle, usually 
> won by having "larger pipe", and it's something hard to tickle in an 
> environment where anonymity is the grounding law.
> 
> What you can do is maintain your relay up and running in good shape with 
> the latest version of Tor until this "attack" gets through. As I said, I 
> guess most of relays are getting this at present times. The DoS "attack" 
> is not targeted at your relay, what you are seeing is just a side effect 
> of someone creating large amounts of circuits (heavy usage of Tor) which 
> is reflected network-wide anyways.
Sometimes 100.000-1.000.000 connections from one IP!
I block the worst with 2 nftables egress rules.

toralf has developed some smarter ddos scripts:
https://github.com/toralf/torutils


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Metrics shows my relay down. But it's not.

[lists]

On Freitag, 24. Juni 2022 21:11:30 CEST Eddie wrote:
> The metrics is showing one of my relays
> (40D13096BBD11AF198CE61DEE4EAECCE5472F2E7) as down for around the last 3
> hours.  Logging in to it, I see everything running normally.
> 
> This server has also lost a bunch of flags for no apparent reason, so
> I'm not sure if they're connected.

Jo it's unfortunately normal, my ¹relays have been changing from red to green 
for weeks. ;-)
Because the Tor network and also the ²dir auths are under DDoS. We just talked 
about it in the meeting. see meeting pad³

¹https://metrics.torproject.org/rs.html#search/ForPrivacyNET
²https://gitlab.torproject.org/tpo/core/tor/-/issues/40622
³https://pad.riseup.net/p/tor-relay-meetup-june-2022-keep

Our XMR .onion (hidden service) nodes look bad too:
http://xmrguide25ibknxgaray5rqksrclddxqku3ggdcnzg4ogdi5qkdkd2yd.onion/remote_nodes

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
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

[lists]

On Wednesday, June 15, 2022 8:17:54 PM CEST Eddie wrote:
> Have a question about how a server I connect to can tell I am running a
> guard/middle relay.  All I can think of is that they check the published
> list of tor nodes against the IP.
Unfortunately, many people do this, often because they have no idea about the 
different Tor relays.

> Background:  The corp my wife works for blocked our IP.  The excuse they
> gave was that it was due to a change made by a vendor they use to
> identify malicious IP addresses.  I have been running the relay for
> almost 5 years without any previous flagging.  They also state that
> running a middle relay is not in violation of any policy, but the vendor
> mis-identified our relay as an exit, hence blocking it.
> 
> 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, despite what the
> corp security folks say.

Workarounts:
- In Germany, almost every ISP has (www & ftp) proxies for its customers. I 
use it generally, also for IRC, then the proxy IP is displayed.
- In Germany we have '¹Freifunk' in almost every city. Firmware is OpenWrt 
with wireguard (VPN) and can be flashed on many WLAN-AP's/router. I have one 
at home too.

¹Anonymous citizens wifi mesh networks. No registration, no logs.

> 
> I'm looking for some sort of validation I can use to counter their claims.


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] EXPKEYSIG when running 'apt update'

[lists]

On Monday, June 13, 2022 7:11:32 PM CEST Imre Jonk wrote:
> Hi tor-relays,
> 
> I'm getting this error when running 'apt update':
mee too ;-)
> Err:4 https://deb.torproject.org/torproject.org bullseye InRelease
>   The following signatures were invalid: EXPKEYSIG 74A941BA219EC810
> deb.torproject.org archive signing key
> 
> The signing key in
> /etc/apt/trusted.gpg.d/deb.torproject.org-keyring.gpg does not appear
> to be expired, so I guess some repository metadata signature has
> expired. Does anyone else encounter this issue?

Had the same thing today and saw that some machines had a newer archive key in:
/usr/share/keyrings/tor-archive-keyring.gpg

You can get the new one with this one line:

wget -qO- 
https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc
 | gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [New Initiative] Tor Weather: Improving the Tor Weather

[lists]

On Wednesday, June 8, 2022 3:39:55 AM CEST Sarthik Gupta wrote:

> The tor-weather service will offer a plethora of notifications options for
> the relays.
If you program something new, see if you can use the old code:
https://github.com/thingless/torweather
As far as I know, nusenu is also building something new. I don't know if he 
has already done something. He'll read this and get in touch.

;-)
dream: someone resuscitates OnionTip.com or TorTip.com

> These include, the node being down, running on EOL/Outdated
> version, losing a flag, ranking in top 20/50/100, etc. These notifications
> can be subscribed & customized by the relay operators to fit their needs
> using a web-frontend.
Please not 'losing a flag'
This confuses people and encourages even more people not to update their 
relays. Or like at the moment: 2 Authority voting running relays offline & 
flags come and go. Then this list is flooded with mails.

> Folks interested in the project can refer this
> 
> thread in the tor-dev mailing list for regular updates. Suggestions are
> always welcomed! Please reach out to us in irc (#tor-dev) for any ideas,
> questions, or suggestions you might have.

Unfortunately, comments are not allowed in:
https://gitlab.torproject.org/sarthikg/tor-weather/-/wikis/Proposal

Cons:
The email provided in the ContactInfo is obfuscated in most of the cases as 
they should be according to the torrc documentation. Hence this information 
cannot be relied upon.

Please replace the link to the outdated jessie manpage
use stable 'bullseye' or
https://manpages.debian.org/main/tor/torrc.5.en.html

You _MAY_ want to obscure is in the torrc not _SHOULD_ And especially in the 
last few weeks, several Tor Dev's have asked:
- DO NOT obfuscate your contact information! Maintainers already burn a lot of 
time trying to decipher obfuscated contact info!

Every reasonable email provider has spamassassin and amavisd-new running. We 
should tell people to use the header: 'X-Spam-Level: YES'

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] My current node setup

[lists]

On Tuesday, June 7, 2022 5:25:18 PM CEST Nyasaki Server wrote:
> Hi to all new ppl that may have joined after the sysadmin101 workshop.
Yes, that was a fun event ;-)

> Exit-Node:
> Archlinux with tor
Awesome, Arch and Gentoo relais are rare *BSD even less and unfortunately 
nobody talks about (Open)Solaris: https://illumos.org/

> metric collection service that nicely collects the statics that tor
> exposes. It's a VPS hosted at Terrahost in Norway for 20$ / month with 2
> vCPU’s and 4GB Memory. Unbound only resolves requests from localhost, due
> to a high percentage of DNS timeouts in the past I decided to use this just
A second IP (DNS on non-exit IP) could help. Unfortunately, the monthly IP 
prices have doubled for almost all hosters in the last few months + extra 
setup fee. :-( Hetzner started this shit.
Mostly, timeouts are not due to unbound, but assholes messing with the Tor 
network. In syslog you see bullshit like IPv6 link-local addresses fe80::
> as backup and resolve everything else via the dedicated DNS server.

> The firewall is set up to allow every port that's listed in my torrc, my
> non-default ssh port and the IP of my dashboard for the metrics port.
Please only filter inbound traffic, never outbound on exits.

Simple Tor relay ip/nftables for IP & IPv6:
https://github.com/boldsuck/tor-relay-bootstrap/tree/master/etc

 > Hosted at Oracle Cloud
I won't comment further on Oracle.
I left DynDNS very quickly at the time when they took it over.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] bridge issue

[lists]

On Saturday, June 4, 2022 1:58:29 AM CEST potlatch via tor-relays wrote:
> Hello,
> I have a bridge [1] that doesn't have any keys in /var/lib/tor/keys! How is
> that possible and how do I fix the problem?
> 
> potlatch
> 
> [1] FB45183DD82D572CA2B2641C1AB0EB0D8CE7B858
> 
> Sent with [Proton Mail](https://proton.me/) secure email.

Mmmmh
- You need root rights to read /var/lib/tor/* or Tor DataDirectory somewhere 
else.
- Possibly you have several instances: /var/lib/tor-instances/*
- If you compiled yourself see below /usr/local/var/lib/tor/*

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Update on tor issue on my debian

[lists]

On Friday, June 3, 2022 10:51:07 PM CEST Keifer Bly wrote:
> Nevermind, I got it.
> 
> Now there are two other things I wanted to ask about, is there a way I can
> set tor to automatically update over time? Also, my bridge at
> https://metrics.torproject.org/rs.html#details/4D6E3CA2110FC36D3106C86940A1D
> 4C8C91923AB says it's blocked in Russia.
Yes, that's how it should be. ;-) Meskio did this especially so that your 
bridge would not be found by the Russian government.

> Is there a way to set a bridge to
> get a new IP address automatically every once in a while so it will have a
> new, unblocked IP address? I think this would be a good idea.
New IP's are available from the provider or entire blocks from the RIR.


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] New OrNetStats Section: Largest Bridge Operators

[lists]

On Sunday, May 29, 2022 6:25:02 PM CEST nusenu wrote:

> AROI support for bridges
> 
> You can also protect your bridge ContactInfo against spoofing now.
> The same fields as for relays apply. If you have setup your AROI [1] on your
> relays already you can simply copy the ContactInfo to your bridges and
> publish the list of hashed bridge fingerprints under this URL:
> 
> https://-your-hostname-/.well-known/tor-relay/hashed-bridge-rsa-fingerprint.
> txt

Oh nice, thanks.
I just saw that nusenu also thought of us 'proof:dns-rsa' users. ;-)

https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/#dns-rsa

For bridges:

hashed-fingerprint.example.com value: “we-run-this-tor-bridge”


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Update on tor issue on my debian

[lists]

On Wednesday, June 1, 2022 7:25:44 PM CEST Keifer Bly wrote:

> So upon trying all of the mentioned commands, my tor installation still
> encounters an error when trying to update. Attached is a photo of my
> sources.list.debian.templ and sources.list. When trying to update the
> returned error
sources.list.debian.temp
I would not change the template from the provider.

>  
> 
> N: Ignoring file 'DEADJOE' in directory '/etc/apt/sources.list.d/' as it has
> no filename extension
> 
> N: Ignoring file 'tor.list.save.2' in directory '/etc/apt/sources.list.d/'
> as it has an invalid filename extension
> 
> N: Ignoring file 'tor.list.save.1' in directory '/etc/apt/sources.list.d/'
> as it has an invalid filename extension
Dir '/etc/apt/sources.list.d/' is empty by default. I would delete all files 
there. $ sudo rm -i /etc/apt/sources.list.d/*


> E: Conflicting values set for option Signed-By regarding source
> https://deb.torproject.org/torproject.org/ buster:
> /usr/share/keyrings/tor-archive-keyring.gpg !=
> 
> E: The list of sources could not be read.

You have to configure it in either the Debian buster way or the new way since 
Debian bullseye.

Old buster way + (apt-key add) in file: /etc/apt/sources.list
deb https://deb.torproject.org/torproject.org buster main

New bullseye way + (tor-archive-keyring) create a file in the directory:
'/etc/apt/sources.list.d/' with the name 'tor.list' 
with just one line:
deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://
deb.torproject.org/torproject.org buster main


For Buster, you just have to delete the penultimate line:
deb http://ftp.de.debian.org/debian stretch main
and 
[signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] in the last line
in /etc/apt/sources.list.


Other consideration:
(You must upgrade buster to bullseye, your certificates may still be out of 
date, your tor daemon is running as root!?, etc.)
nusenu gave tips on relay migration a few days ago.
- stop tor, save tor config and the entire datadir
Reinstall bullseye from the provider customer menu
- then copy over tor config and datadir, set the right permissions and let the 
relay run again.

Tomorrow is a workshop from Torproject


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Bridge operators contact addresses online ;-)

[lists]

I happened to see that Bridge operators contact addresses can now be displayed.

https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/40017

Demo on Tor Metrics for all 'bauruine' and 'ForPrivacyNET' bridges.

Thanks to the torproject team.
-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Sanity check on NumCPUs

[lists]

On Thursday, May 26, 2022 2:31:41 AM CEST Thoughts wrote:
> For a non-exit relay, is "NumCPUs 2" still the recommended maximum?  
> Running on a quad core and recently saw a message indicating I had
> insufficient CPU power to support the desired number of connections...
> 
NumCPU I always let the tor daemon choose itself. This was also recommended by 
Roger at the meeting 2-3 months ago.


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [Event] Relay Operators Meetup - May 21, 2022 @ 1900 UTC

[lists]

On Monday, May 23, 2022 6:53:13 PM CEST Vasilis The Pikachu via tor-relays 
wrote:
> Are the notes for this meeting available? I was not able to make it but 
> i would like to read up on what was talked about
> 

The pads are always set to 'keep'. That means at Riseup = 1 year/365 days.
> >> We're working on the agenda here:
> >> https://pad.riseup.net/p/tor-relay-meetup-may-2022-keep


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Debian is not allowing tor to update despite it being listed as a trusted respritory

[lists]

On Tuesday, May 10, 2022 10:51:23 PM CEST Keifer Bly wrote:
> This is what that returns,
> 
> Debian GNU/Linux 10 \n \l
OK, the version is right.

> Running the command you listed returns:
> 
> Err:1 http://ftp.debian.org/debian buster-backports InRelease
>   Temporary failure resolving 'ftp.debian.org'
> Err:2 http://deb.debian.org/debian buster InRelease
>   Temporary failure resolving 'deb.debian.org'
> Err:3 http://security.debian.org/debian-security buster/updates InRelease
>   Temporary failure resolving 'security.debian.org'
> Err:4 http://deb.debian.org/debian buster-updates InRelease
>   Temporary failure resolving 'deb.debian.org'
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> 18 packages can be upgraded. Run 'apt list --upgradable' to see them.
> W: Failed to fetch http://deb.debian.org/debian/dists/buster/InRelease
>  Temporary failure resolving 'deb.debian.org'
> W: Failed to fetch
> http://deb.debian.org/debian/dists/buster-updates/InRelease  Temporary
> failure resolving 'deb.debian.org'
> W: Failed to fetch
> http://security.debian.org/debian-security/dists/buster/updates/InRelease
>  Temporary failure resolving 'security.debian.org'
> W: Failed to fetch
> http://ftp.debian.org/debian/dists/buster-backports/InRelease  Temporary
> failure resolving 'ftp.debian.org'
> W: Some index files failed to download. They have been ignored, or old ones
> used instead.
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... Done
> The following packages will be upgraded:
>   apt apt-utils base-files isc-dhcp-client isc-dhcp-common libapt-inst2.0
> libapt-pkg5.0 libdns-export1104 libgcrypt20
>   libgnutls30 libhogweed4 libisc-export1100 liblz4-1 libnettle6 libssl1.1
> libudev1 systemd-sysv udev

Some important packages should be upgraded but the DNS resolution does not 
work. :-(
Can you post the output of the following commands? You don't necessarily have 
to be 'root' for this, as a normal user is sufficient:

ping -c 4 8.8.8.8

ping -c 4 deb.debian.org

cat /etc/resolv.conf

ls -al /etc/resolv.conf

systemctl status systemd-resolved

systemctl status ntp

curl https://deb.torproject.org/torproject.org/


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Debian is not allowing tor to update despite it being listed as a trusted respritory

[lists]

On Monday, May 9, 2022 9:40:12 AM CEST ben wrote:

Hi, I think this mail should reach Keifer.

@ Keifer please post the output of:
cat /etc/issue

It should be 'Debian GNU/Linux 10'

apt update && sudo apt full-upgrade
would install missing packages.

Then read what Ben wrote about 'update-ca-certificates'.

--  Forwarded Message  --

Subject: Re: [tor-relays] Debian is not allowing tor to update despite it 
being listed as a trusted respritory
Date: Donnerstag, 5. Mai 2022, 15:09:07 CEST
From: ben 
To: tor-relays 
CC: lists 

> Simply displays a message "no valid openpgp data found". My sources file



You'll see this because your system doesn't trust the cert chain.



You're not seeing a certificate warning because you've got output suppressed 
(the -q in wget's arguments)



If you run



wget https://deb.torproject.org/torproject.org/
A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc



I suspect you'll see the certificate warning.



You need to fix that before anything suggested here is going to work - if the 
cert chain isn't trusted then apt isn't going to access the repository's 
indexes, and so won't even see what packages are there, much less install 
them.



As apt didn't grab an updated version for you (which may be due to other repo 
misconfigurations) you probably want to grab and install the cert manually




# Verify that this gives a cert warning

curl https://deb.torproject.org/torproject.org/ 



curl -k --output "/tmp/ISRG_Root_X1.crt"  "https://letsencrypt.org/certs/
isrgrootx1.pem.txt"

sudo mv /tmp/ISRG_Root_X1.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates



# Now try again

curl https://deb.torproject.org/torproject.org/ 



If that final curl now works, run apt-get update and you should find apt no 
longer complains about the tor repo



-- 
Ben Tasker
https://www.bentasker.co.uk


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Debian is not allowing tor to update despite it being listed as a trusted respritory

[lists]

On Saturday, May 7, 2022 6:50:43 PM CEST Keifer Bly wrote:
> Ok will try these things. Does that it's an ovh debain have anything to do
> with it? Hosted by them and they may frown on tor.

No, there are a lot (actually too many) Tor relays at OVH.
https://nusenu.github.io/OrNetStats/#autonomous-systems-by-cw-fraction

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Ext Relay Operators: Please Upgrade to 0.4.7.7!

[lists]

On Tuesday, May 10, 2022 4:55:57 PM CEST Ladar Levison via tor-relays wrote:

> Anyone know when the EPEL TOR packages will updated? The EL 8 repos only
> offer 0.4.5.11. EL 9 is only a little newer with RPMs for TOR 0.4.6.8.
> Fedora 35 and 36 (with the latter launching today) have only been
> updated to 0.4.6.9. As of now, it appears that only Fedora 37 has been
> updated to 0.4.7.7.

I don't know the philosophy of Fedora/EPEL (CentOS/RHEL). In general, no 
configuration-breaking software is installed on productive systems.
With debian, once the release is frozen and stable, there are _no_ upgrades. 
This is the main reason for the stable archive! There are only updates, 
security updates in the 'stable main' archive
Some new features are offered in backports if they don't break configs of 
stable packages. There are very few upgrades (virus scanners and timezone 
data) in stable-updates, formerly volatile.

Therefore, Tor upgrades with new features must be installed from the Tor 
project repro.
EPEL (CentOS/RHEL) may have a similar policy and you must grab packages from 
the Tor project if you want to upgrade.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relay Throttling

[lists]

On Friday, May 6, 2022 2:39:09 PM CEST trinity pointard wrote:
> Hi,
> 
> There are two main mechanisms to limit relays bandwidth usage.
> The first is by setting RelayBandwidthRate and RelayBandwidthBurst to limit
> the average and peak bandwidth usage of your bridge.
> The second is by setting AccountingMax, AccountingStart and possibly
> accounting AccountingRule, to limit the total bandwidth usage over some
> periode (day, week or month)
> 
> If you want to limit your relay to, say 100mbit, with burst at 120, and set
> a hard limit on monthly traffic to 1TB you can set in your relay torrc.
> 
> RelayBandwidthRate 100MBits
> RelayBandwidthBurst 120MBits
> AccountingMax 1 TBytes
> AccountingStart month 1 00:00
# How we determine when our AccountingMax has been reached. sum|max|in|out
# (Default: max)
AccountingRule sum

A hint, mostly you want 'sum'.
Tor is !Webserver, the incoming and outgoing traffic is the same. Almost all 
providers calculate in + out traffic.


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Exit: Complaints of IP being used for "spam" despite exit policy

[lists]

On Thursday, May 5, 2022 3:57:02 PM CEST The Doctor wrote:
> --- Original Message ---
> 
> On Wednesday, May 4th, 2022 at 11:16, Neel Chauhan  wrote:
> > If you need to send emails, you could:
> > 
> > a. use Sendgrid or Mailgun or whatever to send emails if they don't
> > block exit IPs from connecting to their SMTP relays
> > 
> > b. Run your own SMTP relay on a $3.5 VPS to forward emails
> 
> You could also run an SMTP-to-something else protocol bridge to work around
> it.  I use a fake SMTP server that relays every message it gets over XMPP
> to work around that problem.
> 
> The Doctor [412/724/301/703/415/510]

Thanks, Neel and yl had already messaged me privately. I replied to them 
yesterday. I had already solved the problem, unattended-upgrades and logcheck 
mails reach me again.

Actually, I should know that we should avoid exit IPs for DNS, mail and other 
things. I configured nullmailer as usual, then it takes the first IP and 
interface it finds. I was sending mail as a client through|to my DNS 
provider's SMTP server 'easydns.com'. They recently started using abusix 
before smtpauth as well. Only a /27 are exit IP's per server. Now the mail 
goes out on a completely different subnet and network card.

Well I could have pinged Mark Jeftovic @ easyDNS too, please whitelist _my_ IP 
for _my_ mailbox. Or sending mail out via the SMTP server from IN-Berlin, like 
my iRMC (BMC) do.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Debian is not allowing tor to update despite it being listed as a trusted respritory

[lists]

On Thursday, May 5, 2022 5:17:23 AM CEST Keifer Bly wrote:
> Thank you. But running wget -qO-
> https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E88
> 6DDD89.asc
> 
> gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null

Maybe copy paste error. It must be one line and you must be root or type 
'sudo' in front of it. Maybe you can better copy from here:

3. Then add the gpg key ...
https://support.torproject.org/apt/

> Simply displays a message "no valid openpgp data found". My sources file

If this message appears again, install gpg:
sudo apt update && apt -y install gnupg

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Debian is not allowing tor to update despite it being listed as a trusted respritory

[lists]

On Thursday, May 5, 2022 2:29:30 AM CEST Keifer Bly wrote:
> Ok. I have tried different things. And the same is still happening:
> 
> sources.list file:
> 
> ## Note, this file is written by cloud-init on first boot of an instance
> ## modifications made here will not survive a re-bundle.
> ## if you wish to make changes you can:

> ## c.) make changes to template file
> /etc/cloud/templates/sources.list.debian.tmpl

OK, you must look in '/etc/apt/sources.list' and in
'/etc/cloud/templates/sources.list.debian.tmpl' and delete or comment out the 
below mentioned 4 lines:

> 
> # See
> http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.html
> # for how to upgrade to newer versions of the distribution.
Ignore the upgrade notice and i386. You can use buster until the end of 2022 
and I'm pretty sure google cloud is amd64.

> deb http://deb.debian.org/debian buster main
> deb-src http://deb.debian.org/debian buster main
> 
> ## Major bug fix updates produced after the final release of the
> ## distribution.
> deb http://security.debian.org/ buster/updates main
> deb-src http://security.debian.org/ buster/updates main

You can|must delete these 3 lines...
> deb [trusted=yes] http://deb.torproject.org/torproject.org buster main
> deb http://deb.torproject.org/torproject.org buster main 
> deb-src [trusted=yes] http://deb.torproject.org/torproject.org buster main

> ## Uncomment the following two lines to add software from the 'backports'
> ## repository.
> ##
> ## N.B. software from this repository may not have been tested as
> ## extensively as that contained in the main release, although it includes
> ## newer versions of some applications which may provide useful features.
> deb http://deb.debian.org/debian buster-backports main
> deb-src http://deb.debian.org/debian buster-backports main
... and this old one from debian stretch:
> deb http://ftp.de.debian.org/debian stretch main


> tor.list file:
> 
> deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg]
> https://deb.torproject.org/torproject.org amd64 main
> deb-src [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg]
> https://deb.torproject.org/torproject.org amd64 main
> deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg]
> https://deb.torproject.org/torproject.org  main
> deb-src [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg]
> https://deb.torproject.org/torproject.org  main
> deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg]
> https://deb.torproject.org/torproject.org buster main
> deb-src [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg]
> https://deb.torproject.org/torproject.org buster main
> deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg]
> https://deb.torproject.org/torproject.org tor-nightly-main- main
> deb-src [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg]
> https://deb.torproject.org/torproject.org tor-nightly-main- main
> deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg]
> https://deb.torproject.org/torproject.org tor-nightly-main-buster main
> deb-src [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg]
> https://deb.torproject.org/torproject.org tor-nightly-main-buster main
> 
> Please, what should the sources.list and tor.list files look like? I am
> sorry to ask. Thanks.

In '/etc/apt/sources.list.d/tor.list' just this one line:

deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://
deb.torproject.org/torproject.org buster main


Generally 'deb-src' are the package sources if you want to compile packages 
yourself. You don't need that. Not for Tor and not for Debian either. But it 
doesn't matter if you leave them, it occupies a few MB more in /var/cache/apt/
archives/


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Ext Relay Operators: Please Upgrade to 0.4.7.7!

[lists]

On Wednesday, May 4, 2022 11:31:05 PM CEST Mike Perry wrote:
> Tor 0.4.7.7-stable contains a very important performance improvement,
> called Congestion Control.
> 
> You can read more about this improvement here:
> https://blog.torproject.org/congestion-contrl-047/
> 
> The TL;DR is that users of Tor 0.4.7 will experience faster performance
> when using Exits or Onion Services that have upgraded to 0.4.7.

Is that why the advertised bandwidth jumps well over 100 MB for some relays? 
On April 25, for some, it went up steeply. Some have even overtaken XOR, the 
fastest exit so far. Or is a bwauth on steroid?
https://metrics.torproject.org/rs.html#search/flag:exit%20


by the way:
Buster also has a kernel upgrade. Upgrade Tor and reboot go well together.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Exit: Complaints of IP being used for "spam" despite exit policy

[lists]

On Tuesday, May 3, 2022 8:42:20 PM CEST Neel Chauhan wrote:

> A day or two ago, my Tor exit host, Psychz Networks, has sent me
> complaints about my IPs being used to send "spam" despite me having
> blocked Port 25 (and 465/587) in the exit policy.
> 
> Psychz threatened to block Port 25 even when my exit policy explicitly
> blocks 25/465/587.

Yes, unfortunately you get this SPAM abuse, although it is clear that the mail 
was submitted via a webmailer :-(

> Sometimes I think "is my FreeBSD exploited and being used to send spam",
> but then I also see Linux relays on other ISPs also on the blocklists.

It's actually very unlikely that a longer running exit can send mails. ;-)
I can't even send myself log mails from my exit IP's because all IP's are 
blacklisted. On abusix.com and similar.

> Yes, I am aware Tor exit relays will land on blacklists. But getting
> complaints from spam is new, especially when my relays are blocking
> SMTP.
> 
> I am worried I would have to find a new host if they continue
> complaining. Darn, Psychz has been one of the more reliable exit hosts
> (on-and-off) for many years, although they are more vigilant on abuse
> than say BuyVM.

If possible, try to get an ARIN SWIP record:
https://blog.torproject.org/tips-running-exit-node/
5. Get ARIN registration

99% of the abuse is f*cking auto-generated stuff from tools like fail2ban. If 
you reply, you will not get an answer or 'message is undeliverable' back.

> BuyVM is similarly priced (although my Psychz is an special offer) and
> solid but has too many exits. OVH and TerraHost only allow exits on much
> more expensive dedicated servers. Prgmr and HostMaze allow exits but has
> so-so peering.
https://rdp.sh/ is not overcrowded yet.

> I just hope Psychz doesn't continue to complain.

We all hope with you.
As I've mentioned here before, IPv6 only relays are important. An AS with 
IPv6/48 is affordable. Then it's much easier to set up your own bulletproof 
ISP.


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Debian is not allowing tor to update despite it being listed as a trusted respritory

[lists]

On Tuesday, May 3, 2022 7:10:00 PM CEST Keifer Bly wrote:
> I am not sure how to get rid of the trusty / ubuntu packages?

You just have to write 'buster' instead of 'trusty'. Either in /etc/apt/
sources.list or you have created the file /etc/apt/sources.list.d/tor.list?

> I simply followed the instructions here:
> https://support.torproject.org/apt/tor-deb-repo/

You are running oldstable 'buster', this guide has been updated for stable 
'bullseye' and testing 'bookworm'. The 'signed-by=foo-bar-keyring' is not yet 
required in buster, but it doesn't hurt.
The new 'deb.torproject.org-keyring' package renews both keyrings in:
/etc/apt/trusted.gpg.d/ and /usr/share/keyrings/

¹Apt-key will last be available in Debian 11 and Ubuntu 22.04.
Since bullseye, 'apt-key add' has been deprecated and is no longer available 
in bookworm. Only 'apt-key del' then still works.

¹https://manpages.debian.org/testing/apt/apt-key.8.en.html

Background info:
https://askubuntu.com/questions/1286545/what-commands-exactly-should-replace-the-deprecated-apt-key
or $websearch: Why apt-key is deprecated?


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Debian is not allowing tor to update despite it being listed as a trusted respritory

[lists]

On Tuesday, May 3, 2022 7:31:46 AM CEST Keifer Bly wrote:

> So I am running a tor relay on Debian, but no matter what when updating tor
> there is an “updating from such a respiritpry can’t be done securely and is
> therefore disabled by default”. Here is the log
> 
>  

In addition to the outdated certificates, you get Tor for Ubuntu and not 
Debian:

>  
> 
> Get:1 http://security.debian.org buster/updates InRelease [65.4 kB]
> 
> Hit:2 http://deb.debian.org/debian buster InRelease
> 
> Get:3 http://deb.debian.org/debian buster-updates InRelease [51.9 kB]
> 
> Get:4 http://deb.debian.org/debian buster-backports InRelease [46.7 kB]
> 
> Ign:5 http://ftp.de.debian.org/debian stretch InRelease
> 
> Hit:6 http://ftpde.debian.org/debian stretch Release
I would delete the outdated Debian stretch archives.

> Ign:7 http://deb.torproject.org/torproject.org trusty InRelease
> 
> Ign:8 http://deb.torproject.org/torproject.org trusty Release
> 

Trusty? Why are you using Tor for Ubuntu? For Debian Buster you should also 
use the buster archive:

deb https://deb.torproject.org/torproject.org buster main

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays