Re: [tor-relays] Recent wave of abuse on Tor guards

[Frédéric CORNU]

Le 20/12/2017 à 23:15, teor a écrit :
> 
>> On 21 Dec 2017, at 08:51, teor  wrote:
>>
>>>
>>> 1) Why didn't we see this abuse wave coming ? We kept replying to reporters 
>>> of the dreaded "Failing because we have XXX connections already. Please 
>>> read doc/TUNING for guidance" about how they could amend their config to 
>>> accept more connections. Although the 'global scale' of those events should 
>>> have been detected, without most of use assuming it was due to nodes' bad 
>>> config.
>>
>> Load spikes are normal, particularly with the HSDir flag, because HSDir
>> usage is not bandwidth-weighted.
>>
>> Allowing more connections *is* the right thing to do with this attack,
>> if your OS has the resources. Several of my relays never went down,
>> because they were over-provisioned with RAM and CPU.
>>
>> Others only went down temporarily, during the most intense phases.
>> (And then their excessive bandwidth weight was redistributed, and they
>> have been coping well.)
>>
>> If you don't have the resources to handle that many connections, then
>> limiting connections is the right thing to do. If you can't do it
>> using tor, then a firewall is the way to go.

This has been put in place and relay is now able to sustain the still
ongoing flood.

>>
>> (There are some bugs in Tor that make the attack more effective than
>> it should be. We're working on fixing them.)
> 
> To mitigate this attack, we recommend setting MaxMemInQueues to the amount
> of RAM you have available per tor instance (or maybe a few hundred MB less).
> 
> Tor estimates it, but the estimate isn't very good.
> 

This has been added about 12 hours ago (and relay SIGHUPed) and I still
cannot see any trace of circuit OOM kills in relay logs.

And the 2 most recent heartbeat reports show a 'normal' circuit count

Thanks for all the fish :)


-- 
Frédéric CORNU
http://wardsback.org
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] IPv6 Issue with Relay

[Conrad Rockenhaus]

Hello,

One of the relays that I brought online yesterday, ConradsAWSExit (Hash 
1B47E33F9D422CC97BD2DDA1F082BFF2FC58E79A) is showing up on Atlas that the IPv6 
OR is unreachable.

The other relay is working just fine with IPv6.

I’ve confirmed that the following entries are in torrc:

ORPort 9001
ORPort [2600:1f14:ede:d601:e107:1a4b:ba3:803]:9001
IPv6Exit 1

Just to confirm, here’s the output from ifconfig, that is the IP:

inet6 2600:1f14:ede:d601:e107:1a4b:ba3:803  prefixlen 64  scopeid 0x0

I have confirmed that all of the applicable Security Group rules are configured 
correctly:

Custom TCP Rule
TCP
9001
0.0.0.0/0
ORPort
Custom TCP Rule
TCP
9001
::/0
ORPort
Custom TCP Rule
TCP
9030
0.0.0.0/0
DIRPort
Custom TCP Rule
TCP
9030
::/0
DIRPort

Plus, I have confirmed with a telnet -6 to port 9001 from both my house and my 
servers at OVH in Canada that I’m able to connect to port 9001 via the IPv6 
address on this node.

So, my question is…what could I be missing here that is causing atlas to say 
that IPv6 is unreachable? I’ve been looking into this through the day and would 
like to kind of close it out, got a bunch of emails to catch up on hehe :D, so 
any input would be appreciated.

Thanks,

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

[tor-relays] Become a Fallback Directory Mirror

[teor]

Dear Relay Operators,

Do you want your relay to be a Tor fallback directory mirror?
Will it have the same address and port for the next 2 years?
Just reply to this email with your relay's fingerprint.

If your relay is on the current list, you don't need to do anything.

If you're asking:

Q: What's a fallback directory mirror?

Fallback directory mirrors help Tor clients connect to the network.
For more details, see [1].

Q: Is my relay on the current list?

Search [2] and [3] for your relay fingerprint or IP address and port.
[2] is the current list of fallbacks in Tor.
[3] is used to create the next list of fallbacks.

Q: What do I need to do if my relay is on the list?

Keep the same IP address, keys, and ports.
Email tor-relays if the relay's details change.

Q: Can my relay be on the list next time?

We need fast relays that will be on the same IP address and port for 2
years. Reply to this email to get on the list, or to update the details
of your relay.

Once or twice a year, we run a script to choose about 150-200 relays
from the potential list [3] for the list in Tor [2].

Q: Why didn't my relay get on the list last time?

We check a relay's uptime, flags, and speed [4]. Sometimes, a relay might
be down when we check. That's ok, we will check it again next time.

It's good to have some new relays on the list every release. That helps
tor clients, because blocking a changing list is harder.

Q: What about the current relay DDoS?

We don't think the DDoS will have much impact on the fallback list.

If your relay is affected, please:
* make sure it has enough available file descriptors, and
* set MaxMemInQueues to the amount of RAM you have available per tor
  instance (or maybe a few hundred MB less).

We're also working on some code changes. See [5] for more details.

