Re: [tor-relays] Next Tor relay operators meetup - May 11, 2024 at 19 UTC

[Toralf Förster via tor-relays]

On 5/2/24 18:48, gus wrote:

  - When: May 11, 19.00 UTC


hhm, the ESC in Malmö is at the same time :-/

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tor_bug_reached_count increase

[Toralf Förster via tor-relays]

On 4/19/24 22:53, tor--- via tor-relays wrote:

have a significant
tor_bug_reached_count rate (around 8 per second).


Here the rate is about 2-4 per hour (git-HEAD)

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Request for Feedback on Relay Node Update Management

[Toralf Förster via tor-relays]

On 3/26/24 09:54, Alessandro Greco via tor-relays wrote:

Recently, I've noticed an interesting pattern with my relay node (ID:
47B72187844C00AA5D524415E52E3BE81E63056B [1]). I've followed
TorProject's recommendations [2] and configured automatic updates, which
  has led to frequent restarts of the node to keep the Tor software
up-to-date.


I do run a bunch of Tor (bridges), all at Debian bookworm. I enabled
automatic unattended updates for all packages (not the so-alled
"security" ones). I did not observed any frequently restarts.

My configs are in [1] and [2].


[1]
https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup/templates/upgrade.j2
[2]
https://github.com/toralf/tor-relays/tree/main/playbooks/roles/setup/files

--
Toralf

___
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

[Toralf Förster via tor-relays]

On 2/15/24 17:16, li...@for-privacy.net wrote:

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";
};


I do have (in [1])

Unattended-Upgrade::Origins-Pattern {
"origin=*";
};
Unattended-Upgrade::Package-Blacklist {
};
Unattended-Upgrade::Automatic-Reboot "true";


which seems to work fine - it upgrades every package from every
repo/release if needed.


[1]
https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup/files/50unattended-upgrades

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] bridges for Lox

[Toralf Förster via tor-relays]

On 2/27/24 21:14, boldsuck wrote:

  Gentoo & FreeBSD-Port Dev's and users are years
ahead ;-)


Whilst I'd agree on that my Tor bridges and Snowflakes do run under a
recent Debian. However Tor et al are compiled from sources. [1] [2]


[1]
https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup-tor/tasks/tor-git.yaml
[2]
https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup-tor/tasks/lyrebird.yaml

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] bridges for Lox

[Toralf Förster via tor-relays]

On 2/27/24 16:38, boldsuck wrote:

ORPort 127.0.0.1:14255
ORPort [::1]:14255


I do not specified the ipv6 port explicietly:

  SandBox 0
  ORPort 127.0.0.1:auto
  AssumeReachable 1
  ExtORPort auto
  ServerTransportPlugin obfs4 exec /usr/bin/lyrebird

Would it be needed?
--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] bridges for Lox

[Toralf Förster via tor-relays]

On 2/26/24 20:07, meskio wrote:

Rdsys, the new bridgeDB, will not automatically assign bridges to Lox for now,
but will instead accept bridges with the 'BridgeDistribution lox' configured in
torrc.


BTW by accident I configured "any" but restarted tor with "lox" 2
minutes later. Does that work?

And FWIW:

root@luchs:~# grep lox /var/log/tor/notice.log
Feb 26 20:03:50.008 [warn] Unrecognized BridgeDistribution value "lox".
I'll assume you know what you are doing...

root@luchs:~# tor --version
Tor version 0.4.9.0-alpha-dev (git-b0b943a1613e2f9b).
Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.11,
Zlib 1.2.13, Liblzma N/A, Libzstd N/A and Glibc 2.36 as libc.
Tor compiled with GCC version 12.2.0

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] bridges for Lox

[Toralf Förster via tor-relays]

On 2/26/24 20:07, meskio wrote:

At the moment we're
looking for 10 new bridges for Lox.


9 left

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Recent Tor versions not reloading config on / ignoring HUP kill signal.

[Toralf Förster via tor-relays]

On 1/13/24 18:29, George Hartley via tor-relays wrote:


Is anyone else experiencing this?


Yes,

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

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relay question

[Toralf Förster via tor-relays]

On 12/8/23 04:19, Mulloch94 via tor-relays wrote:

-A INPUT -j DROP


HHm, what's about local traffic, e.g.: -A INPUT --in-interface lo -j ACCEPT
or ICMP, e.g.: -A INPUT -p icmp -j ACCEPT

To persist your firewall rules take a look at this doc [1]


[1] https://github.com/toralf/torutils#quick-start

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] snowflake prometheus metrics listen address

[Toralf Förster]

On 10/3/23 10:24, Fran via tor-relays wrote:


Any ideas?


yes - DNAT the remote prometheus ip to the local address [1]

[1]
https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup-snowflake/tasks/firewall.yaml#L10

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Grafana dashboards

[Toralf Förster]

Yesterday I stumbled together 2-3 dashboards [1] for Tor relay(s), Tor
Snowflake(s) and the DDoS solution [2].

Feedback is welcome.

[1] https://github.com/toralf/torutils/tree/main/dashboards
[2] https://github.com/toralf/torutils/tree/main

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Quick bugfix sharing regarding obfs4 malfunctioning

[Toralf Förster]

On 9/7/23 14:12, telekobold wrote:


A bit research reveled that apparently, an automatic update set the 
systemd setting "NoNewPrivileges=no" in 
/lib/systemd/system/tor@default.service and tor@.service [1] back to yes,


You probably need another entry too (grabed from [1]):

[Service]
NoNewPrivileges=no
AmbientCapabilities=CAP_NET_BIND_SERVICE


