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 mai
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
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 s
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
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
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).
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 join
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 i
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
D
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, ↓
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
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 preferre
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-re
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 signatur
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
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 re
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/ma
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
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
;)
--
T
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
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 rel
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 pre
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
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 m
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 con
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
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://metric
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
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
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
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 segme
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 NOROUT
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
--
Tor
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
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 pract
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-
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 neede
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 -
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 D
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-re
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 bloc
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."
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
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-sta
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.
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
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?
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
__
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/
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-mai
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 th
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.to
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
On 7/9/24 19:03, David Fifield wrote:
"A case study on DDoS attacks against Tor relays"
Tobias Höller, René Mairhofer
https://www.petsymposium.org/foci/2024/foci-2024-0014.php
After reading that paper I do wonder if a firewall rule would work which
drops network packets with destination to the
On 7/10/24 00:32, Osservatorio Nessuno via tor-relays wrote:
In both cases with 32GB of DDR5 RAM (we can max to 64 if needed, but is
it?).
IMO 4 GiB RAM per tor process is needed, with 2 GiB I sometimes
experienced an OOM.
--
Toralf
___
tor-relays
On 7/11/24 22:51, boldsuck wrote:
cat /proc/sys/net/ipv4/tcp_syncookies
cat /proc/sys/net/ipv4/tcp_tcp_timestamps
I prefer sysctl:
$ sysctl net.ipv4.tcp_syncookies
net.ipv4.tcp_syncookies = 1
$ sysctl net.ipv4.tcp_timestamps
net.ipv4.tcp_timestamps = 1
--
Toralf
Regarding to https://gitlab.torproject.org/tpo/core/tor/-/issues/40958 I
do wonder if that issue happened for stable Tor versions too - I do run
myself git HEAD only.
FWIW at my bare metal relay the RAM consumption per Tor process
decreased by about 0.7 GiB.
--
Toralf
___
On 7/12/24 00:14, boldsuck wrote:
The idea is not bad. But can you simply discard every ≤ 50byte packet?
Probably not
I drop fragments and uncommon TCP MSS values.
ip frag-off & 0x1fff != 0 counter drop
IIUC then using conntrack via iptables means that this filter cannot be
implemented, rig
On 7/16/24 14:03, boldsuck wrote:
wget
-qO-https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc
| gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null
Is the name important?
I'm asking b/c Ansible [1] seems to use "deb.torproject.org-k
On 7/12/24 00:52, boldsuck wrote:
This has been looking damn good for 4 days :-)
https://metrics.torproject.org/rs.html#search/ForPrivacyNETbr
Flags, Uptime and green dot is OK
But the behaviour is not fixed. It just happened less often.
--
Toralf
_
On 8/2/24 17:38, Hiro wrote:
We are now opening NSA for testing
May I ask, what the abbreviation "NSA" means?
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 8/14/24 16:13, boldsuck wrote:
If you have 'unattended upgrades' enabled, you will get an ERROR email.
Highly depends on a configured mailer IMO.
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/c
On 8/14/24 19:44, boldsuck wrote:
upgrades are running or not. And that I have to reboot because of the kernel
upgrade or similar. (I don't like auto reboots)
Ah, ok.
I like it and have therefore unattended upgrade configured
unconditionally for all packages [1].
Furthermore I do use needresta
On 9/16/24 21:13, boldsuck via tor-relays wrote:
Some court documents are linked here, in the google sheets:
https://safereddit.com/r/TOR/comments/19benkx/operation_liberty_lane_le_running_gaurd_and/?rdt=40060
Gus may have gotten some more documents.
returns: "Failed to parse page JSON data"
On 10/29/24 04:33, Pierre Bourdon wrote:
A few hours ago I received a forwarded abuse report from Hetzner for
one of my machines running a Tor relay (not exit).
Fun fact - the abuse email is in HTML format.
No comment.
--
Toralf
___
tor-relays mailin
On 10/29/24 04:33, Pierre Bourdon wrote:
Some tcpdumps showing random RSTs coming back to my machines running
relays (with no traffic being initiated by said machines beforehand):
You used somethign like this? :
tcpdump -i enp8s0 'tcp[13] & 4 != 0 && port 22'
--
Toralf
___
On 10/30/24 16:01, Pierre Bourdon wrote:
(props on them, I didn't send it to them myself!).
I replied to an Hetzner email at 10/29/24, 08:55 +0100 and pointed them
to this thread.
--
Toralf
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
On 9/24/24 15:40, boldsuck via tor-relays wrote:
https://paste.systemli.org/?d3987a7dc4df49fa#7GF2qk8hyTVgkinZshff9Dc9R6ukDDZo6BQqwQURzjQy
OT, but useless use of cat ;)
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lis
Never cared about this before, but isn't the "8" too often here? :
$ cat ~/tmp/tor_bridge_stats
i10 bridge-ips
ru=264,br=16,de=16,us=16,au=8,cl=8,co=8,cz=8,dz=8,eg=8,es=8,fr=8,gb=8,gr=8,hk=8,id=8,in=8,ir=8,it=8,kr=8,lt=8,lv=8,nl=8,ph=8,sa=8,sg=8,tw=8,ua=8,ve=8
i11 bridge-ips ru=152,ir=16,cn=8,cz=
On 9/24/24 18:39, David Fifield wrote:
The numbers are rounded to reduce precision.
https://spec.torproject.org/dir-spec/extra-info-document-format.html
ah, thx.
I'm just curious, if 4 is rounded to 0 or to 8 ?
--
Toralf
___
tor-relays mailing lis
On 9/24/24 20:56, boldsuck via tor-relays wrote:
Oh, you're right. It's nicer because I have instance name in front of it.
Then "grep -h" is your friend
;)
--
Toralf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torprojec
On 9/19/24 18:46, meskio wrote:
We plan to watch the usage of moat bridges and evaluate moving them
to another distributor depending on the usage[3].
Is there any timeline for the movement?
--
Toralf
___
tor-relays mailing list
tor-relays@lists.to
On 10/2/24 13:03, meskio wrote:
Not a concrete one. My plan is to review the situation early next month and
depending on the usage bring the conversation on what to do with those bridges
to our thursdays Anti-Censorship meetings.
I plan to change set the bridge distribution for my 4 unassigned
On 10/2/24 17:43, meskio wrote:
I think best right now is to configure them to be distributed over "settings".
As this is what will be automatically used by Tor Browser and other clients.
Thx.
--
Toralf
___
tor-relays mailing list
tor-relays@lists.t
401 - 474 of 474 matches
Mail list logo