[1]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
[2]: https://gitweb.torproject.org/tor.git/tree/src/or/fallback_dirs.inc
[3]: https://gitweb.torproject.org/tor.git/tree/scripts/maint/fallback.whitelist
[4]: 
https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_2017-05-16-0815-09cd78886.log
[5]: https://lists.torproject.org/pipermail/tor-relays/2017-December/013881.html

--
Tim / teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n




signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Recent wave of abuse on Tor guards

[teor]

> On 21 Dec 2017, at 08:51, teor  wrote:
> 
>> 
>> 1) Why didn't we see this abuse wave coming ? We kept replying to reporters 
>> of the dreaded "Failing because we have XXX connections already. Please read 
>> doc/TUNING for guidance" about how they could amend their config to accept 
>> more connections. Although the 'global scale' of those events should have 
>> been detected, without most of use assuming it was due to nodes' bad config.
> 
> Load spikes are normal, particularly with the HSDir flag, because HSDir
> usage is not bandwidth-weighted.
> 
> Allowing more connections *is* the right thing to do with this attack,
> if your OS has the resources. Several of my relays never went down,
> because they were over-provisioned with RAM and CPU.
> 
> Others only went down temporarily, during the most intense phases.
> (And then their excessive bandwidth weight was redistributed, and they
> have been coping well.)
> 
> If you don't have the resources to handle that many connections, then
> limiting connections is the right thing to do. If you can't do it
> using tor, then a firewall is the way to go.
> 
> (There are some bugs in Tor that make the attack more effective than
> it should be. We're working on fixing them.)

To mitigate this attack, we recommend setting MaxMemInQueues to the amount
of RAM you have available per tor instance (or maybe a few hundred MB less).

Tor estimates it, but the estimate isn't very good.

T

--
Tim / teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n




signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Guard node suddenly sending twice what it receives

[teor]

> On 21 Dec 2017, at 08:57, Logforme  wrote:
> 
>> Check the logs, but they won't tell you much, and that's deliberate.
>> 
> So I checked the tor log.
> 
> First part is before the "weirdness":
> Dec 20 16:00:08.000 [notice] Heartbeat: Tor's uptime is 4 days 23:59 hours, 
> with 36191 circuits open. I've sent 3686.92 GB and received 3646.75 GB.
> Dec 20 16:00:08.000 [notice] Circuit handshake stats since last time: 
> 160437/160437 TAP, 5003782/5003782 NTor.
> Dec 20 16:00:08.000 [notice] Since startup, we have initiated 0 v1 
> connections, 0 v2 connections, 1 v3 connections, and 102511 v4 connections; 
> and received 2151 v1 connections, 29819 v2 connections, 46331 v3 connections, 
> and 683484 v4 connections.
> 
> Next time during the weirdness:
> Dec 20 22:00:08.000 [notice] Heartbeat: Tor's uptime is 5 days 5:59 hours, 
> with 233634 circuits open. I've sent 3908.13 GB and received 3832.44 GB.
> Dec 20 22:00:08.000 [notice] Circuit handshake stats since last time: 
> 564576/564576 TAP, 18285622/18285622 NTor.
> Dec 20 22:00:08.000 [notice] Since startup, we have initiated 0 v1 
> connections, 0 v2 connections, 1 v3 connections, and 107666 v4 connections; 
> and received 2309 v1 connections, 31585 v2 connections, 49188 v3 connections, 
> and 711324 v4 connections.
> 
> Note that the number of circuits have gone up from a relatively normal 
> number, 36191, to a massive 233634. Definitely not normal.  And this is with 
> my connection limits in place in the iptables.
> 
> The tor process now uses about twice as much CPU as normally.
> 
> I think the attacker has found a new way "in".

Incoming connection limits aren't entirely effective against this attack,
and never were. We're working on other mitigations.

T

--
Tim / teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n




signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Guard node suddenly sending twice what it receives

[Logforme]

Check the logs, but they won't tell you much, and that's deliberate.


So I checked the tor log.

First part is before the "weirdness":
Dec 20 16:00:08.000 [notice] Heartbeat: Tor's uptime is 4 days 23:59 
hours, with 36191 circuits open. I've sent 3686.92 GB and received 
3646.75 GB.
Dec 20 16:00:08.000 [notice] Circuit handshake stats since last time: 
160437/160437 TAP, 5003782/5003782 NTor.
Dec 20 16:00:08.000 [notice] Since startup, we have initiated 0 v1 
connections, 0 v2 connections, 1 v3 connections, and 102511 v4 
connections; and received 2151 v1 connections, 29819 v2 connections, 
46331 v3 connections, and 683484 v4 connections.


Next time during the weirdness:
Dec 20 22:00:08.000 [notice] Heartbeat: Tor's uptime is 5 days 5:59 
hours, with 233634 circuits open. I've sent 3908.13 GB and received 
3832.44 GB.
Dec 20 22:00:08.000 [notice] Circuit handshake stats since last time: 
564576/564576 TAP, 18285622/18285622 NTor.
Dec 20 22:00:08.000 [notice] Since startup, we have initiated 0 v1 
connections, 0 v2 connections, 1 v3 connections, and 107666 v4 
connections; and received 2309 v1 connections, 31585 v2 connections, 
49188 v3 connections, and 711324 v4 connections.


Note that the number of circuits have gone up from a relatively normal 
number, 36191, to a massive 233634. Definitely not normal.  And this is 
with my connection limits in place in the iptables.


The tor process now uses about twice as much CPU as normally.

I think the attacker has found a new way "in".

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

Re: [tor-relays] Recent wave of abuse on Tor guards

[teor]

> On 21 Dec 2017, at 03:22, fco...@wardsback.org wrote:
> 
> Hi
> 
> I'm the happy maintainer of wardsback : 
> B143D439B72D239A419F8DCE07B8A8EB1B486FA7
> 
> As many of us have noticed, many guard nodes are beeing abused by extremely 
> high numbers of connection attempts.
> Thanks to some of you guys, I manged to put some mitigation in place [0] and 
> I assume many of us did as well.
> 
> I now sit back with questions and concerns arising :
> 
> 1) Why didn't we see this abuse wave coming ? We kept replying to reporters 
> of the dreaded "Failing because we have XXX connections already. Please read 
> doc/TUNING for guidance" about how they could amend their config to accept 
> more connections. Although the 'global scale' of those events should have 
> been detected, without most of use assuming it was due to nodes' bad config.