[1] 
https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup-tor/files/override_tor_service.conf

--
Toralf



OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] short conntrack DDoS attack

[Toralf Förster]

Few days ago the throughput of my Tor relay went down to nearly zero for
about 3 minutes. It turned out that the reason (maybe) was a change here
in my iptables rules. Especially I switched these 2 lines:

  iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
  iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

and run then few hours later into problems. And switched back ofc.
An explanation for the dropdown was given in [1]. Given that the
explanation is right:

How is the Tor application harmed if an attacker mangles packets so that
the state of them are INVALID for the conntrack module but they do pass
the RELATED,ESTABLISHED rule ?


[1] https://forums.gentoo.org/viewtopic-p-8798034.html
--
Toralf
___
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!

[Toralf Förster]

On 8/1/23 19:38, li...@for-privacy.net wrote:

Yes ;-)

cool - this simplifies my Ansible role (I randomly choosed an ORPort
between 30K and 62K)


Unfortunately, they come every 1-2 hours

np - I'll ignore that

Thx !
--
Toralf

___
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!

[Toralf Förster]

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 ? :

 "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'.",


--
Toralf



OpenPGP_signature
Description: OpenPGP digital signature
___
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

[Toralf Förster]

On 6/26/23 23:44, gus wrote:

  - Recommendation: Do not run snowflake proxy on the same IP as a
 relay/bridge. It's a good call to run it on a machine with public
 dynamic IP address.


I setup 6 snowflakes as VPS with a fixed IP.
After which time those IPs should be changed ?

--
Toralf



OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] mulitply ipv6 bridge lines for a single bridge

[Toralf Förster]

Given that hosters of a VPS often gives a big /48, /56 or /64 ipv6 
subnet to a VPS I do wonder if the BridgeLine for ipv6 could benefit 
from that?


With

  ip6tables -t nat -I PREROUTING -p tcp -j DNAT --to-destination [obfs4 
address]

  /usr/sbin/ip6tables-save > /etc/iptables/rules.v6

all incoming TCPv6 packets would be flow to the bridge address. This 
idea is implemented in [1]. BTW there I do change the factory default 
ipv6 address into a random one too.



[1] 
https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup/tasks/network.yaml

--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
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!

[Toralf Förster]

On 3/22/23 20:25, gus wrote:

  But here's the trick: you need to run it on a
residential connection -- you won't need a static IPv4 --,


So the local bridge reports its (eg at 4 o'clock in the morning changed)
ip to the bridge db asap? And then ?

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] export iptables metrics

[Toralf Förster]

I found the time and wrote a Bash script [1] to export iptables and
ipset metrics to Prometheus/Grafana.

It works at least with [2].

[1] https://github.com/toralf/torutils/blob/main/metrics.sh
[2] https://github.com/toralf/torutils#readme

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Too Many Connections

[Toralf Förster]

On 3/15/23 03:19, Jeff Teitel wrote:

Conntrack.sh shows count: 65535.

You can increase that size, look at [1] for an example.


[1] https://github.com/toralf/torutils/blob/main/ipv4-rules.sh#L157

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] RFC: does a private exit would work?

[Toralf Förster]

On 3/4/23 17:29, gus wrote:

What's the goal? To have a private exit that only you can use?


Indeed, similar goal as for private bridges.


There is this very interesting paper and project called HebTor:
https://dl.acm.org/doi/10.1145/3372297.3417245


Thx, so I have sth to read.

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] RFC: does a private exit would work?

[Toralf Förster]

tl;dr;
restricted access + usage of an exit


longer:
An exit is sooner or later abused. A reduced exit policy does not 
prevent that.


What about setup a tor exit relay with 'PublishServerDescriptor = 0' ?

Having an access line like for bridges would restrict the access. An 
alternative could be a port knockig + iptables solution.


Objections and comments are welcome.

--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] cannot keep my bridge up

[Toralf Förster]

On 12/20/22 15:27, Anonforpeace via tor-relays wrote:

Dec 20 08:55:16 mxh-HP-Compaq-Pro-6300-SFF kernel: [137278.310446]
audit: type=1400 audit(1671544516.974:36): apparmor="DENIED"
operation="open" profile="system_tor"
name="/sys/kernel/mm/transparent_hugepage/hpage_pmd_size" pid=17728
comm="obfs4proxy" requested_mask="r" denied_mask="r" fsuid=128 ouid=0


What about this ?

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How to reduce tor CPU load on a single bridge?

[Toralf Förster]

On 12/9/22 07:02, David Fifield wrote:

But now there is rdsys and bridgestrap, which may have the ability to
test the obfs4 port rather than the ORPort. I cannot say whether that
removes the requirement to expose the ORPort.


Would be a step toward to make scanning for bridges harder IMO, if the 
ORPort is no longer needed to be exposed.


--
Toralf



OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] upcoming directory authority changes

[Toralf Förster]

On 12/6/22 19:44, Roger Dingledine wrote:

But it seems
like this role separation never quite matches up well to the security
issues that arise in practice, whereas it definitely adds complexity
both to the design and to operation. This piece of the design could use
some new ideas.


So the concept of off-line master keys doesn't help too much nowadays?

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] upcoming directory authority changes

[Toralf Förster]

On 12/6/22 19:44, Roger Dingledine wrote:

  We
could start by encouraging directory authority operators to participate
in the monthly virtual relay operator meetups.


I'd appreciate it.

--
Toralf



OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] preventing DDoS is more than just network filtering

[Toralf Förster]

