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
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 somethin
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 ex
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.
Right now
P.S:
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):
> Aug 09 21:08:36 matrix tor[XXX]: Aug 09 21:08:36.000 [noti
The DoSCircuitCreation/DoSConnection configs are unrelated to what
ReevaluateExitPolicy allows.
DoSCircuitCreation/DoSConnection are enacted by guards, to protect
themselves, and to some extent the rest of the network, from "noisy
IPs" trying to connect to Tor.
ReevaluateExitPolicy is not a DoS opt
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.
Sorry, but the Tor logs that I am seeing suggest that most DoS gets mitigated.
As far as I know, the concurrent connection (not circuit!)
On Mittwoch, 7. August 2024 14:30:27 CEST George Hartley via tor-relays wrote:
> This is already impossible, as both circuit and concurrent connection DoS
> both gets detected and the IP in question flagged and blacklisted.
No.
DoS has been a topic of conversation at nearly all relay meetings for
This is already impossible, as both circuit and concurrent connection DoS both
gets detected and the IP in question flagged and blacklisted.
Please see the manual on this:
https://2019.www.torproject.org/docs/tor-manual.html.en#DoSCircuitCreationEnabled
All the best,
George
On Sunday, August 4
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 implemente
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
to be clear about what this feature does: it was already possible to
add more rules, and these rules would apply to new connections made
from your exit, but it would *not* kill existing connections which
violate the new policy.
`ReevaluateExitPolicy` allows reevaluating the new exit policy on
exist
Hi to all dear exit operators,
If you are interested in applying the exit policy on reload and not by
restarting tor please note:
https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/735#note_3051797
Quote David:
"Can you give us a sense of how many exit operators use this? If there is a
13 matches
Mail list logo