Load spikes are normal, particularly with the HSDir flag, because HSDir
usage is not bandwidth-weighted.

Allowing more connections *is* the right thing to do with this attack,
if your OS has the resources. Several of my relays never went down,
because they were over-provisioned with RAM and CPU.

Others only went down temporarily, during the most intense phases.
(And then their excessive bandwidth weight was redistributed, and they
have been coping well.)

If you don't have the resources to handle that many connections, then
limiting connections is the right thing to do. If you can't do it
using tor, then a firewall is the way to go.

(There are some bugs in Tor that make the attack more effective than
it should be. We're working on fixing them.)

> 2) We can see on Metrics [1] that guards count is dropping rapidly for a 
> couple weeks now. Presumably because many guard maintainers gave up on 
> restarting their crushed node. (I never will. Even though my Metrics graph 
> shows I've also been in trouble)

Nodes lose the Guard flag when they go down or restart.

If they are set to automatically restart, it will come back eventually.

If they are not, hopefully operators will restart crashed relays.

> 3) What could we do to better detect those 'attacks' and spread the word to 
> fellow maintainers about how to mitigate / correct the situation ?

That's a good question.
Detecting new attacks is hard!

And some of us are busy trying to fix this one :-)

> ...
> 
> [0] : 
> https://lists.torproject.org/pipermail/tor-relays/2017-December/013846.html
> [1] : 
> https://metrics.torproject.org/relayflags.html?start=2017-09-21=2017-12-20=Guard

--
Tim / teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n




signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] restarting tor service after AccountingMax has been reached

[Fabian A. Santiago]

December 20, 2017 4:44 PM, "teor"  wrote:

>> On 21 Dec 2017, at 08:39, Fabian A. Santiago  
>> wrote:
>> 
>> December 20, 2017 4:32 PM, "teor"  wrote:
>> 
>> On 21 Dec 2017, at 08:10, Fabian A. Santiago  
>> wrote:
>> 
>> December 20, 2017 3:32 PM, "teor"  wrote:
>> 
>> On 21 Dec 2017, at 03:07, Fabian A. Santiago  
>> wrote:
>> 
>> I'm noticing that if i attempt to restart tor AFTER AccountingMax has been 
>> reached (meaning it's
>> currently hibernating), tor itself fails to start.
>> What do you mean by "fails to start"?
>> What are the log messages?
>> 
>> if i increase AccountingMax in torrc, then it restarts just fine.
>> 
>> normal?
>> It's hard to say, without any log messages.
>> 
>> Teor,
>> 
>> the logs look normal. maybe I've misinterpreted not opening the listening 
>> ports as not starting. I
>> didn't check the actual systemd service status (silly me, I know). it's 
>> running now so next time I
>> encounter this, I'll double check.
>>> It is normal for Tor to close its listening ports when hibernating.
>>> It is normal for hibernation to persist across a restart.
>>> 
>>> If you check the logs, it probably says something about this on startup,
>>> and when it starts hibernating.
>>> 
>>> (When Tor doesn't have the right permissions to re-open these ports, the
>>> process will exit when it resumes from hibernation. That's a config issue,
>>> not a bug.)
>> 
>> I also noticed in journalctl that it (Tor) wanted me to add 'ExitRelay 1' in 
>> my torrc to disable
>> the exit relay warning and for future config requirements (it said). so i 
>> did that as well. all
>> seems well as of now.
>> 
>> so how i first noticed was when i couldn't browse to my dirport readme html 
>> page after a tor
>> restart. are you saying when it normally hibernates, that page goes down too?
> 
> Yes.
> 
> When Tor hibernates, it doesn't send or receive any data.
> That includes ORPort and DirPort requests.
> 
> T
> 
> --
> Tim / teor
> 
> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
> ricochet:ekmygaiu4rzgsk6n
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

That makes me sad, :-( ;-)

Many thanks.

--

Thanks,

Fabian S.

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

Re: [tor-relays] restarting tor service after AccountingMax has been reached

[teor]