On 11/8/22 10:57, Chris wrote:

The main reason is that a simple SYN flood can quickly fill up your
conntrack table and then legitimate packets are quietly dropped and you
won't see any problems thinking everything is perfect with your server
unless you dig into your system logs.


Hhm, my system log doesn't show any problems, maybe due to (or
regardless of?):
CONFIG_SYN_COOKIES=y
?
Nevertheless, I updated the Readme to explain my point of view [1] [2].

[1] https://github.com/toralf/torutils#block-ddos-traffic
[2] https://github.com/toralf/torutils#rule-set

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] preventing DDoS is more than just network filtering

[Toralf Förster]

The graphs in [1] and [2] are IMO good examples related to [3]:

	"... in addition to network filtering, the (currently) sharp input 
signal ... is transformed into a smeared output response ... This shall 
make it harder for an attacker to gather infromation using time 
correlation techniques."


Feedback is welcome.


[1] https://github.com/toralf/torutils/blob/main/doc/network-metric.svg
[2] 
https://github.com/toralf/torutils/blob/main/doc/network-metric-nextday.svg

[3] https://github.com/toralf/torutils/tree/main#block-ddos-traffic

--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
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

[Toralf Förster]

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 ;)

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] security update for obfs4proxy

[Toralf Förster]

On 10/17/22 11:41, meskio wrote:

Will be nice to add those fixes to the package. Maybe you can open two issues on
the debian bugtracker for them.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021911.

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] security update for obfs4proxy

[Toralf Förster]

On 10/16/22 09:50, Toralf Förster wrote:


After configuring the installation of the unattended_upgrade package to
consider all packages [1] the new obfs4proxy was installed - but Tor was
not restarted nor obfs4proxy reloaded.

Isn't this a task for the software package ?


And IMO the Debian package should re-apply any setcap settings made to
the exe before, eg.:

setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy

or?

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] security update for obfs4proxy

[Toralf Förster]

On 10/14/22 11:28, meskio wrote:

If you use debian you can find the Debian package in stable-backports:
   https://packages.debian.org/stable-backports/obfs4proxy


After configuring the installation of the unattended_upgrade package to
consider all packages [1] the new obfs4proxy was installed - but Tor was
not restarted nor obfs4proxy reloaded.

Isn't this a task for the software package ?


[1]
https://github.com/toralf/tor-relays/commit/37d2cc993c5b17eaa7510cb4a589b62f705c26a0

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] security update for obfs4proxy

[Toralf Förster]

On 10/14/22 19:09, meskio wrote:

The upstream changelog is here:
https://gitlab.com/yawning/obfs4/-/blob/master/ChangeLog
But I understand is not easy to understand what the problem is from that
changelog.


Indeed.

BTW the fix was made 5 weeks ago, so I do assume, the (eg. Debian)
package needed time to stabilize, or ?

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] security update for obfs4proxy

[Toralf Förster]

On 10/14/22 11:28, meskio wrote:

The latest version of obfs4proxy (0.0.14) comes with an important security fix.


Is there a Changelog available ?

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Moving middle relays to bridges?

[Toralf Förster]

On 10/4/22 18:15, Isaac Grover, Aileron I.T. wrote:

According to tor metrics, there have been nearly three times the number
of relays as bridges over the last three months so I would like to move
my handful of middle relays to bridges.  They will keep their same IP
address.  Is there a best practice with regards to doing this so the
directories don’t get confused?



Years ago I learnt that relays were preferred over bridges.

Nevertheless at least you need new IP addresses b/c the ip addresses of
your relays are already known.

--
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] many connections

[Toralf Förster]

On 10/3/22 12:26, Richie wrote:


My apologies if its not the right place to ask.
greetz
Korrupt


Every place is the right place for feedback, thx for yours !

I updated the readme [1] at the experimental branch and will merge it to 
main soon. Feel free to give additional feedback -and/or- make directly 
a pull request at GH.



[1] https://github.com/toralf/torutils/tree/experimental

--
Toralf



OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] many connections

[Toralf Förster]

On 9/30/22 17:57, Sandro Auerbach wrote:

30 minutes later still 22000 connections...
Have you observed something similar?


I reduced those spikes [1] by using certain iptables rules [2].


[1] https://github.com/toralf/torutils/blob/main/sysstat.svg
[2] https://github.com/toralf/torutils

--
Toralf



OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] missing IPv6 close events

[Toralf Förster]

Playing with Python and Stem I wrote a script to monitor the
ORStatus.CLOSED event reasons [1]. A helper script [2] gives statistics
from those data.

From the last 2 days I got:

$> orstatus-stats.sh /tmp/orstatus.29051 CONNECTRESET
   6197 CONNECTRESET
  13214 DONE
  18769 IOERROR
 58 NOROUTE
   1661 TIMEOUT
   2562 TLS_ERROR
  42461

I was wondering if it is expected that DONE is just a 1/4 of all reasons.

And I do wonder why all events are IPv4 only.


[1] https://github.com/toralf/torutils/blob/main/orstatus.py
[2] https://github.com/toralf/torutils/blob/main/orstatus-stats.sh

--
Toralf
___
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

[Toralf Förster]

On 8/18/22 22:10, li...@for-privacy.net wrote:

IPv6 connections should better be limited to /48 subnets in the Tor protocol. 
Or /32


Limiting IPv6 to N connections per /64 will definitely affect relays of
https://metrics.torproject.org/rs.html#search/2a0b:f4c2:2

Similar to their /24 IPv4 segment, eg.
https://metrics.torproject.org/rs.html#search/185.220.101