> On 21 Dec 2017, at 08:39, Fabian A. Santiago  
> wrote:
> 
> December 20, 2017 4:32 PM, "teor"  wrote:
> 
>>> On 21 Dec 2017, at 08:10, Fabian A. Santiago  
>>> wrote:
>>> 
>>> December 20, 2017 3:32 PM, "teor"  wrote:
>>> 
>>> On 21 Dec 2017, at 03:07, Fabian A. Santiago  
>>> wrote:
>>> 
>>> I'm noticing that if i attempt to restart tor AFTER AccountingMax has been 
>>> reached (meaning it's
>>> currently hibernating), tor itself fails to start.
 What do you mean by "fails to start"?
 What are the log messages?
>>> 
>>> if i increase AccountingMax in torrc, then it restarts just fine.
>>> 
>>> normal?
 It's hard to say, without any log messages.
>>> 
>>> Teor,
>>> 
>>> the logs look normal. maybe I've misinterpreted not opening the listening 
>>> ports as not starting. I
>>> didn't check the actual systemd service status (silly me, I know). it's 
>>> running now so next time I
>>> encounter this, I'll double check.
>> 
>> It is normal for Tor to close its listening ports when hibernating.
>> It is normal for hibernation to persist across a restart.
>> 
>> If you check the logs, it probably says something about this on startup,
>> and when it starts hibernating.
>> 
>> (When Tor doesn't have the right permissions to re-open these ports, the
>> process will exit when it resumes from hibernation. That's a config issue,
>> not a bug.)
>> 
>>> I also noticed in journalctl that it (Tor) wanted me to add 'ExitRelay 1' 
>>> in my torrc to disable
>>> the exit relay warning and for future config requirements (it said). so i 
>>> did that as well. all
>>> seems well as of now.
> 
> so how i first noticed was when i couldn't browse to my dirport readme html 
> page after a tor restart. are you saying when it normally hibernates, that 
> page goes down too?

Yes.

When Tor hibernates, it doesn't send or receive any data.
That includes ORPort and DirPort requests.

T

--
Tim / teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n




signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] restarting tor service after AccountingMax has been reached

[Fabian A. Santiago]

December 20, 2017 4:32 PM, "teor"  wrote:

>> On 21 Dec 2017, at 08:10, Fabian A. Santiago  
>> wrote:
>> 
>> December 20, 2017 3:32 PM, "teor"  wrote:
>> 
>> On 21 Dec 2017, at 03:07, Fabian A. Santiago  
>> wrote:
>> 
>> I'm noticing that if i attempt to restart tor AFTER AccountingMax has been 
>> reached (meaning it's
>> currently hibernating), tor itself fails to start.
>>> What do you mean by "fails to start"?
>>> What are the log messages?
>> 
>> if i increase AccountingMax in torrc, then it restarts just fine.
>> 
>> normal?
>>> It's hard to say, without any log messages.
>> 
>> Teor,
>> 
>> the logs look normal. maybe I've misinterpreted not opening the listening 
>> ports as not starting. I
>> didn't check the actual systemd service status (silly me, I know). it's 
>> running now so next time I
>> encounter this, I'll double check.
> 
> It is normal for Tor to close its listening ports when hibernating.
> It is normal for hibernation to persist across a restart.
> 
> If you check the logs, it probably says something about this on startup,
> and when it starts hibernating.
> 
> (When Tor doesn't have the right permissions to re-open these ports, the
> process will exit when it resumes from hibernation. That's a config issue,
> not a bug.)
> 
>> I also noticed in journalctl that it (Tor) wanted me to add 'ExitRelay 1' in 
>> my torrc to disable
>> the exit relay warning and for future config requirements (it said). so i 
>> did that as well. all
>> seems well as of now.
> 
> T
> 
> --
> Tim / teor
> 
> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
> ricochet:ekmygaiu4rzgsk6n
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

so how i first noticed was when i couldn't browse to my dirport readme html 
page after a tor restart. are you saying when it normally hibernates, that page 
goes down too? 

--

Thanks,

Fabian S.

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

Re: [tor-relays] restarting tor service after AccountingMax has been reached

[teor]

> On 21 Dec 2017, at 08:10, Fabian A. Santiago  
> wrote:
> 
> December 20, 2017 3:32 PM, "teor"  wrote:
> 
>>> On 21 Dec 2017, at 03:07, Fabian A. Santiago  
>>> wrote:
>>> 
>>> I'm noticing that if i attempt to restart tor AFTER AccountingMax has been 
>>> reached (meaning it's
>>> currently hibernating), tor itself fails to start.
>> 
>> What do you mean by "fails to start"?
>> What are the log messages?
>> 
>>> if i increase AccountingMax in torrc, then it restarts just fine.
>>> 
>>> normal?
>> 
>> It's hard to say, without any log messages.
> 
> Teor,
> 
> the logs look normal. maybe I've misinterpreted not opening the listening 
> ports as not starting. I didn't check the actual systemd service status 
> (silly me, I know). it's running now so next time I encounter this, I'll 
> double check.

It is normal for Tor to close its listening ports when hibernating.
It is normal for hibernation to persist across a restart.

If you check the logs, it probably says something about this on startup,
and when it starts hibernating.

(When Tor doesn't have the right permissions to re-open these ports, the
process will exit when it resumes from hibernation. That's a config issue,
not a bug.)

> I also noticed in journalctl that it (Tor) wanted me to add 'ExitRelay 1' in 
> my torrc to disable the exit relay warning and for future config requirements 
> (it said). so i did that as well. all seems well as of now.

T

--
Tim / teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n




signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] restarting tor service after AccountingMax has been reached

[Fabian A. Santiago]

December 20, 2017 3:32 PM, "teor"  wrote:

>> On 21 Dec 2017, at 03:07, Fabian A. Santiago  
>> wrote:
>> 
>> I'm noticing that if i attempt to restart tor AFTER AccountingMax has been 
>> reached (meaning it's
>> currently hibernating), tor itself fails to start.
> 
> What do you mean by "fails to start"?
> What are the log messages?
> 
>> if i increase AccountingMax in torrc, then it restarts just fine.
>> 
>> normal?
> 
> It's hard to say, without any log messages.
> 
> T
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Teor,

the logs look normal. maybe I've misinterpreted not opening the listening ports 
as not starting. I didn't check the actual systemd service status (silly me, I 
know). it's running now so next time I encounter this, I'll double check. 

I also noticed in journalctl that it (Tor) wanted me to add 'ExitRelay 1' in my 
torrc to disable the exit relay warning and for future config requirements (it 
said). so i did that as well. all seems well as of now. 

--

Thanks,

Fabian S.

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

Re: [tor-relays] botnet? abusing/attacking guard nodes by openssl?

[teor]

> On 21 Dec 2017, at 06:48, Felix  wrote:
> 
> Hi everybody
> 
>> * if all 65535 connections on an IP were open to the Tor network, and
>> * the biggest Tor Guard has 0.91% Guard probability[0], then
>> * it would expect to see 597 connections.
> 
> Sorry if this is a silly question, but do we know if these are Tor
> clients connecting our guards? We see many connects but not much circuits.

Some of us have analysed the details of this attack on our relays.
The clients perform SSL, the Tor link protocol, and parts of the circuit 
protocol.
Are they real Tor clients? Possibly not.

We're working on a fix, please see this email for details:
https://lists.torproject.org/pipermail/tor-relays/2017-December/013881.html

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

Re: [tor-relays] Guard node suddenly sending twice what it receives

[teor]