FWIW Hetzner gives /64 to its customers.

--
Toralf
___
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

[Toralf Förster]

On 8/18/22 21:31, li...@for-privacy.net wrote:

If that's really the case, I can set up the ip|nftables rules much more
strictly.


Currently I do have it set to "3" [1], before it was 2, which seemed to
work too.


[1] https://github.com/toralf/torutils/blob/main/ipv4-rules.sh

--
Toralf
___
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

[Toralf Förster]

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
341 CONNECTRESET
 78 DONE
783 IOERROR

Data were collected with [1] over past 20 hours.



[1] https://github.com/toralf/torutils/blob/main/orstatus.py

--
Toralf
___
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

[Toralf Förster]

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 ?
Doesn't 1 TCP connection between 2 relays will handle all circuits going
between them ?

--
Toralf
___
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

[Toralf Förster]

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:

$> 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

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Refuse Guard flag

[Toralf Förster]

On 8/2/22 20:58, Eldalië via tor-relays wrote:

Recently I noticed that my ISP started to reset my IP a few
hours after the node gets the Guard flag,


The Guard flag is given after a more or less constant time (or?) - so
I'd not see a conincidence here.

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] An attempt to block spam ip addresses

[Toralf Förster]

Issue 40636 and others deal with DDoS / concurrent connections. Here're
few numbers from my attempt [1] of the last days to block such ip
addresses. The stats are from 2 relays running at the same ip.

Currently there're 700 ip addresses (15 IPv6) caught in the denylist.
Those either opened >4 connections to the same orport and/or produced
>12 new connection attemps within 5 minutes to the orport.

Those system do re-appear quickly if the denylist is flushed.

Within one hour over 500K packets, mainly TCP connection attempts, are
dropped.

Furthermore the number of used sockets at the system is reduced from
>35K to about 21K.

Nevertheless both relays spew the warnings "Your computer is too slow"
and "General overload" from time to time. I do assume that this is a
layer 7 problem and therefore can't be fixed at layer 3.

The filter is build up from iptables. Scripts for IPv4 and IPv6 can be
found under [2] and [3] respectively.


[1] https://gitlab.torproject.org/tpo/core/tor/-/issues/40636#note_2821683
[2] https://github.com/toralf/torutils/blob/main/ipv4-rules.sh
[3] https://github.com/toralf/torutils/blob/main/ipv6-rules.sh

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] relay memory leak?

[Toralf Förster]

On 7/25/22 19:56, David Goulet wrote:

On Linux, we use /proc/meminfo (MemTotal line) and so whatever also max limit
the kernel would put for that.


Here both Tor relays do use about 4 GB each:

$ pgrep tor | xargs -n 1 pmap | grep total
 total  4211476K
 total  4226580K

whilst more would be available:

$ head /proc/meminfo
MemTotal:   131830284 kB
MemFree: 3395252 kB
MemAvailable:   105765448 kB
Buffers:  40 kB
Cached: 97275636 kB
SwapCached:47656 kB
Active: 7976 kB
Inactive:   34977700 kB
Active(anon):6927704 kB
Inactive(anon): 14077848 kB


--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] relay memory leak?

[Toralf Förster]

On 7/25/22 14:48, David Goulet wrote:

  It is usually set around 75% of your total memory


Is there's a max limit ?

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relay Overloaded and Dropping Onionskins

[Toralf Förster]

On 7/20/22 23:34, bidulock_ringrose--- via tor-relays wrote:
Side note: I am using Toralf's ddos-inbound script, which has not 
dropped any connections at all for me when using the -b then -s switch.


In the mean while I try here for my 2 relays a different approach [1].
In the meanwhile I do prefer the iptables only solution over the 
scripted one.



[1] https://gitlab.torproject.org/tpo/core/tor/-/issues/40636#note_2821683

--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] We're trying out guard-n-primary-guards-to-use=2

[Toralf Förster]

On 7/10/22 22:28, Logforme wrote:

A week ago I implemented  connection limits per Toralf's post:
iptables -A INPUT -p tcp --destination-port  443 -m connlimit 
--connlimit-mask 32 --connlimit-above 30 -j DROP

This reduced the number of connections to about 1.

I just now noticed that the relay is flagged as overloaded. What to do?
Decrease the connection limit from 32 to .. what?
Decrease my RelayBandwidthRate even more? Seems like giving in to the DoSer. 



There're still about 200-300 VPS systems DDoS'ing my 2 Tor relays.
The iptables rule halfs the pressure.
I could nearly fully stop the DDoS by using [1].


[1] https://github.com/toralf/torutils/blob/master/ddos-inbound.sh

--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
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

[Toralf Förster]

On 6/15/22 20:17, Eddie wrote:
I have been running the relay for almost 5 years without any previous 
flagging.


There are block list providers which have Tor exit relays lists and 
sells those lists to their customers.

Mayve they extend their algorithm to all Tor relays.

Anyway, "Do not run a relay at home." might be a solution.

--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor 0.4.7.7 Segmentation fault on Ubuntu 22.04 caused by "rseq"

[Toralf Förster]

On 5/7/22 05:56, Xiaoqi Chen (Danny) wrote:


I temporarily mitigated the issue by turning off sandbox mode (remove
"Sandbox 1" in torrc). Does anyone know how to properly resolve the
crashing issue?


usually by filing a bug here :
https://gitlab.torproject.org/tpo/core/tor/-/issues/new

;)

--
Toralf
___
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

[Toralf Förster]

On 5/3/22 07:31, Keifer Bly wrote:

Err:15 https://deb.torproject.org/torproject.org amd64 Release

Certificate verification failed: The certificate is NOT trusted. The 
certificate chain uses expired certificate.  Could not handshake: Error 
in the certificate verification. [IP: 95.216.163.36 443]



Maybe renew the key ?

--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] comments, hints and tipps for an ansible role to deploy Tor bridges

[Toralf Förster]

I do appreciate those for my attempt here:

https://github.com/toralf/tor-relays

TIA
--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] update obfs4proxy if you run a bridge

[Toralf Förster]

On 3/21/22 18:45, meskio wrote:

Thank you for running bridges,
let me know if you need any help upgrading it.


I'm not really familar with Debian and do wonder, what line I have to 
add to /etc/apt/apt.conf.d/50unattended-upgrades to get that 
automatically installed ? Maybe I need to add the repo too ?


Currently it looks like:


~# cat /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Origins-Pattern {
"origin=Debian,codename=${distro_codename},label=Debian";
"origin=Debian,codename=${distro_codename},label=Debian-Security";

"origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
"origin=TorProject";
};
Unattended-Upgrade::Package-Blacklist {
};
Unattended-Upgrade::Automatic-Reboot "true";



--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Connection burst

[Toralf Förster]

On 3/20/22 17:14, Felix wrote:

They were kicked off by the packetfilter


IMO it is a bad idea to filter Tor traffic.

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Operator Meetup (Saturday, March 5th @ 2000 UTC)

[Toralf Förster]

On 3/14/22 09:19, Georg Koppen wrote:
But, there is a lag between when a new bridge appears and when Russia 
starts blocking it. That lag is often a week or more these days.


So, after a week the affected bridges can be stopped ?
--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Moving Bridges

[Toralf Förster]

On 3/8/22 19:48, Eddie wrote:

as I'm certain that there's no way to "move" them to the new location

Yes.

And that's why I do wonder why you want to "continue" the stats ?

--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Ansible role to deploy Bridges

[Toralf Förster]

On 3/8/22 18:39, Erasme via tor-relays wrote:

Thanks to the community, the Ansible role now supports more operating systems 
to deploy obfs4 bridges.

- Debian 11


If bridges are added to the hosts of the inventory, then existing 
bridges are restarted at "-t install_all".


What is the preferred way to reload the Tor service of those already 
running bridges instead restarting them ? (I like to avoid cutting 
existing connections to the established bridges).


--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] snowflake incoming UDP ports

[Toralf Förster]

On 2/19/22 12:48, meskio wrote:

If you have restricted NAT I would recommend you to open the UDP port range of
32768-60999.


Thx, I opened those UDP ports for incoming UDP traffic.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: 
https://meskio.net/crypto.txt 


OT, but: You're still at freenode ?


--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] snowflake incoming UDP ports

[Toralf Förster]

I do simply run here

 ~/devel/go/src/snowflake/proxy/proxy &>>/tmp/snowflake-proxy.log &

and was wondering if I have to open special UDP inbound ports ?

From the stats snowflake iseems to be working:

2022/02/18 19:29:59 In the last 1h0m0s, there are 13 connections.
Traffic Relayed ↑ 192 MB, ↓ 192 MB.
2022/02/18 20:29:59 In the last 1h0m0s, there are 21 connections.
Traffic Relayed ↑ 451 MB, ↓ 451 MB.
2022/02/18 21:29:59 In the last 1h0m0s, there are 9 connections. Traffic
Relayed ↑ 236 MB, ↓ 236 MB.

but b/c I do have a rather restrict inbound firewall rule set I'm
wondering about that.

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [Censorship in Russia] More of my bridges got blocked

[Toralf Förster]

On 12/29/21 18:45, Toralf Förster wrote:
Said that you should set "PublishServerDescriptor 0" at bridges where 
you distribute the connection info yourself.


Or maybe set it to

BridgeDistribution none

to have bridge stats at metrics.org.

--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [Censorship in Russia] More of my bridges got blocked

[Toralf Förster]

On 12/29/21 15:37, Space Oddity via tor-relays wrote:

Also, I can not rule out that some step in my distribution chain was
compromised -- I gave out these bridges privately to a few friends.


IMO you should not mix private brtdges with those where you delegate the 
to distribute the connection info eg to the torproject.
Said that you should set "PublishServerDescriptor 0" at bridges where 
you distribute the connection info yourself.



--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [Looking for feedback] An easier way to declare families

[Toralf Förster]

On 12/14/21 17:06, Nick Mathewson wrote:


A relay operator has asked me, offline, if it is possible under this 
proposal for a relay to belong to more than one family.  (For example, 
if there were two relay operators who each operated some relays on their 
own, but also operated some relays jointly, it might make sense to put 
the jointly operated relays into _both_ of the operators' families .)


Why not just consider the shared set as an own family?

--
Toralf


OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Compression bomb from dizum

[Toralf Förster]

On 11/6/21 10:39 PM, Logforme wrote:

Got the following in my log today:
Nov 06 18:19:01.000 [warn] Possible compression bomb; abandoning stream.
Nov 06 18:19:01.000 [warn] Unable to decompress HTTP body (tried 
Zstandard compressed, on Directory connection (client reading) with 
45.66.33.45:80).

45.66.33.45 is tor.dizum.com, a Tor directory authority.

False positive or a problem generating directory info at dizum?


I got the same at 2 relays at 18:02:56.000
--
Toralf



OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [Looking for feedback] An easier way to declare families

[Toralf Förster]

On 11/6/21 3:36 PM, Nick Mathewson wrote:

Option 3 requires regular updates to all the relays in the family,
which makes it cumbersome.  


Except for people who already have offline relay keys.
For those it is just 1 additonal file to copy ;)