> On 21 Dec 2017, at 06:29, Logforme  wrote:
> 
> My little guard node (855BC2DABE24C861CD887DB9B2E950424B49FC34) have suddenly 
> started to behave strangely. iftop (my "bandwidth monitor"), shows twice as 
> much sent traffic as received traffic. The traffic seems to be distributed to 
> a lot of ip addresses. No ip address stands out as receiving very much 
> traffic: https://imgur.com/a/dAUzc
> 
> Given the last few days of DDoS attacks (my node is still targeted by those) 
> I naturally assume this is another attack.
> First it is lots of connections (mitigated with connection limits)
> Then it is massive amounts of memory per circuit (MaxMemInQueues fixes that)
> And now this.
> 
> Could this be a third attack vector or am I seeing something "normal" (though 
> I often check my bandwidth and I've never seen this before). My node recently 
> got the HSDir flag after the last crash. Could the network be starved for 
> HSDir machines and this is what I'm seeing?

This is normal for HSDirs and directory mirrors, because the requests
are smaller than the responses.

> Being a linux noob I don't know how to figure out exactly what kind of 
> traffic this is. Suggestions gratefully accepted.

Check the logs, but they won't tell you much, and that's deliberate.

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

Re: [tor-relays] restarting tor service after AccountingMax has been reached

[teor]

> On 21 Dec 2017, at 03:07, Fabian A. Santiago  
> wrote:
> 
> I'm noticing that if i attempt to restart tor AFTER AccountingMax has been 
> reached (meaning it's currently hibernating), tor itself fails to start.

What do you mean by "fails to start"?
What are the log messages?

> if i increase AccountingMax in torrc, then it restarts just fine. 
> 
> normal?

It's hard to say, without any log messages.

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

Re: [tor-relays] botnet? abusing/attacking guard nodes by openssl?

[Felix]

Hi everybody

> * if all 65535 connections on an IP were open to the Tor network, and
> * the biggest Tor Guard has 0.91% Guard probability[0], then
> * it would expect to see 597 connections.

Sorry if this is a silly question, but do we know if these are Tor
clients connecting our guards? We see many connects but not much circuits.

Could someone get state by:
openssl s_client -connect tor-guard-ip:tor-guard-orport -tls1
and establish awfull many tls connects without any circuit ?

In this case there are like 64k outbound ports available and the
necessary memory/cpu for openssl is much lower than for a regular Tor
client.

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

[tor-relays] Guard node suddenly sending twice what it receives

[Logforme]

My little guard node (855BC2DABE24C861CD887DB9B2E950424B49FC34) have 
suddenly started to behave strangely. iftop (my "bandwidth monitor"), 
shows twice as much sent traffic as received traffic. The traffic seems 
to be distributed to a lot of ip addresses. No ip address stands out as 
receiving very much traffic: https://imgur.com/a/dAUzc


Given the last few days of DDoS attacks (my node is still targeted by 
those) I naturally assume this is another attack.

First it is lots of connections (mitigated with connection limits)
Then it is massive amounts of memory per circuit (MaxMemInQueues fixes 
that)

And now this.

Could this be a third attack vector or am I seeing something "normal" 
(though I often check my bandwidth and I've never seen this before). My 
node recently got the HSDir flag after the last crash. Could the network 
be starved for HSDir machines and this is what I'm seeing?


Being a linux noob I don't know how to figure out exactly what kind of 
traffic this is. Suggestions gratefully accepted.


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

Re: [tor-relays] botnet? abusing/attacking guard nodes

[niftybunny]

Same shit here. It looks like this:

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

Markus


“Cheery was aware that Commander Vimes didn't like the phrase 'The innocent 
have nothing to fear', believing the innocent had everything to fear, mostly 
from the guilty but in the longer term even more from those who say things like 
'The innocent have nothing to fear'.”

― Terry Pratchett, Snuff

> On 20. Dec 2017, at 17:18, Toralf Förster  wrote:
> 
> On 12/20/2017 04:39 PM, x9p wrote:
>>> My relay B33BFA9AA0005730C1C0E8F7E6F53CF3C5716BD6 is not currently
>>> tagged as Guard, and I am seeing more than twenty IPv4s with more than
>>> 10 connections, and one with 147. Should that be considered normal for a
>>> non-guard relay?
>>> 
>>> Cheers,
>>> 
>>> -- Santiago
>> 147 is a bit high for a non-exit, non-guard, for a single IP. check
>> https://atlas.torproject.org/ and see if this IP is part of Tor network.
>> 
> 
> ? IMO relays don't open more than 1 connection to another relay.
> 
> -- 
> Toralf
> PGP C4EACDDE 0076E94E
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[tor-relays] Recent wave of abuse on Tor guards

[fcornu]

Hi

I'm the happy maintainer of wardsback : 
B143D439B72D239A419F8DCE07B8A8EB1B486FA7


As many of us have noticed, many guard nodes are beeing abused by 
extremely high numbers of connection attempts.
Thanks to some of you guys, I manged to put some mitigation in place [0] 
and I assume many of us did as well.


I now sit back with questions and concerns arising :

 1) Why didn't we see this abuse wave coming ? We kept replying to 
reporters of the dreaded "Failing because we have XXX connections 
already. Please read doc/TUNING for guidance" about how they could amend 
their config to accept more connections. Although the 'global scale' of 
those events should have been detected, without most of use assuming it 
was due to nodes' bad config.


 2) We can see on Metrics [1] that guards count is dropping rapidly for 
a couple weeks now. Presumably because many guard maintainers gave up on 
restarting their crushed node. (I never will. Even though my Metrics 
graph shows I've also been in trouble)


 3) What could we do to better detect those 'attacks' and spread the 
word to fellow maintainers about how to mitigate / correct the situation 
?


I must admit I don't have a valuable clue about how things can 
technically be improved, but I humbly wanted to share a few thought 
here.


Peace

[0] : 
https://lists.torproject.org/pipermail/tor-relays/2017-December/013846.html
[1] : 
https://metrics.torproject.org/relayflags.html?start=2017-09-21=2017-12-20=Guard


--
Frédéric CORNU
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Ongoing DDoS on the Network - Status

[David Goulet]

Hi everyone!

I'm David and I'm part of the core development team in Tor. A few minutes ago
I just sent this to the tor-project@ mailing list about the DDoS the network
is currently under:

https://lists.torproject.org/pipermail/tor-project/2017-December/001604.html

There is not much more to say about this right now but I wanted to thanks
everyone here for running a relay, this situation is not pleasant for anyone
especially for relay operators for which you need to deal with this attack
(and extra bonus point during the holidays for some...).

Second, everyone who provided information, took the time to dig in this
problem and sent their findings on this list was a HUGE help to us so again,
thank you very much for this.

We will update everyone as soon as possible on the status of the tor releases
that hopefully will contain fixes that should help mitigate this DDoS.

Cheers!
David

-- 
aFJe0kbRB1zZXgwFQIvBG0Skn3xAsDGxVQsAiguKjY8=


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

Re: [tor-relays] botnet? abusing/attacking guard nodes

[Toralf Förster]

On 12/20/2017 04:39 PM, x9p wrote:
>> My relay B33BFA9AA0005730C1C0E8F7E6F53CF3C5716BD6 is not currently
>> tagged as Guard, and I am seeing more than twenty IPv4s with more than
>> 10 connections, and one with 147. Should that be considered normal for a
>> non-guard relay?
>>
>> Cheers,
>>
>>  -- Santiago
> 147 is a bit high for a non-exit, non-guard, for a single IP. check
> https://atlas.torproject.org/ and see if this IP is part of Tor network.
> 

? IMO relays don't open more than 1 connection to another relay.

-- 
Toralf
PGP C4EACDDE 0076E94E



signature.asc
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] botnet? abusing/attacking guard nodes

[Stijn Jonker]

On 20 Dec 2017, at 16:39, x9p wrote:


On Wed, December 20, 2017 12:10 pm, Santiago wrote:
...


My relay B33BFA9AA0005730C1C0E8F7E6F53CF3C5716BD6 is not currently
tagged as Guard, and I am seeing more than twenty IPv4s with more 
than
10 connections, and one with 147. Should that be considered normal 
for a

non-guard relay?


147 is a bit high for a non-exit, non-guard, for a single IP. check
https://atlas.torproject.org/ and see if this IP is part of Tor 
network.


My relay is regularly struggling a bit nowadays, with some source IP's 
crossing over the 1000 connections, but quite a few at 50-100. The one 
with 1000 connections, and for some random IP's none of their IP's being 
listed as an Tor node on atlas. Seems to be a lot of IP's out of 
54.36.51.0/24 that tend to open a lot of sessions. Whereby the ones 
checked are not on Atlas.


At some point the entire conntrack table was full and OOM kills for the 
tor process. This only left me to put in some connection limits. Despite 
being advices against. I currently have:
200 connections per /24, if that's used then at least allow 24 
connections per /32.


I'm currently running with 6600 connections just fine; when it crosses 
the 15k it becomes troublesome.


Now blocking some connections might be far-far from ideal, but better 
~6000 connections served with bandwidth then to remove my relay from the 
tor network in my view.


That said it would be good if the Tor program itself would have some 
protections, to the extend possible, with the current protocol. For 
instance dropping clients (source IP's) that frequently connect but are 
not behaving. I understand this might have it's implications when under 
censorship/censorship countermeasures.


--
Yours Sincerely / Met Vriendelijke groet,
Stijn Jonker

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

[tor-relays] restarting tor service after AccountingMax has been reached

[Fabian A. Santiago]

I'm noticing that if i attempt to restart tor AFTER AccountingMax has been 
reached (meaning it's currently hibernating), tor itself fails to start. if i 
increase AccountingMax in torrc, then it restarts just fine. 

normal?


--

Thanks,

Fabian S.

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

Re: [tor-relays] botnet? abusing/attacking guard nodes

[x9p]

On Wed, December 20, 2017 12:10 pm, Santiago wrote:
...
>
> My relay B33BFA9AA0005730C1C0E8F7E6F53CF3C5716BD6 is not currently
> tagged as Guard, and I am seeing more than twenty IPv4s with more than
> 10 connections, and one with 147. Should that be considered normal for a
> non-guard relay?
>
> Cheers,
>
>  -- Santiago

147 is a bit high for a non-exit, non-guard, for a single IP. check
https://atlas.torproject.org/ and see if this IP is part of Tor network.


cheers.

--
x9p | PGP : 0x03B50AF5EA4C8D80 / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 
E7EE

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

Re: [tor-relays] botnet? abusing/attacking guard nodes

[tor]

>> My relay B33BFA9AA0005730C1C0E8F7E6F53CF3C5716BD6 is not currently
>> tagged as Guard, and I am seeing more than twenty IPv4s with more than
>> 10 connections, and one with 147. Should that be considered normal for a
>> non-guard relay?

Yes, that seems entirely normal.
​
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] botnet? abusing/attacking guard nodes

[Santiago]

El 19/12/17 a las 11:13, teor escribió:
…
> If there are 65535 connections open from a source IP, and they all go to
> Tor Guards, and the clients weight connections according to Guard
> probability, then the largest guard will have 0.91% of 65535 connections,
> or approximately 597.
> 
> Most guards would see 10-200 connections per IP.
…

My relay B33BFA9AA0005730C1C0E8F7E6F53CF3C5716BD6 is not currently
tagged as Guard, and I am seeing more than twenty IPv4s with more than
10 connections, and one with 147. Should that be considered normal for a
non-guard relay?

Cheers,

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

Re: [tor-relays] New Relay Online/Working on AWS Cloud Torproject

[teor]

> On 20 Dec 2017, at 20:59, Conrad Rockenhaus  wrote:
> 
> ConradsAWSRelay was started back up on a new AWS instance running Amazon 
> Linux and it’s hash is now 9F7F05699131E1E2A22F70B83E8CBB4671F5FEE2. I have 
> upgraded to Tor 0.3.1.9…. I had issues with getting the libevent development 
> header dependencies resolved on Amazon Linux so I just compiled it on Red Hat 
> and brought it over. More than likely I overlooked something and caused a 
> cascade of failures from there, anyway, it’s up.
> 
> Additionally, I brought up ConradsAWSExit, 
> 1B47E33F9D422CC97BD2DDA1F082BFF2FC58E79A, to help out with that area. I may 
> bandwidth limit this one depending on load,  I will have to wait and see how 
> much traffic it gets since I don’t have unlimited $$$ to allocate to my new 
> hobby :).

Yes, running nodes at AWS can be expensive.
I'm also interested to see what abuse complaints you get.

> If someone could take another look and provide me any feedback/constructive 
> criticism about these two nodes, I would greatly appreciate it.

Since you control multiple relays, please set MyFamily on all of them:

MyFamily fingerprint1,fingerprint2

This is important because they are in different IPv4 /16s.
(It will be even more important if one has the Guard flag, and the other
has the Exit flag.)

Does AWS have native IPv6 yet?

If so, please set on both relays:

ORPort [IPv6]:Port

And on the Exit:

IPv6Exit 1

You could connect to IPv6 using a nearby free tunnel service
(Hurricane Electric is good, and has good peering with AWS),
but this is not as fast or reliable as native IPv6.

But as a learning experience, it's a good way to get IPv6.

> Thank you for everyone’s advise! I also appreciate the input regarding the 
> revitalization of the Cloud project again. Another person has also 
> volunteered to assist in the project so hopefully things should start moving 
> here pretty soon!

That's exciting.
It would be great for people to be able to choose between multiple
providers. Free VPSs are a great way to learn how to set up a relay.

The biggest issue with the cloud image was that it wasn't kept up
to date. I wonder if there's a way of doing that automatically.

I also wonder if there's a way of giving people a BSD image option
as well.

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

Re: [tor-relays] New Relay Online/Working on AWS Cloud Torproject

[Conrad Rockenhaus]

Hello,

ConradsAWSRelay was started back up on a new AWS instance running Amazon Linux 
and it’s hash is now 9F7F05699131E1E2A22F70B83E8CBB4671F5FEE2. I have upgraded 
to Tor 0.3.1.9…. I had issues with getting the libevent development header 
dependencies resolved on Amazon Linux so I just compiled it on Red Hat and 
brought it over. More than likely I overlooked something and caused a cascade 
of failures from there, anyway, it’s up.

Additionally, I brought up ConradsAWSExit, 
1B47E33F9D422CC97BD2DDA1F082BFF2FC58E79A, to help out with that area. I may 
bandwidth limit this one depending on load,  I will have to wait and see how 
much traffic it gets since I don’t have unlimited $$$ to allocate to my new 
hobby :).

If someone could take another look and provide me any feedback/constructive 
criticism about these two nodes, I would greatly appreciate it.

Thank you for everyone’s advise! I also appreciate the input regarding the 
revitalization of the Cloud project again. Another person has also volunteered 
to assist in the project so hopefully things should start moving here pretty 
soon!

Thanks,

Conrad

> On Dec 19, 2017, at 9:02 PM, Conrad Rockenhaus  wrote:
> 
> 
> 
>> On Dec 19, 2017, at 8:55 PM, teor > > wrote:
>> 
>> 
>> On 20 Dec 2017, at 13:28, Conrad Rockenhaus > > wrote:
>> 
>>> Howdy,
>>> 
>>> Early this morning (3 AM CST) I brought a non-exit relay named 
>>> “ConradsAWSRelay” online. I would appreciate it if someone would take an 
>>> objective look at it to see if the relay is fast enough and bringing useful 
>>> services to the tor network.
>> 
>> Please upgrade your relay to the latest Tor version:
>> https://lists.torproject.org/pipermail/tor-announce/2017-December/000147.html
>>  
>> 
>> 
> 
> I noticed this when I started it up. It appears that the version of Tor on 
> EPEL is out of date. I’ll build it out of source to fix it. I’ll probably 
> have to do that for the Cloud solution as well since the lifecycle of EPEL is 
> normally behind. I’ll fix this now.
> 
>> Your relay might take a few weeks to be used:
>> https://blog.torproject.org/lifecycle-new-relay 
>> 
> I completely forgot about that. Thank you for reminding me :D.
> 
>> 
>>> Additionally, I know that people have been working on ansible solutions 
>>> regarding the installation of tor and what not, but that being said, I’m 
>>> working on an AWS specific solution to replace the previous Cloud 
>>> torproject that we had years ago. I will keep everyone in the loop, but I 
>>> think its time that we have a cloud specific solution for rolling out tor.
>> 
>> Thanks!
>> It would be great to have this again.
> 
> I’m making progress and will advise all when I hit certain points so I can 
> get feedback. I would like this new solution to have significant community 
> input so I have all of my i’s dotted and my t’s crossed.
> 
> Thanks,
> 
> Conrad
> 
>> 
>> T
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org 
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

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

Re: [tor-relays] Tor Advocacy, Political & Artistic

[Vasilis]

Hello Kenneth,

Kenneth Freeman:
> I've recently touted establishing a Tor exit node at the inaugural Boise
> organizing committee of the Democratic Socialists of America.>
> The idea was considered esoteric, but such anonymity craft is useful for
> activists of all stripes.
> 
> Too, performing artists (neo-burlesque, LGBTQ comics, etc.), punks and
> anarchists have also expressed interest in Tor.

Thank you for running an exit relay.
Anonymity is useful for all creatures. :)

> I have been told that Tor is conceptually difficult to wrap your head
> around, but these are useful mission fields.

Any specifics on what is the conceptually difficulty to Tor?


Cheers,
~Vasilis
-- 
Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162
Pubkey: https://pgp.mit.edu/pks/lookup?op=get=0x5FBF70B1D1260162



signature.asc
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] Image asset in Tor readme html

[Florentin Rochet]

On 2017-12-20 03:52, teor wrote:

On 20 Dec 2017, at 12:59, Fabian A. Santiago  
wrote:

Can the Tor service not serve up a locally referenced PNG file in the readme 
HTML file used for dirportfrontpage? Mine keeps showing as a broken link.

Tor doesn't have this feature, it simply serves the page as a single file.
There are probably some tricks you could use with newer browsers
to embed a PNG file in the page.


This example may help you: http://145.239.91.37. View source to see how 
the Tor image is embedded


Best,
Florentin

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