--
Toralf



OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Dropped off consensus (0.4.4.5) - reason is Libressl 3.2.1 - 3.4.1 seems ok

[Toralf Förster]

On 10/23/21 12:41 AM, Felix wrote:


Toralf, it would be super nice if you could check on your end, or
somebody else can confirm?


Hi,

we here in Gentoo decided to stop supporting LibreSSL, so I cannot tell
you if it would work here or not.

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Overloaded state indicator on relay-search

[Toralf Förster]

On 9/23/21 3:39 PM, Silvia/Hiro wrote:

Let us known how you find this new feature.

It would be nice if even the search form would have that feature too.
Currently here all is green:
https://metrics.torproject.org/rs.html#search/zwiebeltoralf
wherease the details of each of the 2 relays shows the overload indicator.

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Overloaded state indicator on relay-search

[Toralf Förster]

On 9/25/21 4:11 PM, Silvia/Hiro wrote:

If it happens again there are two buttons at the end of the page where
you can see the latest server and extra-info descriptors.

Only, if the DirPort is (still) opened, or ?

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] New round of measuring the accuracy of Tor relays' advertised bandwidth

[Toralf Förster]

On 9/2/21 9:11 AM, Georg Koppen wrote:

No. As far as it matters for the test those two relays are independent
relays which each get tested as two random relays would get.


Except, that both shares the same network card ...

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] New round of measuring the accuracy of Tor relays' advertised bandwidth

[Toralf Förster]

On 8/25/21 12:02 PM, Georg Koppen wrote:

Hello!

You might recall we ran two "speed tests" so far for investigating the
accuracy of a relay's advertised bandwidth, one in 2021[1] and another
one earlier this year[2].


I do run 2 relays at the same ip address.

Do the tests consider that ?

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Move or Recreate

[Toralf Förster]

On 8/15/21 6:04 AM, Eddie wrote:

I know how to maintain the keys for both relays and bridges for the
replacements, but was wondering exactly what does that buy me, as both
will now be running at different IPv4/6 addresses.

As opposed to just blowing away the current ones and starting fresh copies.


Using offline master keys blows away that question ;-)

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Verify my Relay

[Toralf Förster]

On 6/24/21 1:59 AM, S1l3nt Hash wrote:

Address xxx.xxx.xxx.xxx (static public ip)
DirPort 9030 NoAdvertise
DirPort xxx.xxx.xxx.xxx:9030 NoListen (static public ip)
ORPort 9001 NoAdvertise
ORPort xxx.xxx.xxx.xxx:9001 NoListen (static public ip)


Hiding those IP addresses (and other *sensitive*) data is a good idea in
general.
OTOH the IP address of your relay is seen in every public accessible
metrics.

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Problem moving my Tor Bridge Relay

[Toralf Förster]

On 6/12/21 5:42 PM, Cor.ling wrote:

Jun 12 15:13:59 PC tor[38309]: Jun 12 15:13:59.476 [warn]
/var/lib/tor/keys is not owned by this user (debian-tor, 124) but by
root (0). Perhaps you are running Tor as the wrong user?
Jun 12 15:13:59 PC tor[38309]: Jun 12 15:13:59.476 [warn] Failed to
parse/validate config: Couldn't access private data directory
"/var/lib/tor/keys"


Wrong file/dor ownership could be the root cause for the trouble.


--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] let's make ContactInfo mandatory for exits (and warn others)

[Toralf Förster]

On 4/24/21 9:21 PM, nusenu wrote:

Hi Toralf,

Toralf Förster:

On 4/24/21 12:11 PM, nusenu wrote:

* tor 0.4.7: no longer assign the exit flag to relays not having a ContactInfo 
(< 5 chars) in their descriptor.
  Log a warning for relay operators,


I've opened 1-2 dozen ports - except 80 sand 443 at 2 relays.
So I do not have the Exit flag.


I don't see how your email es related to my email? :)
Would you mind to elaborate?

kind regards,
nusenu


Well, not really to your email,just to the fraction "assign the exit
flag" - yeah, sry, maybe a separate thread would be better.

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] let's make ContactInfo mandatory for exits (and warn others)

[Toralf Förster]

On 4/24/21 12:11 PM, nusenu wrote:

* tor 0.4.7: no longer assign the exit flag to relays not having a ContactInfo 
(< 5 chars) in their descriptor.
 Log a warning for relay operators,


I've opened 1-2 dozen ports - except 80 sand 443 at 2 relays.
So I do not have the Exit flag.
Nevertheless I see about 100 exit connections at 2 relays here and do
wonder now if opening those ports is ok and which types of clients use
them ?

Here're the data of one of the relays got with [1]

ORport 9051
 0.4.7.0-alpha-dev   uptime: 7-19:57:56   flags: Fast, Guard, HSDir,
Running, Stable, V2Dir, Valid

+--+--+--+
| Type | IPv4 | IPv6 |
+--+--+--+
| Inbound to our OR from relay | 1899 |  260 |
| Inbound to our OR from other | 3361 |   32 |
| Inbound to our ControlPort   |1 |  |
| Outbound to relay OR | 4770 |  956 |
| Outbound to relay non-OR |1 |  |
| Outbound exit traffic|   56 |9 |
| Outbound unknown |   10 |  |
+--+--+--+
| Total| 10098 | 1257 |
+--+--+--+

+--+--+--+
| Exit Port| IPv4 | IPv6 |
+--+--+--+
| 53 (DNS) |1 |  |
| 563 (NNTPS)  |2 |  |
| 853  |2 |  |
| 5222 (Jabber)|   31 |5 |
| 5223 (Jabber)|7 |  |
| 6667 (IRC)   |5 |2 |
| 6697 (IRC)   |8 |2 |
+--+--+--+
| Total|   56 |9 |
+--+--+--+


[1] https://github.com/toralf/torutils/blob/master/info.py
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] how does one file a problem report?

[Toralf Förster]

On 4/24/21 7:18 AM, Scott Bennett wrote:

  I went through the process to get an account at gitlab.torproject.org
in order to file a problem report for a very irksome and tiresome daily
abort in tor 0.4.5.7 and 0.4.6.1-alpha under FreeBSD 11.4.  However, I do
not find anywhere on that web site for filing a PR, nor do I see any
instructions as to how to file a PR.  Would someone please point me to the
relevant information?  Bugzilla seems to be much easier to use.

GitLab accepts only MR (merge request) - not PR (pull request).
But for the start you might just file an "issue" -a ftzer you got a user id.


--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] OS Upgrade

[Toralf Förster]

On 4/23/21 2:03 PM, Matt Traudt wrote:

Keeping tor up to date, and the OS and all the other things installed on
it up to date, is much more important than maintaining your flags.
You'll get them back.


IMO relays with a way too long uptime should get a penalty.

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Questions about consensus votes

[Toralf Förster]

On 4/21/21 12:15 PM, Sebastian Hahn wrote:

Moria applies its own criteria which differ from dir-spec. Its operator is 
testing future improvements to the Tor network and therefore frequently doesn't 
follow all the specs.

bastet too, or ?

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Fallback Directories - Upcoming Change

[Toralf Förster]

On 4/7/21 9:04 PM, David Goulet wrote:

Over time, we will remove or add more relays at each minor release if the set
of fallback directories not working reaches a 25% threshold or more.


In the past a fallback dir volunteer committed himself to have address
and port stable for 2 years.

If a relay is now removed from the fallback directory list - how long
shall the Tor relay operator wait before he can change the address
and/or port?
Technically speaking, how long does it usually takes till a Tor
(browser) version containing the new fallback dir is spreaded out mostly?

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] syn flood iptables rule

[Toralf Förster]

On 2/22/21 3:27 PM, Toralf Förster wrote:


  # DDoS
  $IPT -A INPUT -p tcp -m state --state NEW -m recent --name synflood --set
  $IPT -A INPUT -p tcp -m state --state NEW -m recent --name synflood
--update --seconds 60 --hitcount 10 -j DROP


just for the record:

In the emanwhile I do think that this idea was BS.

The reason is that if an advisory spoofs the sender address then this
eventually blocks the (spoofed) sender address thereby.

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] ipv6 ORPort + DIRPort too ?

[Toralf Förster]

On 3/27/21 11:05 AM, Petrusko wrote:

And I'm not sure if I can serve DIRPort on the ipv6 too ?


If I understood it correctly a DirPort are no longer needed for latest
Tor software version.
So you should be fine with opened IPv4|6 ORports only.

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] is this valid bridge config

[Toralf Förster]

On 3/23/21 4:13 PM, gi vian wrote:

ExitPolicy reject *:*

IMO this is not needed


--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] ECONNREFUSED

[Toralf Förster]

On 3/16/21 2:44 PM, tor wrote:


However, the status page keeps saying I'm dysfunctional with a ECONNREFUSED:
https://bridges.torproject.org/status?id=E120A0492F789F5367EAD84C64F92EE279018F98




Wasn't aware of that status page - my bridge is listed as
* obfs4: dysfunctional

OTOH I can connect to it with obfs4 fine from my desktop and verified
that obfs4 is working - so maybe the bridge check is wrong ?

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Bridge operator iat_mode setting

[Toralf Förster]

On 2/25/21 6:32 PM, niftybunny wrote:

And why did I read about this the first time in a mailing list?


+1

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Bridge operator iat_mode setting

[Toralf Förster]

On 2/24/21 9:34 PM, William Kane wrote:

Thank you for running obfs4 bridges with iat_mode != 0, only very few
obfs4 bridges support the additional traffic obfuscation in both
directions.

SO why is this not the default?

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Bridge operator iat_mode setting

[Toralf Förster]

On 2/24/21 9:34 PM, William Kane wrote:

Thank you for running obfs4 bridges with iat_mode != 0, only very few
obfs4 bridges support the additional traffic obfuscation in both
directions.


At my client I have iat_mode=2 set but I do wonder how to set that as
default at a bridge?

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] syn flood iptables rule

[Toralf Förster]

On 2/22/21 7:29 PM, William Kane wrote:

A hard limit of 9 might be a little too low - then again, a legit,
unmodified tor binary would hold it's TCP connection established for
as long as needed -

Hhm, I'm really under the impression that even 5 or 4 should be enough.
If a client connects more often than every 15 seconds to its guard or a
relay opens a conenction for more often than 4x per minute to another
relay - then they are modified, or ?

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] syn flood iptables rule

[Toralf Förster]

On 2/22/21 7:44 PM, Stephen Mollett wrote:


Have you tried adding "xt_recent.ip_list_tot=" to your kernel
command line? That formula works for most module parameters when their
module is built-in, I think.

Stephen


Yep, that works.
Thx.

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] syn flood iptables rule

[Toralf Förster]

The following 3 statements

  # Make sure NEW incoming tcp connections are SYN packets; otherwise
we need to drop them.
  $IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

  # DDoS
  $IPT -A INPUT -p tcp -m state --state NEW -m recent --name synflood --set
  $IPT -A INPUT -p tcp -m state --state NEW -m recent --name synflood
--update --seconds 60 --hitcount 10 -j DROP

seems to work and to help here ata fast Tor relay. CPU went down from
109% to 95%. There're 500 connections less than before for a Tor fast relay.

The /proc/net/xt_recent/synflood is quickly filled.
Unfortunately I cannot change the "ip_list_tot" of "xt_recent" b/c I do
use a non-modular kernel. Does anybody knows a circumvention?

Are there any objections against this approach?
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] anyone else getting sync floods from russia?

[Toralf Förster]

On 2/22/21 1:01 AM, li...@for-privacy.net wrote:

Multiport example:
# Up to 15 ports can be specified. A port range (port:port) counts as
two ports.
# Drop incoming connections which make more than 10 connection attempts
upon ports x-y within 1 minute
-A INPUT -p tcp -m multiport --dports xx:yy -m state --state NEW -m
recent --name syfloo --set
-A INPUT -p tcp -m multiport --dports xx:yy -m state --state NEW -m
recent --name syfloo --update --seconds 60 --hitcount 10 -j DROP


yeah, cool, I do wonder if "-m multiport --dports xx:yy" is needed ?

> --connlimit-upto & --connlimit-above looks interesting too.

That I got never to work

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] anyone else getting sync floods from russia?

[Toralf Förster]

On 2/21/21 12:37 PM, niftybunny wrote:

If I get say 2 connections from a single IP it would be blocked with 
iptables.

Even much less looks unusal

With this command

watch -d -x bash -c 'ss --all --numeric --processes state syn-recv |
sort -k 5 -n'

I do see a handful of addresses - and at least one (rather new) Tor
relay is among them - which makes one SYN-RECV after the other w/o
finishing the handshake.


--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] anyone else getting sync floods from russia?

[Toralf Förster]

On 2/20/21 12:29 PM, niftybunny wrote:

We already changed the timers on the TCP connections and we have scripts 
running which are blocking IPs who will send us x connections. Right now 
they changed tactics and for me it looks like SYNC flood from datacenter IP 
ranges and a few 100 IPs which undermine the easy blocking.

Would an iptables ruel with "recent" and "limit" be a solution here ?
If yes, how do you use that (do you have a code snippet)?

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] anyone else getting sync floods from russia?

[Toralf Förster]

On 2/20/21 2:25 AM, niftybunny wrote:

https://i.imgur.com/nDbaXqH.png 

https://i.imgur.com/Y5259wW.png 

Yep, I do wonder if sth like

netstat --tcp -n -4 | perl -wane ' BEGIN { $Hist=(); } { next unless
(m/^tcp/); ($Remote) = split(/:/, $F[4]); $Hist{$Remote}++; } END {
foreach my $key (sort { $Hist{$b} <=> $Hist{$a} || $a cmp $b } keys
%Hist) { printf("%-15s %5i\n", $key, $Hist{$key}) } }' | head -n 40

would help in any case ?

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Huge increase in bridge connections

[Toralf Förster]

On 2/12/21 2:04 PM, Logforme wrote:
Don't know if it's connected but my 2 guard relays jumped from the 
normal 2k clients to over 6k during a 24h period.

https
IMO it is uncommon. FWIW I observed a jump from 18K to 34K at 10th of 
February around 10:00 pm UTC, slowly decreasing now.


--
Toralf



OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Is my relay broken? No stable, hsdir or guard flags

[Toralf Förster]

On 1/30/21 5:59 AM, Scott Bennett wrote:

  Or, as an alternative to the above proposal, newly awakened authorities'
votes regarding time-dependent flags should be ignored by other authorities
until the newly awakened have been awake at least, say, ten days?


I do wonder if this helps if all authorities suffer from the same 
issue/architectural fla/DDos/bug ?


--
Toralf



OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Server under attack according to my hoster

[Toralf Förster]

On 1/22/21 6:04 PM, lists.torproject@stein-io.de wrote:
Today I received a notification that my server is "under attack" since 
my server got over the threshold of 300k packets/s. At the time of the 
mail it seems to be about 450k pps .


I do run 2 Tor relays at 1 Hetzner host and do have rcpcks/s and 
txpcks/s of about 80,000 at that system combined for both relays.

--
Toralf



OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Introducing new bridge status page

[Toralf Förster]

On 1/11/21 9:03 PM, Philipp Winter wrote:

FINGERPRINT is your bridge's fingerprint or its hashed fingerprint --
either works.


for public bridges ;-)

--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] OrNetStats: Operator Level Graphs added

[Toralf Förster]

On 1/9/21 9:38 PM, nusenu wrote:

- change the scale on the y axis (vertical drag and drop)


Maybe nitpicking but IMO It is irritating, that the 0% value (zero) of 
the left y-axis doesn't match the 0 GBit/s at the right y-axis (per 
default).


--
Toralf



OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] OrNetStats: Operator Level Graphs added

[Toralf Förster]

On 1/10/21 7:08 PM, li...@for-privacy.net wrote:


I don't want to expect the average user to fish something obfuscated out 
of the string. Yes, I am old and conservative ;-)
/me too - therefore I tend to not add detailed technical information 
about the relays.


(BTW that doesn't work at all with the current ciissversion if relays 
are hosted at different hoster at all, or?)


--
Toralf



OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays